On Tue, 2003-06-17 at 16:29, John Summerfield wrote: > On Tue, 17 Jun 2003, James Melin wrote:
<snipping away> > What I would look to do is to create a second runnable system, so I > could boot a different disk (or a tape) and mount the system to be > operated on either ro or rw, depending on what's to be done. > > For actually copying the system, both tar and dd can be used: there are > alternatives to tar, but the basic principles are the same. > > dd can be used to copy from one device to another, making an exact copy > of all the data on the disk, whether the data's used or not: if you > delete all the files on a disk, copying it isn't quicker. However, it > minimises any seeking your "disks" do. > > I'm assuming real disks, adjust as needed for your technology. > > tar is more flexible because, in the process of copying, you can change > your configuration. > > You would create a backup with a command like this: > tar clC / / usr var home > > The operands: > c -- create > l -- local (don't cross mount points) > "C /" -- change to directory "/" before accessing the following > directories > /, usr, var, home are separate mounted filesystems to backup. > > By default, tar writes to stdout. > > You can restore the backup created with the above tar command by > appending something like this to the commandline" > | tar xpC /mnt > | -- pipe stuff > x -- extract > p -- preserve permissions, timestamps etc > > This supposes you've mounted the target filesystems appropriately at > /mnt. The target can be any Linux-supported 'unixy" filesystem (I don't > recommend FAT!), including nfs, and can have any disk layout you like: > more or fewer disks than the source, lvm or not, RAID or not, all > independantly of how the source is laid out. > > With creative use of ssh (and equivalent), source and destinations can > be on different machines, neither needs to be the one you're typing at. > > Alternatives to tar that are used similarly include cpio, afio and (I > think) pax. > > There is also the dump/restore package which is supposedly fastert than > tar (I've not tested this out) but has built-in knowledge of the filesystem > structure and which cannot be used to change filesystem type. > > > rsync is also worth a mention: I don't think it has much advantage over > tar for this case, but if you want to update an existing copy it's tops. > It's also pretty handy when source and destinations are on different > machines, for doing multiple restores from a single backup (think > cloning a system). Mind you, tar _can_ backup to a single file, and many > restores can be run simultaneously from that. > > Have I forgotten someone's favourite? Probably, but tar's mine. > > > > > -- > > > Cheers > John. > Good Lord that's excellent thought. My idea was to setup a snap in LVM and cron a job to create an iso9660 through mkisofs. This would afford you the lux to send it out to a dated image and burn it to whatever media for restoration on whatever platform. I'll have the full details - success or failure - in about a week if anyone is interested (I'm but a mere mortal and therefore not even remotely as fast or efficient as John - we bow and pay homage). Steve
