But for my Web server running WordPress,this backup method seemed to be an overkill. I use the following method to setup a standby WordPress server (can be either a VM or a physical machine). The backup server is always running and it’s content is synced up with the production server. In the event of a production server failure, all I need to do is to re-route the port 80 traffic to the standby server, which can be achieved in a matter of seconds.

To setup the standby server, I first installed Ubuntu server 8.04.1 (the same version as on my production server, with LAMP), and copied the WordPress content over (of course, most of the configurations need to be identical to the production server as well). To sync up the database content and the custom contents (e.g. uploaded images), the following command is scheduled to run on the server on a daily basis, which essentially backs up the content database:

on the standby server, the following commands are scheduled using cron daily to pick up the changes in production environment:

The above commands essentially restore the production database snapshot onto the standby server and sync up the custom contents.

One benefit of this hot sync technique is that the standby server is always live and can be tested readily by changing the host entry in /etc/hosts to point the production url to the standby server.

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
savedefault

And 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).