Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

backups



After having spent half my career dealing with backups.  The wisest thing I
believe you can do is test it.

I have done this, and it seems to work for me:

Find an machine (almost anything for testing, if it is going to be a backup
or DR server, it should be roughly equivalent
to your production machine) with enough disk space, and restore your system
to it.

Document EXACTLY what you do, where you get the information/disks/CDs, etc.
and how you install them, and
how you get the data restored.

Once it is done, working, and tested, now fix your documentation.  And
personally I do it again using my new 'cookbook'
myself.  Iterate as needed to get it right.

Now, get a co-worker, friend, or consultant that has a good skill set,
understands tech talk, and buy them pizza and
Cokes while they go through your cookbook. ... Stay with them, document
everything they ask you, any issues they have,
etc.

Fix your documentation again, now, iterate the last step with a different
person.

Once you have no new 'fix' notes at the end of a test, you have a reasonable
cookbook.

Now repeat the test every six months, once with just you (or another local
admin) and one with a 'guest' (basically, not
you or someone that deals with these systems on a daily basis).

This verifies your procedures, that your backups can be restored, and your
customers can be served if you can't be there.

I have had instances where backups were bad, or the data needed was not in
the backups for whatever reason.
So I have eaten a lot of crow, and it doesn't go down well.  Performing the
tasks above helps ensure that you are
really ready if something bad happens.  The worst I have had to do is DR
tests (disaster recovery tests), and I have even
had to rebuild my production backup server from backups (very nerve racking
at the least).  Rebuilding mail servers is
bad, but it works (it also helps to make sure you have secondary email
servers in a different geography, like half way
across the country - they accept email for your domain, but users still
can't get to it until your email server comes back
up and processes the dumps from the secondary servers, but at least mail
doesn't bounce.).

I hope this helps a bit.






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org