Restore linux backup to new hardware

If the backup procedure as defined was followed would this be manifestly the same as taking the physical drive out and putting it in the target machine?

Pretty much. If the new system accepts the same type of drives, then you could probably just move the drive over and most things would work without any other work.

What happens with differing hardware devices, does any hardware not present in the original need to be set up manually after the backup restore on the target machine?

Maybe, Keep in mind that if you use a stock kernel as part of most major distributions then the most hardware usually will be supported out of the box. If you move the drive from one box to another then things will probably just work.

For Linux the thing most likely to break for servers without a GUI is storage. So if your old box was IDE, and your new box is SCSI, or SATA then your fstab, boot-loader and so on needs to be changed to reflect the new partitions.

Systems used for desktops are a bit trickier since the video/sound/wifi devices tend to be less well supported, but even then the system still will be pretty easy to get booted, you will just have to adjust the configuration for software that uses those devices.

Why is copying the MBR and partition table an important step?

It isn't, it is just there to make the partitions on thew new system identical. You could completely reparation the new drive however you like and adjust your boot-loader and fstab on the new system after you have copied files and to reflect your new partition structure.

If the hard drive already has a working installation of the target OS, you can usually just restore over the top of it and reboot, although you do have to make sure that the grub.conf and /etc/fstab do not have drive labels or UUIDs in there (if they do, it's usually easier to just specify the device name in case you have to restore again later). I would exclude /boot from the restore (and possibly also /etc/fstab to avoid the above).

If the system is already bootable you do not need to install GRUB again, if it's a new hard drive that hasn't had a full installation on it you need to ensure it knows where to find the kernel, so a simple grub-install hd0 (or whichever hard drive) should do it.

Then, reboot and cross your fingers.

The procedure described in that thread is usually called a Bare-Metal Restore. As the name says, it means restoring the original system (often on completely new hardware) starting with an empty harddisk. It has some advantages, most notably that you get an exact copy of the original, including files in more exotic directories that you might otherwise overlook. But bare-metal restore has some drawbacks, too:

1. It takes more space on the backup media. Your backup tapes might get clogged with twenty identical copies of your operating system, and your nightly backup run might mostly consist of copying stuff that you could easily reinstall from CD if needed.
2. Your new server might not be identical to the old machine. Maybe you have SATA now where the old hardware had SCSI, maybe the graphics card is too new for the old kernel, that kind of stuff. As Zoredache says, today's stock kernels exhibit this problem only very rarely, but maybe the original reason to go for a bare-metal restore was that your system is running a non-stock self-compiled kernel...
3. Since you don't have a running operating system when the restore starts you need a second system to jumpstart the process. These days this is almost always some USB or live CD with all the required tools, but i remember the days when we used to create rescue floppies for that purpose, crossing our fingers oping that they would work when we needed them.

Alternatively, you can choose to restore only non-OS directories, for example all home and application directories. Then restoring your system becomes a two-part process: 1. installation of the operating system on the new machine, preferably using an automated installation method like Kickstart, followed by 2. Restoring the needed user and application directories from the backup medium. This avoids the drawbacks of bare-metal, but comes with a drawback of its own: you'll have to be able to define the backup directories. On a newish server, this might not be a problem, but if your system is some old piece that was once set up by that guy who is no longer with the company and that nobody has dared touching the last two years, that can be a serious issue.

To my knowledge, the only problem when restoring a server on another one (even Physical-to-Vistual or Vistual-to-Physical) is booting the system. when the system is booted up, everything is the same as before and all of the applications and servers, should work properly.

In order to boot up the system, you can built necessary drivers, which are mostly related to storage (SCSI, RAID, filesystems like ext4, etc.) in the kernel. this solution needs recompiling the kernel which might not be trivial.

Another solution would be using an Initial RAM disk or InitRD. You can list needed drivers (which are kernel modules) and make an initrd that contains these drivers. Nonetheless, this solution needs some insight.

If you are as lazy as me :D you can use the following procedure:

1. Install a distribution as similar as possible to the backup or image you have got, on the destination (where you want to restore the backup). As a point in case, if you have a backup of a Centos 5.3, you should install Centos 5.3 on the destination or (if you do not have the Centos 5.3) Centos 5.4; even a RHEL 5.4 sould do. However, a Slackware 13.1 or Debian 5.3 might not be suitable!

   • The only thing that we need is the kernel and the initrd; therefore, you should keep things that affect them (kernel and initrd) like the backed up system. For example, you should use the same filesystem (ext4, XFS,...) and the same software RAID (RAID 0, RAID 1, RAID 5) if any.

2. Keep a copy of the kernel and the initrd of the newly installed system. As an illustration, using the following command to create a compressed tar file from /boot on an external storage mounted on /mnt/external_storage would be sufficient: tar czvf /mnt/external_storage/new_boot.tar.gz /boot

3. Restore your backup or image on the destination.

4. Restore the /boot copied from the installed system:

   • Boot up using a Live CD
   • Mount the root filesystem of the restored system; for example: mkdir -p /mnt/restored ; mount /dev/sda1 /mnt/restored
   • Mount the media containing the copy of the /boot from the installed system; for example: mount /dev/sdb1 /mnt/external_storage
   • Restore the /boot copied from the installed system; for example: cd /mnt/restored ; tar xzvf /mnt/external_storage/new_boot.tar.gz

5. Adjust configuration of lilo or grub, if needed.

6. Cleanup /etc/blkid.tab of the restored system if present; for example: > /mnt/restored/etc/blkid.tab
7. Unmount filesystems and reboot; for example: cd / ; umount /mnt/restored ; umount /mnt/external_storage ; reboot

The above mentioned procedure is what we have been using at work for a year now.