LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   How do I recover the / root filesystem from backup? (https://www.linuxquestions.org/questions/linux-newbie-8/how-do-i-recover-the-root-filesystem-from-backup-805855/)

Earwig 05-04-2010 09:46 AM

How do I recover the / root filesystem from backup?
 
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.)

acid_kewpie 05-04-2010 09:52 AM

/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.

Earwig 05-04-2010 09:56 AM

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

wmakowski 05-04-2010 10:25 AM

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

Earwig 05-04-2010 11:42 AM

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

Earwig 05-04-2010 12:04 PM

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

tredegar 05-04-2010 12:57 PM

Quote:

I don't yet need to do a recovery, this question is in anticipation of such a requirement, so there is no panic.
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.

Tinkster 05-04-2010 01:05 PM

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

jiml8 05-04-2010 01:42 PM

Quote:

Originally Posted by wmakowski (Post 3956959)
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.

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...):

Code:

rm -rf /mnt/sda6/back/backup6
mv /mnt/sda6/back/backup5 /mnt/sda6/back/backup6
mv /mnt/sda6/back/backup4 /mnt/sda6/back/backup5
mv /mnt/sda6/back/backup3 /mnt/sda6/back/backup4
mv /mnt/sda6/back/backup2 /mnt/sda6/back/backup3
mv /mnt/sda6/back/backup1 /mnt/sda6/back/backup2
cp -al /mnt/sda6/back/backup0 /mnt/sda6/back/backup1
rsync -a --delete --exclude /tmp --exclude /home --exclude /media --exclude /proc --exclude /sys --exclude /mnt --exclude /var/tmp / /mnt/sda6/back/backup0

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

Code:

#!/bin/bash
dirname=`date`;
mv /mnt/sda6/back/backup6 /mnt/sda6/back/weeklybackups/"$dirname"

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.

jiml8 05-04-2010 01:46 PM

Quote:

Originally Posted by Tinkster (Post 3957126)
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

Rsync is ALWAYS quicker than a reinstall.

Tinkster 05-04-2010 02:18 PM

Quote:

Originally Posted by jiml8 (Post 3957196)
Rsync is ALWAYS quicker than a reinstall.

... if your network is fast enough.

tredegar 05-04-2010 02:24 PM

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.

jiml8 05-04-2010 02:32 PM

Quote:

Originally Posted by Tinkster (Post 3957237)
... if your network is fast enough.

...which any contemporary LAN will be.

tredegar 05-04-2010 03:02 PM

Quote:

...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" :)

Tinkster 05-04-2010 03:17 PM

Quote:

Originally Posted by jiml8 (Post 3957257)
...which any contemporary LAN will be.

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

jiml8 05-04-2010 04:27 PM

Quote:

Originally Posted by tredegar (Post 3957286)
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 am in the US, which means that the readily available and very inexpensive LAN hardware is comparable to that found in Europe or most parts of Asia, and the internet bandwidth/speed is somewhat inferior to that commonly found in Europe and somewhat superior to that commonly found in Asia.

If OP is from Africa, the Pacific Islands, or rural portions of South America, then more than likely the networking capability that - yes - I DO take for granted is not readily available. Otherwise, it IS readily available.

Given that OP used the phrase: "a directory elsewhere on the network", I presume he is not using dialup. Therefore, if his network is newer than roughly 30 years old, he has a data transfer rate of at least 10 Mbps pretty much regardless of what architecture/protocol he is using.

Therefore, rsync will always be faster than reloading.

But, yes. This is veering off topic.

Earwig 05-04-2010 06:50 PM

Many thanks to everyone! The answers are really helpful. I have scoured every word, and will take careful notes from here and put into practise. Thanks to wmakowski and jiml8 for the dirs to exclude. Thanks jiml8 for the backup script, I can understand that. Thanks to tredegar for the useful reply, and I agree the data is the most important thing, but these systems are already in production and are quite detailed to install and configure and are used by engineers (I'm their linux sys admin as of fairly recently, and so far I haven't had a problem), but I ought to make sure I could recover then if I had to! I have now also updated my profile a little as suggested! Thanks to Tinkster for suggestion of installing from scratch and recovering /etc, it is an alternative if necessary.

jiml8, the only bit I did not understand was when you said "part 1.5 and part 2", I could not think what that referred to.

Recovering the / filesystem from backup is interesting, due to the fact that the OS is created by *installing* rpm packages, rather than copying in the files of an rpm package, and that does make a difference when considering the recovery from backup. I kept wondering how other people would do a recovery, and I am glad I have asked. I reckon I could manage now, although I must actually test it out. Thanks to all!

jiml8 05-05-2010 01:57 AM

Oh, by all means test it out. Abso-freaking-lutely.

But you'll find that it's quite easy.

I don't even have a "recovery" script; that's ad-hoc and I just use the console and the rsync -avz command.

As for part 1.5 and part 2, grub's boot code does not fit into the drive's MBR; it is a bit too big. Part 1.5 is the part of the basic boot loader that grub places on the drive outside of the MBR area. Grub places it in an absolute location on the disk and hard codes that location into the code that goes into the MBR so that it can properly jump at a time when no OS is running.

Part 2 contains the information to deal with the specific filesystem found on the boot partition. Grub is multi-platform, and it therefore has to be able to handle whatever filesystem it is given. So part 2 is loaded IN the filesystem, but its absolute location on the HD is provided to the boot loader code so, again, a jump can occur to that code, since the filesystem must be known in order to read things like the kernel off of it.

Earwig 05-05-2010 07:52 AM

jiml8, you say at one point to exclude /proc /sys and also /dev /var/run and /tmp in the / backup. However, in your daily backup script you have forgotten to exclude /dev and /var/run. I'm just being picky! :)

(It was all really helpful though, and thanks for the bit about part 1.5 and 2 of grub.)

jiml8 05-05-2010 01:50 PM

Yeah, you are right. I guess I'm collecting that. It isn't necessary; /var/run contains nothing but lockfiles and pid files for running processes. Those are supposed to be deleted when a process shuts down and recreated when a process is restarted.


All times are GMT -5. The time now is 09:15 PM.