Filesystem backups - opinions??
 

Hi all,

I'm fairly new to the linux sys-admin world and am currently working my way towards LPI-1. I think this is probably more of a 'server' question, in that it relates to setups that are more likely to be servers than desktops.

One of the guide's that I've been reading has commented on the practise of backing up both the MBR (through dd) and also the partition table (through sfdisk).

I'm just interested really, to see if making full backups of these is commonplace or is it considered excessive?

Many thanks,

Paul

It depends on how you want to restore. Getting this information would allow you to do a "Bare Metal Restore" (BMR) as you could take a new disk (or even a new server) and put the information on the new disk exactly as it was on the old disk then restore your backups and boot up. Conventional backups don't include the boot sector so you might have to reinstall the base OS to get one populated then restore your backups.

However, there are tools out there that will create bootable restore media for you that include the boot sector. Mondo is one used by many.
http://www.mondorescue.org/

If your systems are regular desktops/notebooks/etc., then you most likely have a normal old IBM PC MBR rather than a new GUID Partition Table (GPT). In which case, something like the following dd command to backup the boot sector is sufficient:
dd if=/dev/sda of=some-drive.mbr bs=512 count=1

I wouldn't call that excessive. Since I've learned about MBRs and drive partitioning, I try to keep backups of MBRs of each of my drives, and I would recommend that others do this as well. That's partly because I once saw the MBR of a failing HDD mysteriously wiped out, and partly because any OS installation that touches the boot process will overwrite the MBR.

And as MensaWater said, backing up the MBR will also allow you to restore a full system backup to a new drive setup without having to reinstall the boot loader (or worse, a full OS).

I take a contrary view.
What's important is the data. Secure that.

Restoring partition tables and especially the MBR is likely to do more damage than good. On the rare occasions when needed, I prefer to recreate and restore (the data) rather than rely on potentially out of date partition structures.

Nobody suggested NOT backing up data. We said that the MBR can alleviate having to reload the OS before restoring data. A data backup without the MBR can be recovered but not until you have something to recover it to (e.g. another system or a reload OS on the original).

Also I noted that Mondo can be used to make an exact duplicate of your OS on the same system, a new disk or even another system. You'd still want to have backed up the data.

That's only true if you write an MBR with a partition table that doesn't match the actual partitions you have. Even then, the first sign that you messed up would be filesystems that look corrupted and can't be mounted (and you can only cause irreversible damage if you try to make new filesystems over the existing data).

To the OP: If you're interested in learning more about MBRs and what you're actually backing up, have a look at this Wikipedia article on the subject. If you want to see this stuff in action, first make sure you're familiar with dd and know how to backup and restore an MBR (with bs=512 and count=1, as I showed in my previous post). Then, on a boot disk or something you can try tools like fdisk/cfdisk (or, if you're really adventurous, you can use a hexadecimal editor like bvi to modify the MBR by hand) to modify your partition table. Note that these tools do nothing to your actual partitions and data (it's safe as long as you don't try a `mkfs` on your drive while the partitions are remapped). And then just restore your MBR with dd or fdisk/cfdisk.

Right, thanks for the pointers PehJota. Nice to see it provoked a debate!


Paul

I don't back up MBRs and partition tables but I do back up data in several ways -- to an extent that most people would consider excessive -- so it's not laziness. The rationale is that HDD failure will, on average, happen long enough after installing an OS that it's time to re-install to get rid of the cruft (of my own doing -- this is Linux, not Windows!) or for a later version and I can live with the system being down for as long as it takes to get the essentials of a new OS installation usable -- especially as I a) make a log of installation and subsequent changes that can be used as a template for the next installation and b) keep a repository of non-distro source code.

That rationale would not apply to backing up a mission-critical system such as a server used by many people when time to complete disaster recovery is critical -- in which case it is prudent to keep (ideally identical and tested) replacement hardware components in stock.

Interesting. I've seen the argument about fresh install when doing upgrades to get rid of cruft (and in fact am a proponent of it) but never have seen it as an argument for doing that after system failures. Even non-mission critical systems often have lots of users (DBA, developers, testers, QA etc...) so extended downtime is often deemed unacceptable. Also many dev/test/staging systems are used as preambles to what will later be installed in Production (mission critical) systems. As such having something newer in those pre-production environments than one has in Production is apt to insure you'll end up doing testing and analysis that works fine in pre-prod but fails miserably in Production.

Years ago I was on a project team that spent quite a bit of time to prepare for an OS upgrade and then implement it. Our findings were:
1) No matter how carefully we planned there were items that needed to be addressed after the upgrade.
2) The amount of cruft left in place after the upgrade that we weren't "sure" could be deleted was stupid.
Based on those we decided that fresh installs to go to new versions of OS instead of upgrading.

I think the most important thing here is: what do you want to backup on your system? I mean what services are you running on it. It really dramatically changes the scenario of the backup/restore process. (simple data/files folders, system users, application config files)
It can happen that you don't know what do you need to backup. In this case you should find that out.

Next important thing is the environment where is this system running. If it is requirerd to run 24 hours a day or you can handle outages for several hours.

For example in my case I made two scripts. One runs periodically to backup everything that is required and another script which is executed on a fresh OS install and restores it all.

And what is most important - test your backup scenario.

My recent experience:

I always made manual backups of the system and data and mbr on my mission critical machine which was running Kubuntu 8.04. When the motherboard went bad I decided to use one of my test machines as my mission critical machine. That would allow me to wait until I had more money before I replaced the motherboard in my original critical machine.

I could have restored Kubuntu 8.04 onto the test machine. That would have provided me a familiar environment. The concerns would simply have been to get Kubuntu hardware drivers working.

Instead I set up the test machine with a new Kubuntu 10.04 system. Then I restored the data (/home) onto a separate partition. It didn't work very well. Problems with sharing the X display between different logged on users appeared. I think it had to do with SELinux but I didn't want to figure it out.

So I tried several other distributions using KDE. They all had their problems with running Kontact from a second logged in user.

I eventually used Ubuntu 10.04 with Gnome but still using Kontact. That worked pretty well after I deleted the old .kde directories from the restored data. (I keep my email in the $HOME/Mail directory in maildir format so it wasn't stored in $HOME/.kde). Unfortunately the Kontact contact list isn't working because of a problem with the Akonadi server not starting or something. I don't really care.

Then I replaced the motherboard on the original machine. As expected it has problems with the new hardware. I'm not in the mood to fix it yet or I may just install another distro onto that machine. In any case it will not become my critical machine.

So backing up the mbr and Kubuntu 8.04 system did not help when I had to replace the motherboard. On the other hand if the disk drive had gone bad all of that system and mbr information would have made fixing the machine easy.

So backing up the mbr and system is useful if your disk drive goes bad. It will have limited value if your motherboard goes bad.

My current backup strategy is to occasionally back up the mbr and system partitions and to frequently back up the data partitions.

NOTE: Please don't make suggestions about these problems. I am not trying to hijack this thread. I am simply stating how my backup strategy worked and some of its problems when changing hardware and/or distributions.

If your motherboard goes bad it seems your disk should still be OK to retrieve data from even if not to boot from on different hardware.

I've never had a mobo failure that wasn't resolved by replacing with the same model. Also I've not seen that many mobo failures in doing this for over 20 years. On the other hand I lost count long ago on the number of times I've seen disk failures. A lost mobo is a major inconvenience but not quite the catastrophe lost data is. So long as your disk is good you can find a way to get data off it onto a new mobo.

RAID goes a long way to helping insure you don't lose data in the first place. Regular backups go further in insuring that that if you do lose the data that you have a means of recovering it. Disaster Recovery is planning for losing not only the mobo but the entire data center. Everyone should be doing RAID and backups IMHO. For most users losing data is a bad thing. For businesses downtime is nearly as bad as losing data so DR is a way of life.

The problems may have been caused by the configuration files under /home/*/ being incompatible between versions of their respective apps. If it was, a solution is to have the /home/*/ directories specific to the OS (and hence its apps) and to keep "data" in a separate file system which is mounted for all OSes.

For example, if /data were the separate file system which is mounted for all OSes, /home/<username>/d could be a symlink to /data/<username>/ (the name d is conveniently short to type and derives from the common Windows arrangement of keeping data on the D: drive, also "d" for data).

Taking this idea a little further, some of the configuration files under /home/*/ are compatible between versions of their respective apps and it is convenient for the users to have the same configuration regardles of which OS is running. In this case /home/*/.<app name> can be a symlink onto the data file system. This works for me for VirtualBox, KeePassX, Mozilla, OOo and similarly it is convenient to have a single set of template files:

Oops! :redface:

Interesting thread here just popped up - MBR restore trashed the system.
This is just too easy to do.