On Tue, 17 Jun 2003, James Melin wrote: > I would like to be able to do some volume snapshots for a disaster recovery > exercise. > > Since we don't have VM, what I'd like to do is go down to single user mode, > software applications stopped and issue a device copy for all active > devices, and then come back up with the devices I just copied to, mounted > at /mnt. > > This will let me change the internal configuration files to that of the > hardware devices for the disaster recovery system, or in my case for > testing my DR testing plan, another LPAR, and IPL the copies > > > What is the best method to do this? I know I could disk copy the volumes > using DFSMShsm with linux down, but I'd rather not come all the way down. > I've got the dasd to spare for this, so I'd like to try it. > > > So best way to shutdown to single user mode, kick off a script, and what > commands to dump the dasd in that script, and return to runlevel 3 is the > what I'm after >
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. Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
