20

I am familiar with using rsync to back up various files from my system but what is the best way to completely restore a machine.

What I have tried in the past is:

  1. Do a basic format/reinstall from the Fedora install disks
  2. Make sure networking is enabled
  3. Copy everything from rsync backup over the top of the newly installed system

This way sort of works but I do not think every package that was installed works 100% afterwards.

I want to be able to restore my system with the minimum amount of effort and everything work the same as at the moment the backup was taken. Also if possible install to other machines and essentailly have two machines with the same packages and data.

Improve this question
2
  • When you say you want to install on other machines do you mean other 'identical/ machines or more like a desktop and a laptop?
    – Ichorus
    Commented Jun 4, 2009 at 17:45
  • hardware would be different but on want the same software packages on both
    – Simon Foster
    Commented Jun 4, 2009 at 17:49

13 Answers 13

Reset to default
17

Here's what I've done (this assumes a single disk, at /dev/sda)

  • use dd to backup the MBR and partition table: "dd bs=512 count=1 if=/dev/sda of=/backups/sda.layout"

  • use rsync to copy the entire thing with something like: "rsync -axvPH --numeric-ids ..."

On restore I do this:

  • boot the target machine with sysrescuecd, I will typically have the 'sda.layout' file on a USB stick.

  • restore the MBR/partition table with dd: "dd bs=512 count=1 if=/path/to/sda.layout of=/dev/sda"

  • Use partprobe (thanks commenter Mark) to get the kernel to re-read the partition table.

  • Mount all the various partions under /restore/. I make the mount points identical under restore, so if I have /boot, /var on my source, I end up with /restore/boot, /restore/var, etc.

  • use rsync to restore the entire thing.

Improve this answer
5
  • 3
    I have done this several times and has the advantage of using standard linux CLI commands.I use rsnapshot, a perl script around rsync to make backups to a central server. Then rsync the whole thing back after booting from sysrescuecd and dd'ing the partitions table. BTW, "partprobe" will re-read the partition table
    – Mark Porter
    Commented Jun 4, 2009 at 19:06
  • OK, this may be seen as a vile hack but since you can have the kernel reread the partition table by issuing a sysctl() like fdisk does, you might just as well have fdisk - which unlike partprobe is always there in my experience - do it: fdisk /dev/yourdisk <<EOF w EOF
    – Bernd Haug
    Commented Jun 4, 2009 at 20:44
  • Thanks for everyones suggestions, I knew there must be a better solution out there. Will try these suggestions and see what works best for me.
    – Simon Foster
    Commented Jun 4, 2009 at 20:50
  • 3
    Don't forget the count with dd! "dd bs=512 if=/dev/sda of=/backups/sda.layout count=1" and "dd bs=512 if=/path/to/sda.layout of=/dev/sda count=1"
    – Steven
    Commented Jun 5, 2009 at 14:20
  • @Steven: Crap! Thanks for the catch. Can I vote a comment up?
    – kbyrd
    Commented Jun 5, 2009 at 15:03
6

I never clone systems entirely. You never know what may change, and your system cloned image is already out of the date the moment one change occurs. The best way to do it is to establish a procedure that lets you produce functionally identical systems. One possibility is something like Kickstart, or AutoYaST or similar tools. Keep good backups of your configuration, and ideally use a configuration management system such as Bcfg2, Puppet, or CFEngine to configure everything instead of doing it by hand. Then when you need to create a new system that's similar to another one you have, or recreate an existing system, it's a simple and well-defined procedure.

Improve this answer
3

It would take more effort up front, but Kickstart and Revisor allow you customize an installation and use it on other machines. You can include customized versions of your settings files.

You may also want to consider keeping your home directory on a separate partition. You can leave that partition alone while doing a clean install on another partition.

Improve this answer
2

Grab a copy of system recovery cd, and after your initial minimal install, boot from it, mount and chroot into your disk, and then do the rsync. After it's finished you may need to run update-grub to get it booting from the correct boot device and kernel.

Improve this answer
2

I've always thought that the Gentoo way of installing a new system (from backup or otherwise) was the best due to its simplicity.

  1. Create working, minimal system.
  2. Load the working system as a hard drive in a livecd.
  3. Tar the filesystem up and save somewhere.
  4. Load the target system with a livecd.
  5. Prep the target hard drive and mount it.
  6. Untar to mounted hard drive.
  7. Enter chroot.
  8. Set up bootloader and other system-dependent things.
  9. Reboot and go.
  10. Install new software/copy user folders/add other files as necessary.
Improve this answer
2

Try clonezilla live cd. You can boot into a live session and image your machine without having to install anything. You then have the option to store the copy of the image on a network share or remote machine and so on.

Improve this answer
0

If it's the exact same machine, I would just use dd to create a disk image, then reimage it as necessary (possibly changing some configurations afterwards if appropriate).

If you're switching hardware, I've had some success creating a tarball or complete rsync backup of the file system root. I'm not sure why you'd need a complete install first - as long as you take a full backup, the base Fedora install shouldn't be a prerequisite.

Improve this answer
0

Your procedure can cause numerous problems, and should be avoided.

There are two primary recommended ways to go about this, and a third if you are purely trying to build a development environment.

Imaging

If the hardware that you will be restoring TO will be the same, or similar enough, use a disk imaging tool to make a copy of the entire hard drive or array. When you wish to restore, simply re-image the machines in question with this image. If you image to multiple machines, be aware that you will need to update any machine-specific settings on the other devices (hostname, static IP address, etc...) such that they do not conflict with one another.

To do the actual imaging, I would recommend any tool or product that can clone hard drives.

Configuration/Home Directory backups

On your primary machine, regularly back up (with whatever method you like) whichever of the following directories (or others) you require:

/home - All user personal settings, documents, and files
/etc - configurations
/opt - special software not installed via the package manager
/usr/local - special software not installed via the package manager
/var - logs and such

When restoring, re-install the OS on the machines in question, and then copy each of these (or the relevant files only) to its proper location.

Virtual Machines with snapshots

Create a virtual machine in VMWare (or whatever else you prefer). When it is configured as you wish it to be, create a snapshot. This snapshot can then easily be restored to any number of new or existing virtual machines.

In general, you should only back up data and configurations (however you define these). The OS and software can trivially be rebuilt at any time: only your own content is valuable. If this setup is for development, and you need to ensure an identical environment (as opposed to simply getting things working again), then snapshots in a virtual machine are really your best bet.

Imaging is the brute force solution. If you can, just back up your data, and don't worry about the OS itself. Trying to restore it entirely is asking for trouble.

If you can clarify what your final intent is here, I can provide a more detailed solution.

Improve this answer
0

Since you say "hardware will be different", SystemImager can come very handy.

It is just a bunch of wrapper scripts around PXE and Rsync. Therefore the "backup" that it creates is just a complete directory structure of your backed-up Linux server. You can "cd" into this dir and change stuff around as you feed. (SystemImager manages changing Network settings on its own when you push the image out.)

You can chroot into your backed up server and run yum or apt to install software before you push the image out.

Edit: You can take a look at the SI script that creates partitions/logical volumes and modify it according to the disk size of the target machines. You can also add/remove kernel modules.

Improve this answer
0

I've had very good luck with Mondo Rescue. Basically it backs up all your files and partitions to a bootable CD for later use. It can handle changes in partitions and drives.

http://www.mondorescue.org/

Improve this answer
0

partimage can help with this

Improve this answer
0

  • The safest way is to clone the whole disks or at least the relevant partitions and restore them using a Live CD.

  • Another more space efficient method is to use dump (xfsdump for XFS), but in this case you'll have to recreate (format) the partitions by hand. Don't forget to create them with the same parameters, especially UUID and LABEL.

  • You can also use tar with the --xattrs parameter to save each file's extended attributes.

Improve this answer
1
  • 1
    Modern rsync on Linux has -X and -A for extended attributes and ACLs respectively.
    – kbyrd
    Commented Jun 4, 2009 at 18:02
0

partimage and partclone (parts of Clonezilla) are useful utilities for creating full system images.

As you identified, full system images are not necessarily system portable: usually because of device names.

It may be as simple as re-installing GRUB (preferably on a separate /boot partition) and the MBR after imaging (with e.g. a LiveCD).

Another approach is to use Configuration Management tools to define policies which are applied to a baseline image (like Vagrant base boxes); and separate data backups into block and/or object storage (EBS/S3, Openstack Block Storage / Openstack Object Storage)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .