One benefit of using a Linux environment is that the whole system back up is extremely easy. In fact, if you are doing the backups and restores for the same machine (which is usually the case), you only need to use the TAR command (see details) and no special software is needed.
However, sometimes it is desirable to have a standby instance of the machine. For example, in a production environment, if a standby server is hot-synced with the production server then in the event of a production server failure, the standby server can kick in right away and the downtime can be reduced to as little as a couple of minutes. Whereas if a system restore is required, the production server has to be re-imaged and that can take significantly longer.
Fortunately, it is relatively easy to achieve this goal. In this post I will show you how to backup a Ubuntu Server (7.04) system to a Virtual Server. It only requires a few more steps then the plain vanilla TAR backup/restore.
- Backup
The backup command is almost identical to the command used in a standard backup (e.g. the backup is used to restore to the same server). Because the backup machine might not have the same physical specs as the machine where we perform the backup, we need to exclude a few more items. Particularly,
/dev, /etc/fstab, /etc/hostname, /etc/iftab might be different on the backup machine and we need to be careful not to overwrite them when restoring. An example of the TAR command used for backup a system is listed here:
tar -czf /mnt/backup/sysbackup/backup.tgz –exclude=/proc –exclude=/dev –exclude=/lost+found –exclude=/mnt –exclude=/sys –exclude=/cdrom –exclude=/etc/fstab –exclude=/etc/hostname –exclude=/etc/iftab /
- Preparing the Backup VM
Here I use a virtual machine to illustrate the restore-to-a-different machine strategy. In practice though, this can also be a physical machine.
First, you will need to prepare a minimum VM that has the desired OS on it (in my case Ubuntu Server 7.04). The OS is needed because we are using TAR to do the backup and restore. It should be pretty easy though as most server version Linux images support unattended setup.
You do not need to install any security updates afterward as the system will be brought up to date during the restoration process.
- Resotring Backup Image to VM
Now copy the backup image over to the VM. Because certain files can only be overwritten when they are not in use, we will perform the restoration in single user mode:
init 1
next we will restore the backup image:
tar -xpzf /backup.tgz -C /
DO NOT REBOOT AFTER RESTORE! If you reboot right after the restoration, the system will not be in a bootable state (e.g. system drive’s UUID has not been updated yet, if you reboot now you will not be able to boot into your system. In this case you will have to use a live CD to boot and fix your system from there).
First thing we need to do is to set the correct UUID for the partition we are booting from.
Do a df to see which partition is the root partition, e.g.
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 113892200 1007084 107099712 1% /
Find out the UUID of the partition:
dumpe2fs /dev/sda1 | grep UUID
Write down the UUID of the partition and double check to make sure that it is written down correctly as wrong UUID will lead to a boot failure.
Now, we need to edit /boot/grub/menu.lst to update the boot partition’s UUID.
In menu.lst, find entries like:
title Ubuntu, kernel 2.6.20-16-server
root (hd0,0)
kernel /boot/vmlinuz-2.6.20-16-server root=UUID=401eeff8-c149-4db6-b4df-6cd899b880c6 ro quiet splash
initrd /boot/initrd.img-2.6.20-16-server
quiet
savedefaultAnd change the UUID to the one you just copied down. Again, use extra caution to ensure that the UUID is changed correctly.
Depending on the system, there might be quite a few entries with the same UUID as you might have different kernels installed. If you are not certain, change them all.
Now you should be able to reboot into the restored system. After reboot, you might not have access to the network any longer due to the MAC change of the ethernet during system restore. This can be fixed easily. Do a
ipconfig -a
you should see an entry with eth0 (or eth1). Copy down the HWaddr (e.g. 00:52:AA:C2:F9:CD) and use this value to update /etc/iftab
eth0 mac 00:52:AA:C2:F9:CD arp 1
Make sure that the ether net interface is updated to eth0.
Now you should be able to use ifup eth0 to bring up the network. see this thread for more detailed discussion on this issue.
One benefit of this backup strategy is that you are always guaranteed that the backup image works correctly, and you can have the backup system on standby using rsync to synchronize the backup machine and your production machine. And in the event of a disaster, your backup machine can kick in immediately.
Restoring the image back to the production machine is actually easier since you can just restore the image back without the need to change any configurations mentioned above (however, it is still a good idea to check).
