[rescue] Mounting and Dumping

[Andrew Weiss]

On Jan 14, 2004, at 6:34 PM, Sheldon T. Hall wrote:
> <kinky friedman>
> It always fails to amaze me ...
> </kinky friedman>
> ... that the folks who buy [unix|windows|whatever] put up with this.  I
> mean, how hard can it be to back up the friggin' files in a sane and
> reliable manner?  In 1983 I wrote a backup program for CP/M, in BASIC, 
> that
> would back up any size of hard drive, to any number of floppy disks, 
> and
> arrange the files to fill the floppies as full as possible.  If I 
> could do
> that, why can't the guys at [Sun|Microsoft|wherever] do something 
> better
> twenty years later?
>
So why can't a program for backup take in principle a system that is 
going to be backed up at off hours, create a large RAM disk of 1GB or 
so (larger if you can afford it), lock the original filesystem for read 
access only, accept all writes as journal entries to the RAMdisk, 
finish backing up the read-only (and mounted system), and then examine 
the RAMdisk and if there were any changes have an option to either 
immediately apply the journal to the backup (slow), or... back up the 
journal after the original set on the tape.  Then allow selective point 
in time restore at a later date.  I'd also like to see this built into 
fsck type activity where one can repair the root filesystem while it is 
online and mounted.  If need be, this pseudo-journaling swap space for 
backup could be configured as either disk or memory.  (You could put an 
inexpensive older disk somewhere in the system that is only banged on 
during backups)

Just random thoughts...I'd really like a backup process that doesn't 
involve complex rote

Andrew