[Discuss] Redundant array of inexpensive servers: clustering?

[Kent Borg]

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