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

Re: Backup + Recovey on CDR



jbardin@imagelinks.com wrote:
>  is there anyway i can make a bottable cdrom weekly with the
> system archived on it...

Funny you should mention that.  I've been thinking along those lines,
too.
I think it would be great if there was a standard way to do it.  Then,
if
I was on vacation, my lovely systems would be safe from disaster because
it is not hard to find a sysadmin who knows about the standard way to
do things on Linux systems. :-).  OK, here goes...

=============================

Cool projects are made even cooler by a cool name.
I think I will dub this the "Millenium Chainsaw"(tm)
since it cuts down the problem space like a Vorlon Battle Cruiser(sm)
slices through warm butter.  And I have working code, sort of :-).
Well, working for me.  If it breaks your system you keep the pieces,
as usual.

Here are the cool things I've got so far:

1. A little script that packs away my filesystems in .tgz format.
   Compression is on the order of 2:1.

2. A little script that
        - sticks the MBR in the right place
        - partitions the disk,
        - makes file systems
        - builds the filesystem hierarchy
        - loads the .tgz archives back in the right places
        - runs lilo, making the system ready for its one and
          only reboot.

3. A bootable CD recipe, stolen outright from Debian. (Thanks Debian!)

4. A recipe for recreating the system should it disappear:
        - hardware for the system
        - BIOS settings
        - how the original OS was installed (not that I will
          ever do that again)
        - a simple procedure for recovery -- about 10 minutes
          unless you decide to check the disk as you make the
          filesystems, in which case it takes a lot longer.


Here are the cool things I want to do:

5. move to dump/restore instead of tar.

6. keep incremental dumps somewhere on the net so I can get everything
   back to the last cron-driven-non-media-eating backup point.

7. Steal outright the cool hardware detection code used by the
   desktop wannabe distros like Suse, Caldera, and Redhat.
   This should give a measure of hardware independence.  Right
   now I'm counting on hardware being fairly much the same between
   the original system and the recovery system.

8. Create some "Here, boot this" CDs that install a configured
(everything
   off) Debian system on any hardware in under 10 minutes without
   asking anybody anything.  It boots, slicks the disk, and installs.
   The only interaction is "remove CD then press enter to reboot".
   This should make Debian a little more popular at the installfests.

9. Maybe poke around in the registry for things like monitor
capabilities
   and network environment clues.  Then again, why trust *anything*
   found on a contaminated system?

10. A list of tips for getting the services that are off configured
    and turned on.  The key point is that the system should be basically
    usable before we start asking intimidating questions like "what is
    your netmask?".  Real users do not know WTF a netmask is, and should
    have the opportunity to browse the docs for a week or two before
    guessing wrong, guessing wrong again, and then maybe getting it
right
    or asking the neighbor's kid.


> p.s. i dont know why i would ever need to recover a crashed a linux
> system anyways ;).

Because you (yes you) might say "rm -rf foo /*" one day.
Because some genius plugs a data cable into a wall socket.
Because thieves break in and steal.  Because water runs downhill.
Because a tornado can bury your lovely system in the heart of an oak.
Because this list has no end.

=============================

So I will clean things up a little, add (minimal) documentation,
and post this on a web page somewhere.  Stay tuned.

-- 
         _~|__
   >@   (vagn(     /
    \`-ooooooooo-'/
  ^^^^^^^^^^^^^^^^^^^^



Reply to: