Suppose I have a good backup of the / root filesystem. How do I recover the / root area? Suppose I have modified the root filesystem, perhaps I do an update some of the packages and regret it, and I want to get back to the system at the time of the backup. How do most linux people recover the root area of a system from a backup?

1) I wondered if I might put a System Rescue CD in and boot off it?
2) And then NFS mount the directory containing the backup? -In my case, I have made a good backup using rsync, to a directory elsewhere on the network.
3) And then, still booted off the System Rescue CD, mount the partition that contains the / root area in question?
4) Would I then clear or empty or delete the contents from the / root partition?
5) And then copy across all the files from the backup into the / root partition?

I ask these questions because of the (very nice) way linux OS is built entirely from packages... Am I being too complicated? (By comparison, I can see it is easy to recover user data.)

If, instead, I simply recovered the backup straight onto the updated root filesystem, I wonder what it would look like if I then tried to verify it with "rpm -Va", for example? Surely, all the packages would fail the verification, because it would think it has a later version of each package from the update, but the actual files would have been overwritten by the earlier version from the backup?

Thanks!

(I don't yet need to do a recovery, this question is in anticipation of such a requirement, so there is no panic.)

/root is not "interesting" at all, it's just a home directory in a different location. And installing packages will not affect it in any way usually. Just recover your files from your backup media and replace just like any other trivial location, no need for boot disks or anything at all.

Correct. I didn't mean /root. I meant /.

It is possible to recover the entire / filesystem from a rsynced copy using the method you described. I've done this before when upgrading a hard drive. I've also used rsync to create a diskless environment on a server. Make sure to use rsync -a to make the copy so all permissions and ownerships are maintained.

There are only a few things that I can think of to look out for in the restore. Someone correct me if I'm wrong, but the only directories to exclude would be /proc and /sys. Another thing you will need to watch out for is your boot loader and fstab. Especially if you have any changes to your partitions. You may have to perform a grub-install to get grub to the master boot record. If partitions did change you would also need to make adjustments in grub.conf.

As far as packages being out of sync. There could be a few inconsistensies if you overwrite an existing installation, but if you went to a reformated partition it would not be an issue.

-----
Bill

1 members found this post helpful.

Many thanks! In which case I will give it a go...

I'd be really interested to know if anyone else has any other method they have used?

This is very sensible. There's no point in taking a backup unless you are sure you can use it to recover.

The first time I took a backup, it failed when I really needed it [I was using cpio and a tape drive, I eventually recovered it, but it was a PITA, and I wished I had tested it].
I learnt my lesson

cp -a source destination works well for a one-off backup.
Using rsync is a much better idea if you are going to be updating your backup because it is a lot faster than cp [minutes instead of hours]. rsync has many options, be sure to read and understand them properly.

Then test your backup / recovery strategy by pretending you have had a catastrophic failure and attempting a restore to a spare partition.

Make sure you can boot your backup. Then make a note (on paper, I have a useful "linux notes" book) of what to do when you need to do a restore. Otherwise, when you need it, you'll perhaps have forgotten just what method you used to take the backup and what you need to do to restore it.

Don't forget that it's a good idea to take a backup of /home whilst nobody but root is logged in (and not by using sudo ...)

If I backup / then I boot from a live CD, or linux on a different partition from the one I am backing up so the filesystem I am backing up is not in use (which means things may be changing, and inconsistencies may crop up that may come back to bite you).

What do I really do now?
I don't backup / because a reinstall takes, maybe 90mins, and I don't kill my system as often as I used to (it has been a few years now).

I do regularly backup /home where I have a collection of scripts and personal HOWTOs that are useful for getting my (next) distro to behave as I like it. My personal files are much more important to me than the system files.

1 members found this post helpful.

Depending on how (well) you separate system and user data you
may be better off (quicker) to install the box from scratch and
restore /etc from backup to preserve the machines "identity".

Just a thought.



Cheers,
Tink

Also exclude /dev and parts of /var (notably /var/run).

You might or might not want to copy back /tmp; I usually don't.

@Earwig:

You can very often do a recovery of / without rebooting and without using a recovery CD or a Linux Live CD. It just depends on whether, after whatever you did, you have enough functioning system left to do that. In the past, I've made some serious mistakes while working on the system, and just rebuilt it on the fly using rsync and kept on going.

Once I managed to delete most of /usr/bin (whoops!), however I managed to get a bash shell pointed at a backup copy of /usr/bin and used the commands in that backup copy to restore /usr/bin without rebooting.

If I want to genuinely roll back, then yes I would reboot into a Linux Live CD, delete the entire /, and then copy it in from the backup. After deleting /, since I don't attempt to backup /proc, /sys, /dev, /var/run, or /tmp, I'd have to manually create those directories before rebooting back into the system. Also, typically, I'd have to reinstall grub so that part 1.5 and part 2 would be properly found. But the whole thing goes quickly and easily.

In the not distant past, I had a hard drive failure underway. During the period of time when I knew something was going wrong, but wasn't sure what, I had to recover my system 4 or 5 times in just a few hours, while I diagnosed...Drive? Controller? Cable? Cable adapter?

The point is that I COULD recover my system 4 or 5 times in just a few hours, quite easily, in fact.

Here is my daily backup script for my system, that runs in the middle of the night as a cron job (there is another one for /home...):

and here is the script that gets run once a week in the wee hours of Sunday morning (again a cron job)

Every now and then (maybe every 6 months or so), I wander into the /mnt/sda6/back/weeklybackups directory, choose a recent weekly backup, tar and gzip it, then move it to an archival location and delete all the weekly backups.

I do similar things with /home, but I do it separately.

Following this mechanism gives me the capability to roll back to any specific day of the last week, or any specific week of the last several months, or - for still older stuff -to specific snapshots, as required.

Works pretty well.

1 members found this post helpful.

Rsync is ALWAYS quicker than a reinstall.

... if your network is fast enough.

I just remembered, that for those with an aversion to the CLI, there are also flyback and backintime for linux that were inspired by Apple's "Time Machine" [Search on them].

Not available in the repositories for my ("old", but fully functional) linux distro though, and I really don't need them, so I am not that interested, but the OP might be.

...which any contemporary LAN will be.

This is veering off-topic, but please remember that LQ is global, and many members do not have the resources, hardware or finance that you are apparently comfortably accustomed to.

You don't post even a vague location in your profile. Perhaps if you did, we'd understand better "where you are coming from"

I shall call you rabbit, for you are jumping to conclusions.