[lug] Reliable SATA server?

Sean Reifschneider jafo at tummy.com
Mon Apr 30 12:46:56 MDT 2012

On 04/29/2012 06:05 PM, Rob Nagler wrote:
> drives.  I always thought the theory behind RAID was the "I", but I

The "I" in RAID means "less expensive than IBM mainframe drives".  :-)

> I was running these for a while, too, but they had weird failures,
> including backplane.  I ran a few other devices, but all seem to have
> problems.

We've had probably 40 of these through either our facility or our clients,
and have been very happy with them.

> With cp --link (long names let the code be self-documenting :-), I can
> ssh into the backup machine, do a find or just scp, and the file is
> restored.  No muss, no fuss.

With ZFS, it's little different.  I don't normally keep the snapshots
mounted, but you could.  So I just login, mount the snapshot, then I can
access the backup just as you would.

> I have seen more expensive and complex backup systems fail horribly.
> We've been backing up this way for 15 years, and we store quite a bit
> of data so I have to say it works and it's less filling. ;-)   The

I think you'd be hard pressed to call using filesystem snapshots "more
expensive and complex", but whatever.  :-)

In our environment "cp -l" wouldn't work at all.  It uses too much space
(log-files and ZODB files which get appended to end up using way, way more
space using "cp -l" than using snapshots, for a couple of examples) and are
too resource-intensive to maintain (one of the machines we back up takes 6
hours to do an "rm -rf" in one of their directories).

If it works for you, great!  It wouldn't work for us, not even close.  We'd
have to probably double or more the number of backup servers.

> * rsync  to the secondaries

The nice thing about ZFS is that you can ask it to give you a data stream
that represents the delta between two snapshots, and can load that on
another system.  So you can do the replication to a secondary backup server
without having to compare the whole file-system on both sides.

> I guess I beg to differ.  We have tested servers (RAID

Fair enough, but somehow you are running very similar systems to what we
are running, and you are having problems...  So, not sure what I can say.
Sorry I couldn't be of help.

> I've been working with computers far too long to accept "how you are
> using them" as the problem.  I have been amazed at the crappiness of

With all due respect, the above statement to me sounds like you are
unwilling to even consider that "cp -l" is not a good way to store historic
backup copies.  And if you aren't willing to consider that, there's not
much any of us can do.  You've apparently been working with computers for
too long to accept my 25 years of experience...

But, for anyone else out there, or anyone finding this in the list
archives: Seriously consider using ZFS/btrfs/HAMMER snapshots instead of
"cp -l" for simple, rsync backups, for anything more than trivial backups.

Especially if you have data corruption issues, consider ZFS since it can
detect and correct many kinds of "silent" corruption that RAID+ext4 cannot.
If you seriously value having backups you can guarantee are not corrupted,
ZFS is a pretty good way to go.


More information about the LUG mailing list