I want to pretend I've had a total disk failure. I've got a brand new disk. And I've got a full tar backup created with the following tar command:
Assume that I'll create the previous partition structure from memory. (Ideally I'd like to be an idiot that can't remember that.)

This question is for a new Debian Wheezy install.

So, how do I do this?

And even better, is there a webpages somewhere that tells me how to do this?

FOR STARTERS and for context, let me make an uninformed guess.

1. Boot into any other system on my disks
2. build the desired partition structure on the new disk
3. cd to the / partition on that disk
4. tar -xzvpf /media/backups/fullbackup0.tar.gz
5. rebuild GRUB2 somehow
6. update the MBR somehow (done by reinstall-grub, I think)

But this likely won't work since /etc/fstab (and others???) have UUID's set to the previous (pretend broken) system. So how do I reassociate to the new UUIDs?

If I can do that, is that all I need to do?

Thanks for your help.

I haven't used tar for fullsystem backup, but I use rsync for that regularly, and I have restored it many times.

You need to exclude some more directories, and you also need to include a few files in /dev. Include must come before exclude.
You restore it from a LiveCD/other installed system, as you wrote it. Then you need to
1. change uuid in /etc/fstab. Run 'blkid' as root to find out the new uuid.
2. regenerate grub's configuration file. Usually by running 'update-grub'.
3. install grub in mbr.

You said you have other system on the same machine. Depending on which distro is "owning" mbr, you might need to run update-grub on that system instead, and don't install grub in mbr.

It doesn't matter if you create the same partitions or if you make it different. Just mount all partitions where they should be in the new system before restoring the backup. At least this is true for rsync. As I haven't used tar for this I can't say for sure. You better test your backup before your disk fails.

Untried - others will no doubt refine it.

.

Before I would put too much trust in that, I would check if gzip writes a temp file. If it does (and I have a notion it does), then you'll need a lot of tmp space to sort out a zip that size. That could scupper a recovery. In that case you could pipe it through split (man split). You may also need to exclude dev, except for basic devices.

I think that cpio is a better option for such full system backups than tar is. The way tar handles things varies from version to version, and really isn't designed for this.

You can also use rsync for backups.

@H_TeXMeX_H: The traditional cpio file formats have various limitations, including file size limitations that you might actually hit on a modern system so I would not advise anyone use them.

The two most common cpio formats are odc and newc. Both of these are old, effectively legacy, formats and as such have little place in backing up modern systems. odc, an old posix standard cannot have individual entries larger than 8Gb (personally I have media files bigger than that). newc, never a posix standard but faily ubiquitous nonetheless (not least because it is the archive container within most rpm files), can actually only hold smaller files (2Gb) despite being a newer format (it is less limited than odc in other areas such as pathname length).

A more modern posix archive format is pax (an extension of the tar format), which can be written by modern tar versions and has no practical limits, e.g. individual file entries can be 9Eb in size. Standardisation means there are no longer any worries about format variance for tar versions that support pax (GNU tar, BSD tar, Star, etc.) and yes tar is very much designed for this type of backup.

If one really wants to use cpio for backup, they have three options: use BSD Cpio, which can write pax archives; use Heirloom cpio (from The Heirloom Toolchest), which can also write pax archives or use non-standard extensions to the traditional cpio formats (e.g. SCO extensions to newc allowing file entries of up to 9Eb); use Afio, which can extend odc past practical limits. I would avoid GNU Cpio at all costs since it supports neither pax nor extensions to odc or newc, making it largely useless for modern backup. I'd also add that GNU Cpio appears to be in maintenance mode, receiving tiny updates and fixes only. If you were to judge the cpio and tar wars by only the GNU utilities, then you would have concluded that cpio had been beaten to a pulp.

@linuxStudent11: I would not use external compression on a critical backup.

The easiest is to use dd from a live cd and make a bit-for-bit copy of the root drive to a backup drive. The tar/rsync/cpio method is more relevant if you are cloning to a smaller size ssd drive. dd will work for a same size or larger drive. In case of the latter, just use gparted to resize the partition to fill the entire drive.

Assuming you are backing up to /dev/sdb1 and /dev/sdb1 is mounted on /mnt/new:

Fix /mnt/new/etc/fstab with blkid - this will print out the UUID for each partition in the system. Just copy and paste the UUID for the root drive.

grub-install --boot-directory=/mnt/new/boot /dev/sdb

You can also use chroot to fix the MBR & grub:
If you would like to keep the same network device name (eth0) edit /mnt/new/etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x8086:0x294c (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Just remove lines which look like this.

Regards,
Stefan

WOW! Thanks for everybody's help on this. It sounds like tar is NOT a universal answer, instead use dd,rsync,apio (as approprate) with variations on grub (I'm using grub2 at the moment). tar looks like its good only for limited local backups.

I'll be saving this thread in my websaves dir. Thanks again everybody.