On 03/31/2014 11:03 AM, Richard Pieri wrote:
Bill Ricker wrote:
I've seen a big-name commercial block-replication solution duplicate
trashed data to the cold spare ... wasn't pretty !
Another great example of how replication is not backup.
Or, another way of looking at it: a demonstration that there are
different kinds of backup.
Having backup hardware is good, and having a backup hot copy of your
data for the backup hardware to use obviously pairs well. But that just
saves you from losing your primary hardware in a flood, fire, theft, etc.
There are more ways for things go go wrong. The software maybe has a bug
that messes up your data, or a human maybe fat-fingers a command and
messes up your data. In those cases it would be nice to be able to go
back in time to some sort of a checkpoint. This is what "backup"
frequently means, but that isn't simple either: Maybe you need to
restore an old backup dump then run transactions forward to just before
the error. Depends on what you are doing.
In whatever your situation is, it is worthwhile to think through all the
things that could go wrong, and figure out how you can most reasonably
protect yourself from each. Including a recovery plan for each case.
(That's why I like using disks for back up data over tape because the
restore time can be a mount vs. a lot of spooling.)
Back to my earlier "flood, fire, theft"-list. Be careful a single event
doesn't take out both your primary functions and your redundancy sitting
a few inches away, and maybe your off-line backup a few feet from there.
And be careful your offsite backup isn't itself a security risk. (Oh, I
stopped for a drink on my way home and left my bag in the bar.)
There are no simple recipes, you have to think through scenarios,
dreaming up diabolical, unfortunate events.
-kb
_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
