I see no reason you could not copy/paste the whole thing into a page with an appropriate title. Others can refine and improve upon it, but I'd bet good money that no one will delete it or complain that it was put there.
-wes On Sun, Jun 20, 2010 at 5:09 PM, Don Gould <[email protected]> wrote: > Strikes me that all this content should be added to the wiki shouldn't it? > > I'm happy to do a bit of editing, but I'm a newbi here and don't want to > tread on anyones toes. > > What do others think? > > Cheers Don > > On 20/06/2010 7:36 p.m., Keith Lofstrom wrote: > > On Sat, Jun 19, 2010 at 08:31:31PM +0200, JPH wrote: > >> It is virtually impossible to do a full restore without doing some > >> serious after work. The problem is at least that your boot sector is not > >> being backed up, and if it would be, it'd be most probably useless > >> because the file layout on disk has changed. Another problem you'll run > >> in to with Ubuntu is that the filesystem's UUID's have changed during > >> format. > > > > While I don't know how Grub-2 does things, with Grub-1 I name the > > partitions and use those names in fstab. I also do recovery in > > a script (running on a second machine) that does the format and > > grub install. My full-disk restores are automated, so they use > > clock time but not a lot of serious user time, beyond decisions > > as to what to restore. > > > > Also, when I buy a disk for installation, I buy an identical > > spare. They are cheap enough, and that saves the trouble of > > deciding how to adapt to a different drive size. > > > > The original questioner was thinking ahead - when you need to do > > a full disk restore, it always happens at an inconvenient time. > > Thus, it is good to have all the scripts written and materials > > available, so when that sad day comes the stress is minimized. > > That includes setting up the original disk for easiest restore. > > Many "features" like UUID partition labels in fstab, or even > > LVM (without proper tools for rebuilding) can get in the way > > of restore, without much more sophisticated scripts to do the > > recovery. > > > > Note, many recovery steps are aided by swap enclosures. Another > > way to quicken recovery is to save the first few kilobytes of > > each drive, df information, and sfdisk information with every > > backup. > > > > Yet another aid is to put three partitions on each backup drive, > > with a small bootable OS partition and swap. When I build a > > new backup drive, I typically just "dd" the OS partition from > > an older backup drive to a newer one. With a two-drive system, > > that can be done by dd-ing the old partition to a file, then > > "dd" again onto the new drive OS partition. > > > > My worst case was a drive failure on my laptop the night > > before a plane flight and a long trip. With all the > > automation in place, it was a simple matter of putting the > > spare laptop drive in a swap tray in a 2 drive system, > > booting from the backup drive, starting the script, and > > going to bed. A few hours later, I had a drive ready to > > swap into the laptop. On the plane, I loaded the failed > > hard drive into a second drive bay on my laptop, and was > > able to recover most of the files I had worked on the day > > before the failure. > > > > Many of these features should be in a new program which > > might be called "divish-restore-ultra". A better programmer > > than I can write it. Similarly, perhaps someone can write > > a guide to setting up a computer for maximum dirvish/rsync > > friendliness. But those hypothetical people have more time > > than I do. > > > > Keith > > > _______________________________________________ > Dirvish mailing list > [email protected] > http://www.dirvish.org/mailman/listinfo/dirvish >
_______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
