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



This is a good set of instructions.  Thanks for sharing this with us!

On Wed, Dec 15, 2010 at 11:13 AM, Jack Coats <jack-rp9/bkPP+cDYtjvyW6yDsg at public.gmane.org> wrote:

> 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.
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>






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