-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17.03.2010 16:19, Edward Ned Harvey wrote:
*snip
> Still ... If you're in situation (b) then you want as many options available
> to you as possible. I've helped many people and/or companies before, who
> ... Had backup media, but didn't have the application that wrote the backup
> media and therefore couldn't figure out how to restore. ... Had a backup
> system that was live synchronizing the master file server to a slave file
> server, and then when something blew up the master, it propagated and
> deleted the slave too. In this case, the only thing that saved them was an
> engineer who had copied the whole directory a week ago onto his iPod, if you
> can believe that. ... Had backup tapes but no tape drive ... Had
> archives on DVD, and the DVD's were nearly all bad ... Looked through the
> backups only to discover something critical had been accidentally excluded
I can add a few items on your list, that you've probably seen, but
forgot to list:
- -Using a tape format that really isn't a standard (anybody remember the
first generation of DDS with compression, that ... probably could only
be restored on the exact identical drive that wrote them?)
- -Enabling the fancy "security feature" and not keeping a safe copy of
the encryption keys they're using on the tapes?
- -Forgetting that a disaster-recovery setup SHOULD start out with
pen+paper planning "what to do _WHEN_ disaster strikes." Including
making a step by step list. This way you can plan what prerequisites
your disaster recovery has. How do you bootstrap your recovery? What do
you need up and running to read your tapes? What routines do you have
for bringing offline media off site for safekeeping? (and this "plan for
disaster" is the reasons for my many questions on these lists lately. I
simply *will not* switch to a new solution that I cannot properly plan
for a disaster recovery of!).
What I'm getting at, is that most of the disaster recovery procedure
should actually be done _BEFORE_ disaster strikes. And use that work to
do your best to make disasters unlikely.
If your backup solution depends on a running system, bring a livecd or
similar in the same suitcase as the tapes. If you don't you'll have a
major problem when you NEED the backup.
Proper backups for disaster-recovery should be offline media. Disaster
isn't only "place burning to the ground, switch to secondary location".
It can also be a rogue employee (or outsider) data-bombing your
infrastructure. If those backups are online-and-connected, there is
little reason to trust that they weren't destroyed as well.
If you back up to a mounted file system, using a cronjob, mount the fs
for the backup and dismount it after verify. Don't keep it eternally
mounted, since a situation corrupting the mounted data then could
corrupt the backup as well.
This falls back to "plan for disaster". Include "human failures" and
"sysadmin accidents" in the disaster plan. And document every step. This
because there's no guarantee the sysadmin manages to get out of his
dungeon when the building burns to the ground. A proper disaster
recovery plan would mean that anyone competent can read the hardcopy of
the plan, and restore the system.
And so on.
Maybe someone should add some "plan for disaster" to the "best current
practices" zfs-page? ;)
//Svein
- --
- --------+-------------------+-------------------------------
/"\ |Svein Skogen | sv...@d80.iso100.no
\ / |Solberg Østli 9 | PGP Key: 0xE5E76831
X |2020 Skedsmokorset | sv...@jernhuset.no
/ \ |Norway | PGP Key: 0xCE96CE13
| | sv...@stillbilde.net
ascii | | PGP Key: 0x58CD33B6
ribbon |System Admin | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key: 0x22D494A4
+-------------------+-------------------------------
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle: SS16503-RIPE
- --------+-------------------+-------------------------------
If you really are in a hurry, mail me at
svein-mob...@stillbilde.net
This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- ------------------------------------------------------------
Picture Gallery:
https://gallery.stillbilde.net/v/svein/
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkug9u8ACgkQSBMQn1jNM7bBmwCg/i+Wcd9rXmWmhm6HReaP7XRe
IFwAoNMg8UzbX+gs2ZvAzvplEtwehfbR
=0Xlw
-----END PGP SIGNATURE-----
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
