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
- 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
- Perform backup to desktop on server1 using the standard server manager panel
- Then on server1 do mv /temp/users /home/e-smith/files/ mv /temp/ibays /home/e-smith/files/
- 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.
- Perform Restore from desktop on server2 using the standard server manager panel.
- 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.
- 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
- Use scp to copy the tarred files between machines by doing (on server1)
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
- 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
This list can be found in
/usr/lib/perl5/site_perl/esmith/Backup.pm
Changes to this file will be overwriten during upgrades.
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 and custom templates) is backed up & restored. All contribs (ie installed as rpms) are not backed up and normal templates (which are installed by the system or add on contribs) 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.
If you use any add on contrib for backup purposes eg Affa or Dar2 or whatever, then after doing a fresh reinstall of the sme OS, the first thing you do is reinstall the backup contrib and do some basic configuration manually. Then you would restore using that contrib, then you can reinstall all other contribs etc.
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. Each of these methods has their own practical issues, choose the one that best suits your situation.
From what I have read earlier you will get into trouble trying to restore rpms which have executables installed in the normal Linux file system locations, that's why they should be reinstalled. Also some contribs will need to be updated if you restore to a newer version of the sme OS, so if you automatically restore old contribs, then you will break your server, in some cases.
Add on scripts etc are best implemented via custom templates (which do get backed up), and any scripts can be put into /opt/xxx, and you then add /opt to your list of backup inclusions, or put them into an ibay if preferred, which does get backed up automatically.
The DAR2 contrib has a web interface that is configurable and allows you to create the disaster recovery backup (ie all data and configuration) required to rebuild a server, but you still need to reinstall add on contribs (rpms). It also allows allows selective backup jobs to be done, eg of certain ibays only, depending on your particular needs.
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
