Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Reminder -- RAID 5 is not your friend



Looking at a little raid 1 details, I noticed something I had not seen 
before: doing backups by splitting the mirror. Specifically, say one has 
a simple Linux box with a pair of software raid 1 disks in it.

One could set up the raid to use a third disk, one that is external SATA 
or USB. Add it to the mirror and the mirror "rebuilds", giving you a 
complete copy of the entire system. Now split it off from the mirror and 
you have a consistent snapshot of the entire box on that one external 
drive. Do some magic with grub and it might even be sensible as a boot 
disk for disaster recovery. Take it away as your off-site backup. 
Further, set up a different external disk to do the same thing and now 
you can ping-pong between the two off-site backups, always keep at least 
one backup drive off-site and you will be pretty safe from those pesky 
"act of God" hazards.

Obvious downsides:

- Rebuilding onto the backup will beat on your working disks, but most 
backup techniques have some element of that. The nasty inefficiency here 
is rebuilding copies not only your files (new and unchanged) but also 
copies all your unused space.

- Rebuilding onto the backup will be slow, but if you are ping-ponging 
with at least two disks it need not be any faster than the period of 
your backup: if you are attentively doing a backup every day, it is OK 
to spend 23-hours doing the rebuild; if you are just doing a backup once 
a week, the rebuild can run for 7.9-days. Actually, it is probably good 
to do the rebuild as slowly as possible to not compete with the useful 
work work of the system.

- Works easily with single disk sized boxes (upto 1.5 TB these days) but 
bigger setups get cumbersome.

- Recovering from a backup will be a bit like recovering from a loss of 
power. Some programs (databases) will get upset. Possibly poke those 
programs to finish their current IO before splitting the array, then 
tell them to resume IO.

- The off-site backup won't be encrypted unless the running copy is 
encrypted. You might not care about this, but if you do it is possible 
you want your regular disks to be running encrypted anyway--so that 
disposal of dead disks is easier.

- Little ability to browse back in time with these backups except via a 
large pool of backup disks (unless you have some other snapshotting 
within your server setup).


Anyone have experience with this?


Thanks,

-kb







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org