Backup server config

Backup server configuration

Overview

This method utilizes the standard backup to desktop function. Data in ibays and user folders is temporarily moved to a temp folder, which will not be included in the backup. If required, user, ibay and other data can be manually copied from the backup server to the restored server either partially or in total after the restore.

If you have large amounts of data in other locations, then that should also be moved to the /tmp or /temp folder.

This method is a good way to create a server clone that has identical configuration but no data, without going through all the setup again.

Procedure

Note:

This method does not transfer mysql database information. If you wish to transfer mysql data, please see the section below titled "Manually transferring configuration information" or use the standard backup/restore routines. To transfer mysql data manually you must use the signal-event pre-backup command on the old server to dump the mysql tables to a file in /home/e-smith/db/mysql/ and then copy that file to the new server.

	Tip:
	It is preferable to make a /temp folder as files in /tmp are routinely automatically deleted by the server, and using /temp will avoid unwanted inadvertent deletion. If you don't have much data or email in /home/e-smith/files/users then don't bother to move that.

1. On the server to be backed up (server1) do mkdir -p /temp mv /home/e-smith/files/users /temp mv /home/e-smith/files/ibays /temp
2. Perform backup to desktop on server1 using the standard server manager panel
3. Then on server1 do mv /temp/users /home/e-smith/files/ mv /temp/ibays /home/e-smith/files/
4. Build another server to restore to (server2), and perform a fresh install of sme server on it. Note that any preferred hardware can be used, it does not need to be physically identical to the original server the backup was performed on.
5. Perform Restore from desktop on server2 using the standard server manager panel.
6. On the restored server (server2), login as admin and select Configure this server. Change the local IP and other settings as required, detect different NIC's, and also change to server only mode if it's going to be a second server on your network (where the backed up server was a server/gateway) and disable the DHCP server. As a minimum, make sure you change the local IP on the restored server as it will be identically configured after the restore. Then log in to server manager on the restored server and change workgroup name and domain controller settings and any other settings required etc.

You should now have a second server (server2) which is identically configured to server1 (except for changes that were made) but without user and ibay data. Note that the user and ibays will exist in server manager and in the file structure, but they will be empty.

Copying data to the restored server

You can then optionally transfer the data across the network from server to server either totally or in limited form as required using command line, tar and scp. You can delete any users, ibays, groups and other settings not required on the restored server via server manager.

It is preferable to tar/untar data so you don't loose ownership and permissions during the copy from server1 to server2. If copying user data and email using normal copy commands, then ensure that ownership is correct on the new server.

Modify the following commands appropriately to only move the data you require.

1. Use tar to compress all the user and ibays folders (on server1) by doing cd /home/e-smith/files tar -czvf /temp/users.tar.gz users tar -czvf /temp/ibays.tar.gz ibays
2. Use scp to copy the tarred files between machines by doing (on server1)

   	Note:
   	You will need to have remote access between the servers setup to be able to ssh, either using passwords or ssh keys.

   
   

   scp /temp/users.tar.gz server2IP:/home/e-smith/files/
   scp /temp/ibays.tar.gz server2IP:/home/e-smith/files/ 
   

   If ssh is configured for a different port (than 22) use

   scp -P xxxx /temp/users.tar.gz server2IP:/home/e-smith/files/
   scp -P xxxx /temp/ibays.tar.gz server2IP:/home/e-smith/files/
   

   where xxxx = port number

3. Use tar to uncompress all the user and ibay folders by doing (on server2) cd /home/e-smith/files/ tar -xvzf users.tar.gz tar -xvzf ibays.tar.gz rm /home/e-smith/files/users.tar.gz rm /home/e-smith/files/ibays.tar.gz If required, to correct ownership for each user on server2 do cd /home/e-smith/files/users chown -R username:username username

Manually transferring configuration information

If you wish to manually transfer configuration information from an old server to a new server you can use the following steps. All the files listed below are required as user information & passwords is contained in many different locations.

On the old server do the following to dump the mysql tables to a file in /home/e-smith/db/mysql/:

signal-event pre-backup

Before restoring files to the new server, issue the following command on the new server:

signal-event pre-restore

Then copy all the following files & folders from the old server to the new server preferably using the tar command, see usage examples & syntax above in the section "Copying data to the restored server". You can exclude ibay & user data if preferred by moving that data to /temp (see steps in above section "Procedure") This list is based on the requirements of sme7.2:

/etc/e-smith/templates-custom
/etc/e-smith/templates-user-custom
/etc/group
/etc/gshadow
/etc/passwd
/etc/samba/secrets.tdb
/etc/samba/smbpasswd
/etc/shadow
/etc/smbpasswd
/etc/ssh
/etc/sudoers
/home/e-smith
/root

and add in

/opt

if you have stuff installed there.

After copying all the required files to the new server you then need to run the following commands on the new server:

signal-event post-upgrade
reboot

Standard backup & restore inclusions

This command will give a listing of the files & folders included in a standard backup & restore, as per a default install of sme server.

perl -e 'use esmith::Backup; $b = new esmith::Backup;print join("\n",$b->restore_list)'

Which on a sme7.3 server shows:

home/e-smith
etc/e-smith/templates-custom
etc/e-smith/templates-user-custom
etc/ssh
root
etc/sudoers
etc/passwd
etc/shadow
etc/group
etc/gshadow
etc/samba/secrets.tdb
etc/samba/smbpasswd
etc/smbpasswd

Backup and Restore concepts, issues and other information

The sme backup & restore concept is that only data (users & ibays) and configuration (including all mysql dbs) is backed up & restored. All contribs (ie installed as rpms) are not backed up.

A restore is done to a fresh installation of sme server, and then contribs are reinstalled. As configuration data is restored, you should not need to setup those reinstalled contribs again.

It's good admin practise to create an ibay specifically to house a copy of every rpm you install, so you can easily reinstall those from your backed up and restored copies, although with yum repos being available now, it's not so necessary to do this. It does provide a reminder of everything you have installed though, in case you forget.

The Affa contrib provides you with a report of missing rpms (if you enable that setting), which is the difference between the source server and the backup server, so you can easily see what needs reinstalling after a restore or Affa "rise", or install those on the Affa backup server in advance (if using a separate backup server).

Note that a tape backup backs up all file systems on the server, but only restores the "standard restore" files. See this list http://wiki.contribs.org/Backup_server_config#Standard_backup_.26_restore_inclusions

If you wish to backup "everything" (including installed rpms), then the standard sme backup methods, which includes most of the available backup contribs eg DAR2, Backup with dar, etc, do not backup "everything". You need to perform a bare metal or disk clone backup to achieve that. The contrib that does that is Mondo, but it may not have been updated to be compatible with sme7.x. Another way of easily doing this is to swap out a RAID1 disk, and plug in a clean (empty) disk. Disk cloning software can also be used, but it must support RAID partitions and lvm volumes, and some software does not. The Linux dd command will also copy every bit on a disk, to another mounted disk, but it will be slow and may take a long time for a disk with a lot of data.

Reference links

http://wiki.contribs.org/UpgradeDisk

http://forums.contribs.org/index.php?topic=30745.0

http://forums.contribs.org/index.php?topic=39969.0

---