[Leaplist] Backup to external USB md RAID 1/5?

[Bryan J. Smith]

Jason Boxman wrote:  
> To save physical space, I am considering eliminating my backup
> server entirely.  Instead, I am considering replacing it with three
> external 3.5" (the current internal disks) drives in a RAID 1 or 5
> configuration.

Okay, I'm scratching my head.  What size is your current "backup
server"?

In my house, anything with four (4) 3.5" HDs or less is MicroATX or
smaller.  That means any one (1) of three (3) common form-factors ...
- Tower:   7" x 14" x 15" (holds 5 x 3.5", 3 x 5.25")
-  Cube:   9" x 11" x 14" (holds 3 x 3.5", 2 x 5.25")
-  Slim: 5.5" x 12" x 12" (holds 3 x 3.5", 1 x 5.25")

While there are "Slimmer" designs, but they don't take full height PCI
cards.

That Slim is not really much bigger than three (3) 1.75" x 6" x 8"
external 3.5" drives stacked to 5.5" x 6" x 8".  I don't see this being
about size, but that's just me -- I've been doing MicroATX for 4 years.

> Can you run md RAID against a bunch of external USB 2.0 drives?

Of course!  Of course, you'll also have ...
- Disconnections (even Apple admitted this back in 2003 with FireWire)
- Disconnections causing "broken" mirrors/stripes (especially w/MD)
- Shock issues (3.5" is not designed for mobile, 2.5" is)
- Systems not liking the "unknown" format (may I "initialize" for you?)
- Piss-poor performance (forget anything faster than 20MBps w/USB 2.0)
- Etc...

Issues with both disconnections and systems not liking the format caused
me to use LVM-based mirroring or striping years ago.  Unlike Multi-disk
(MD) approaches, which must be "scanned" and have configuration
"rebuild" or things can get dorked, LVM has fixed meta-data that is
well-known and defined.  You can't "accidentally" try to "mount a
mirror/stripe" that is incomplete unlike MD if you have a config file.
The system must "fully see" the volume or it doesn't touch it at all.
E.g., "vgchange" utility.  It also protects me on a "disconnect" -- it
just completely freezes the volume group as read-only.  I've seen MD
still attempt to write, writing to one disk but not another.

With regards to format issues when other systems "touch" it, unlike MD
(which is often mistaken as Ext2/3 by other OSes/utilities), LVM has a
well defined meta-data and slices are not so "bare."  Most other
systems, even Windows, see the LVM meta-data and realize it shouldn't
touch it.  Remember, mirroring and striping under MD and LVM don't
differ, it's the same kernel implementation, it's just the volume
management that is added -- LVM has it, MD does not.

I've never had any issues with LVM.  Every major issue I've seen has
been LVM atop of MD, where the MD got dorked.  I like my mirrors and
stripes integrated in LVM (via Device Mapper for LVM2 under 2.6), not
separate and another layer.  I like them inside of a volume, not "bare"
on the outside.

But just-in-case some systems still don't like LVM, like for MD, I still
put an 8GiB (63/255/1-1024 s/h/c) or 32GiB (63/255/1-4096 s/h/c) C:
drive at the front of the drive for slice 1, and then Ext3 becomes slice
2.  That way Mac, Windows, etc... won't want to immediately "initialize"
the disk.  ;)

Shock issues with 3.5" disks is why I only use 2.5" disks now
externally.  No matter how you pad'em, it's not good.  2.5" is an order
of magnitude better for non-spinning shock, let alone spinning/operating
shock.

> Is that working for anyone?

Yes and no.  I use LVM on many external disks just so things don't get
touched.  But no, I don't use 3.5", I use 2.5".  I just bought a number
of brand new Hitachi, 250GB, 5400rpm, ~45MBps performing 2.5" SATA disks
for both internal and external use at $80/each (sub-$0.33/GB).  I even
use LVM for a single disk, just because I like to use "vgchange -an
(volumegroup)" so there is _no_mistake_ that the kernel is not using it
anymore at all.  I do this with SMB servers regularly.

> Alternately, is there some other solution that'll provide me with live,
> on-site backups that I can divorce from a physical system if necessary.

Why would you want to divorce yourself?

> (If the system itself dies and I need access to the backups,
> not to move the hard disks off-site;

Why not just have extra internal storage in your main system (extra
copies -- maybe revisions of files stored in a different filesystem in a
Subversion repository), and then the backup server (sync your Subversion
repository to it, maybe a "drop area" for really important stuff), and
then maybe an external 2.5" disk for the most critical stuff (sync that
"drop area" to it) that you plug in and unplug regularly (maybe keep
with you in your backpack wherever you go), and call it a day?

I think it covers most everything for a home user.  I know it does me.
I sync my main server against my main desktop, and vice-versa, and then
use DVD-R/RAM and 2.5" drives for off-line/off-site.

I've never seen "size" or "reliability" argued against a backup server.
Interesting.  I mean, if your "backup server goes down," what does that
cost you?  It's secondary.  But if external drives are bringing down
your main system, that's primary.  ;)

Yes, I've had this discussion in production labs far too many times.
Eventually they humor me with "one week of 'my way,'" as soon after,
they become 'real believers in the BS of BS which really wasn't BS."  I
don't state things because it's just "my way," it's based on seeing
repeat follies -- a few even my own assumptions corrected
afterwards.  ;)

> I expect to leave them spinning 24/7.)

I reduced downtime in a particular large defense contractor's classified
and confidential labs by 100% -- absolute 100% (and this wasn't no
"small location" either, campus wide in several departments) -- by
removing all of the FireWire and USB disks attached to servers 24x7 --
hint, hint.  ;)

BTW, for 24x7 operation, you want a Hitachi "T"7K, Seagate Barracuda
"ES" or Western Digital Caviar "R"E that has been tested to reduced
vibrations and other longevity issues when you're spinning 24x7.
Otherwise, fully expect drives to fail much sooner, vibration matters.


-- 
Bryan J  Smith              Professional, Technical Annoyance
mailto:b.j.smith at ieee.org  http://www.linkedin.com/in/bjsmith
-------------------------------------------------------------
           Fission Power:  An Inconvenient Solution