3

I want to set up a RAID 1 array using mdadm to store backups (I'll be using rsnapshot to do the actual backups). I've read that using metadata 0.9 or 1.0 format with RAID 1 is advantageous because they put the superblock at the end of the device, so that the filesystem can still be read without using mdadm. This seems really appealing for a backup application, because it means that in the event of a RAID failure I can still recover data from the individual disks. However, the Linux RAID Wiki has the following scary-sounding words to offer on the subject:

Putting the superblock at the end of the device is dangerous if you have any kind of auto-mounting/auto-detection/auto-activation of the raid contents; in some circumstances (in the case of blkid: if the superblock is damaged) the raid components could be detected as a valid filesystem (or other format) which may contain outdated data. This will desynchronise the array and compromise the data.

Can anyone clarify what this means and how worried I should be about it? Does it mean that I risk data loss if I put the superblock at the end and list the RAID device in fstab without the noauto option? Or does this refer to other sorts of automation?

0

2 Answers 2

3

So, here's the deal with putting the RAID superblock at the end of a device. When you set up a RAID 1 array using mdadm for backups, using metadata 0.9 or 1.0 format is cool because it puts the superblock at the end of the device. This means you can still read the filesystem without needing mdadm, which is handy if your RAID goes wonky and you need to recover data from individual disks.

But, there's a catch. The Linux RAID Wiki sounds pretty scary when it says putting the superblock at the end can be risky. Basically, if you've got any auto-mounting or auto-detection stuff going on, there's a chance your RAID components could be seen as a valid filesystem, even if they're damaged. This could mess up your array and mess with your data.

So, should you be worried? Well, it depends. If you're planning to list the RAID device in fstab without the noauto option, you might be at risk of data loss if things go haywire. It's kind of like leaving the door open for something bad to happen.

But if you're not doing any fancy auto-mounting stuff, you might be okay. It's all about weighing the convenience of automatic setups against the potential risks of data desyncing and loss.

Hope that clears things up a bit!

2

Filesystem can be read without mdadm in any case if you're using RAID1. Just a little bit more work is needed to read it if the superblock is in the beginning. That need should never happen during normal operation; once you have RAID, you must never access the data around it, so the advantage to not to be able to mount it accidentally is very important. In the properly built system such need won't happen at all; for example, I can hardly remember such need from my own experience.

What could happen? Suppose you mounted your filesystem from one RAID leg, perform some writes. Some data and metadata changes, but it doesn't get reflected in any RAID metadata, so RAID layer can't possibly know something is changed in the media. Then, you assemble RAID again and try accessing filesystem. Both legs look equal for the RAID layer; it will spread reads to both of them. However, metadata are not agree! It's easy to trigger a miserable failure of the most reliable filesystem if used like this. So, you must prevent any accidental direct accesses to the RAID-enabled media around RAID layer, for it to help you to save from disaster — rather than cause a disaster.

I don't get what "backup application" you are talking about. Such access is certainly not what is reasonable to automate. And, RAID is not a backup, it was told so many times, so I don't know what to say, I can't get why people still think that way.

Don't design your storage subsystem for the case when you might need to go around RAID layer. Don't design it for the forensics in mind. Instead, do proper backups to never need recovery. E.g. you may go as far as periodically dump the whole filesystem image to the backup storage (separate from this array). Or copy files periodically. That could be automated and become a backup. And that is what could (and will) save you from the need to recover data around RAID in the first place.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .