Restore from Dump on tape

Brad Crotchett brad at ispn.net
Sat Nov 2 17:14:29 CST 2002


Whew! May first disaster recovery on a production server is over.  We
couldn't save the original install so we reloaded rh 7.2 and restored from
tape.  First restore failed as our client partitioned differently than the
original (we had no remote access, so we were walking a non-linux user
through this over the phone!).  Second install we walked them through
partitioning and the restore went pretty well, though painfully slow.  The
only problem after the restore was a few file permission errors on cyrus
files, and a handful of corrupt mailboxes.

Thanks for the info and suggestions from both of you.

Disaster recovery sucks.

Brad

>Interesting things may happen in the /var and /tmp directories.  Such as
>lock files being clobbered and losing permissions to open new xterms,
>etc...  I doubt you would clobber anything interesting in the workhorse
>/bin, /sbin, /usr, or the popular /home directories.  If you have a full
>server running, new processes might in a rare case find very old
>configuration files interesting.

>I don't know the "correct" way, but I would switch to runlevel 1 (init 1)
>to close all open files. Make sure the system log daemon is not running to
>update files.  Just a shell.  If you were to put the drive in sleep mode,
>you may find there will be no writes to wake it back up in this state.
>That is good.  As long as no new processes are launched, no old files will
>be opened again.  When you are done, run the sync command before
>restarting the system.

>Another way might be to boot off a boot floppy, such as slack, or even a
>bootable ISO, and do it all from there.

>There are even sneaky ways you can even wipe over the drive while the
>system is running.  Safe ways of doing this would require more time than
>might be worth it, but you can make a RAM disk of a small system and
>chroot into there, remount the drive as read-only, and go to town.




More information about the Kclug mailing list