[PLUG] Building Ubuntu System With Mirrored Drives

Chaz Sliger chaz at bctonline.com
Thu Dec 13 04:18:21 UTC 2012


Chris,  Thanks for the heads-up on hardware raid.
I did some poking around and will definitely go with software raid.
The whole idea behind the 3rd disk is disaster recovery.  Since you can
periodically swap one of the raid-1 drives in the system with the drive on
the shelf, it gives you the ability to recovery quickly to a point in time.
Q: Have you been able to recover using your rsnapshot data on the usb drive?

-----Original Message-----
From: plug-bounces at lists.pdxlinux.org
[mailto:plug-bounces at lists.pdxlinux.org] On Behalf Of chris (fool) mccraw
Sent: Monday, November 26, 2012 8:15 PM
To: General Linux/UNIX discussion and help, civil and on-topic
Subject: Re: [PLUG] Building Ubuntu System With Mirrored Drives

Hey Chaz,

On Mon, Nov 26, 2012 at 10:32 AM, Chaz Sliger <chaz at bctonline.com> wrote:
> I would like to build a system that has removable mirrored drives.

I think you will have a hard time doing this the way you envision.

> I'm thinking of having 3 drives - 2 in the system, 1 on the shelf, and 
> rotating them daily.
>
> Q: Is there a motherboard with good hardware mirroring support?

A: I've found a lot that don't, in my searches.  I'm wondering why would you
want to tie yourself to a specific motherboard? (hardware raid volumes are
very rarely usable on other breeds of card than the one they were made
on--sometimes even same-brand is not enough, it must be same firmware
revision!) The beauty of linux s/w raid is that in 10 years, you can still
put those disks in whatever machine is available (with a "legacy" sata card)
and reassemble the raid.  i have rebuilt my raid on my underpowered (was
VIA, now Atom, both fanless single core machines) fileserver a whole lot in
the past 8 months (due to a failing hard drive that kept working for long
enough to rebuild before erroring out and requiring another rebuild) and the
speed of the rebuild has been pretty close to disk speed despite these
servers not being optimized for I/O - i regularly get 110MB/s rebuilds on
modern 2TB drives (the cheapest ones i could find though!)  plus, my systems
have been pretty usable while the raid rebuilds--they only serve pretty
small stuff except the occasional "fire up virtualbox off a networked drive
to run windows for 5 minutes" and that definitely gets prioritized over raid
rebuilds (you can tweak the settings from the command line for s/w raid
rebuild speed and priority)--so i basically don't notice additional lag
during rebuild (vs the 100mbit network fileservice speed anyway)

The real problem I think you'll have is that raid 1 is about 2 disks--i
don't know a way to proactively mirror that third disk while the first 2 are
working.  maybe some h/w raid solutions have this, but linux s/w raid
doesn't have a concept of 3-way mirroring (unless you have 4 drives and have
a mirrored-mirror kind of thing) so here's the way things will go:

- you have a 2 drive raid.
- you mdadm --add md0 /dev/otherdrive
- you now have a 2 drive raid with an empty hotspare
- you pull a working drive
- you wait hours to rebuild the new drive from the one that's still spinning
and hope you don't have a failure of that first drive during this process,
since you'll lose data from the last 2 hours.

My 3-drive system is like this:

2 drive mirrored array (have /boot and / mirrored separately from my data
partition so i can upgrade the OS without touching my data partition

1 external usb drive for use with rsnapshot which is online backups with
months of history for not much extra drive space.  If I'm going on vacation,
i unplug the USB drive and take it with me or anyway make sure it's not
vulnerable to fire/theft/lightning at the same time as the rest of my
system.

Not trying to poo-poo your idea, but wondering if having the solution in
mind instead of the problem (what problem are you trying to solve with the
constant drive swaps, esp if you keep the other drive next to the computer?)
might be narrowing your field of possibilities.

luck++;
_______________________________________________
PLUG mailing list
PLUG at lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug





More information about the PLUG mailing list