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.

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!

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.

1 members found this post helpful.

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

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.