Experiments in Rapid System Restoration using Tardiff

One great feature of Linux and other Unix variants is that you can quickly make a “bare metal” restoration or duplicate of a system provided you have a full backup of the original.  (With Windows, the registry requires special tools in order to back up.)  Assuming the hardware is the same, you can start with a new installation of the same operating system as the original (say Fedora Core 2), extract the backup (excluding /proc and /dev), and in many cases, the system will function wonderfully.

But what if the destination system has different hardware or network configurations than the original?  Is there a way of rapidly restoring the system?  For example, our web site will be hosted on a Virtuozzo virtual machine and I would like to have a duplicate of the system running on a VMWare virtual machine.  Simply copying the root directory yields a great error on boot-up: “Init: no more processes at this runlevel.”  As it turns out, Virtuozzo imposes quotas on processes, threads, and files through a system that clearly upsets VMWare.  In addition the virtual network drivers are incompatible.

So I tried this:

  • Take a tar ball of a pristine OS install on Virtuozzo
  • Take a tar ball of the fully running machine on Virtuozzo
  • Create a “diff” tar ball containing only those files changed between the pristine OS install and the fully running machine (using version of the tardiff.pl comparison tool modified by Tim Schwenk)
  • Apply the “diff” tar ball to a pristine OS install on VMWare

The concept behind this technique is that any files that were not modified from the pristine OS install to the fully running system were either standard OS files or hardware-specific.  So by applying the “diff” tar ball to a pristine OS install on VMWare, only updated and non-hardware files were copied.

It worked… almost.  As it turned out, the “pristine” FC2 install on Virtuozzo had more packages installed (specifically httpd) than my pristine FC2 install on VMWare.  So httpd was not copied onto the new system.  Even worse, the RPM database was copied over, so the new system thought that httpd was installed.

So to really get rapid system restoration working with tardiff you need to make the additional step of ensuring that the packages of the pristine OS install on the destination system match the packages of the pristine OS install on the source system.

The summary is that with some preparation, it is possible to do rapid system restoration or duplication, even if the destination has different hardware than the source provided you:

  • Record the list of packages of a new OS install on the source system
  • Create a tar ball of the new OS install on the source system
  • Create a tar ball of the completed source system

With this advance legwork, you can restore or duplicate a system to a virtual machine in under an hour.

2 responses to “Experiments in Rapid System Restoration using Tardiff

  1. Question: does the link to tardiff.pl comparison tool go to the version modified by Tim Schwenk? That page doesn’t say.
    And a statement: Tim Schwenk is another cool TCG-er!

  2. The link goes to the original tardiff.pl tool. Unfortunately, to get it to run under cygwin I did a horrible hack-and-slash update to the tool (I know, using tools under cygwin to manipulate tar balls created in Linux… but it does work!). In the process I actually removed features of the original. However, if there’s interest I’ll clean it up and release it somewhere…

Comments are closed.