[mdlug] Periodic backup software (dis)recommendations

Dan Pritts danno at umich.edu
Tue Aug 17 10:37:44 EDT 2010


On Sun, Aug 15, 2010 at 05:45:34PM -0400, Dr. Robert Meier wrote:
> I'm configuring a new computer, and now is the time to consider
> backup strategy.

Something I forgot to mention in my previous reply:

DO TEST RESTORES.

REGULARLY.

backups are easy.  RESTORES ARE HARD.

Test that every client can restore, or be damn sure that they are
so alike as for it to be a waste of time.  

a couple anecdotes from hard experience:

1) I managed a umich department that used a lot of NeXT workstations.
we backed them up with rdump to a tape drive on a central machine.
worked great, yada yada.

Somewhere along the line NeXT stopped making hardware and released
its OS for x86 machines.  A faculty member bought a PC preloaded
with nextstep and i added it to backups.  along we went, no problems.

He had a total disk failure.  we went to restore.  Whoops, dump
dumped raw filesystem data.  The filesystem was byte-order dependent.
The backup server was a 68030; the client an i486.  I have never
gone to figure out exacttly what went wrong, but there was data on
the tape from this box, just as had been logged.  The other data
on the tape, from 68k clients, restored fine, either locally on the
server or remotely on the client with rrestore.  Unfortunately, the
data on the tape from the i486 machine was not readable either
locally on the server (no big surprise, byte-order wrong), OR on
the client with rrestore.

Oops.

On the plus side, Ontrack got all his data back and it only cost
$1-2000 (1996 dollars, i don't recall exactly).  Given that it was
a year of his life, it was a bargain.


2) Another umich department.  This one happened to have a Sun.

I had set up backups to their local tape drive, and tested restores,
no problems.

I had a summer intern whose job it was to do local tech support
(which he did fine) and swap the tapes so backups occurred
regularly.  

At the end of the summer, both the intern and I left the U for
greener pastures.  

Soon after, I got a call from a former colleague who was trying to
do a restore.  I don't know exaclty what went wrong but the backups
were no good.

It was my fault, not the intern's.  I shouldn't have left this
important task to him with no supervision/verification it was getting
done right.



In each case, if i had properly tested restores, data loss would have
been prevented.


I hope my sad experience helps some of you.

danno



More information about the mdlug mailing list