System backup/restore strategy with mirrored volumes

[Alfonso Gonzalez]

I have a system with all its logical volumes mirrored. I would like to take advantage of the mirror to speed up the backup and restore procedures.
So far in order to backup the logical volumes I put the system in single user mode, split the volumes, and mount them under /backup directory under mount points with the same name as their original mount points;
/usr goes to /backup/usr, etc (one exception is root which goes to /backup/root). Before executing tar I put the system back on service, so the system is in production while the backup is being performed. When the backup is finished I lvmerge the volumes.

For the restore, I set the system in single user and recover the info from the tape directly to its original directories. Any ideas for recovering root?
Any improvements on the strategy?

[Charles McCary]

Alfonzo,

Hi - I'm a little confused I guess. But if you're bringing the production system up before kicking off the backup on the mirrors, what performance gains are you making? The only one I can think of is the disk usage would be lower on the production disk than if you just ran a backup of the lvm itself. If you don't have a disk usage issue, you may be buying yourself some extra work. Perhaps I'm confused by what you explained.

tx,
c

[Patrick Wallek]

How many VGs do you have? Is it just VG00?

If it is just VG00 that is mirrored, you are really doing backups the hard way.

Have a look at the Ignite/UX product: http://software.hp.com/products/IUX

It is FREE. It is built specifically for backing up and recovering VG00 and it does a VERY good job.

If you have other VGs, maybe with databases or something, you could do something similar to what you are already doing, but without going down to single user mode.

You could shut down the DB, split the mirrors, startup the DB again, mount the split mirrors, do your backup and then lvmerge the mirrors again.

[James R. Ferguson]

Hi:

Two comments for your consideration:

If you are dealing with vg00, as your post suggests, I would use Ignite's 'make_tape_recovery' to insure that you can recover your system if needed.

Otherwise, consider using 'fbackup'/'frecover' to backup and restore files. One advantage of 'fbackup' is that it will retry (recopy) files that are noted to have changed during the time interval their transfer from disk to tape has occured.

Regards!

...JRF...

[Charles McCary]

Alfonso,

Just re-read your response. I guess the other issue is that you can't back up the data while in "production", so that's why you're going through the trouble to split it out then back it up. If we're talking about just the system lvols (usr, root, etc..) then you should be able to back these up without splitting them out.

tx,
c

[hpuxrox]

"Any improvements on the strategy?"

- Ignite

[Justo Exposito]

Hola Alfonso,

I think that for the root directory and all the O.S you must use Ignite in order to copy it.
You can do a make_tape_recovery that allow you to copy the entire vg00 and make a bootable copy of the system.
This is a simple method and you don't need to stop your system for do it.

For the other vgs depend on the software that you are using, in our case we have Oracle and we do an online backup with OmnibackII.

Best Regards,

Justo.

[A. Clay Stephenson]

Let me suggest a Plan B which does not leave your system unmirrored during backups.

1) You really should be using Ignite/UX (make_tape_recovery) for all of your vg00 stuff. That will get your system back up in case of major failure.
2) Rather than unmirroring (and losing protection during backups) and then remirroring (and taking a big I/O hit), instead use the OnlineJFS snapof mounts. They typically use less than 15% extra space per filesystem and the snapshots take only a few seconds. You simply stop your critical aplications (like databases), do the snapshots, and restart the applications. You then backup the snapshots and unmount the snapshots when you are finished.

[Alfonso Gonzalez]

If I start up the production system with the mirrored logical volumes splited, I can perform a backup while the system is operational.

If I perform a make_tape_recovery I have to wait for the backup to finish before putting the system back in operation; currently it may take up to 2 hours to complete.

What I am trying to do is minimize the time the system has to be in maintenance mode to perform a backup.

[Justo Exposito]

Hola Alfonso,

You don't need to put your system in maintenance mode in order to do the make_tape_recovery you can do it in live without any problem and you can do it by the cron daemon at midnight for example.

The problem if you stop the mirror is if you have a hardware problem with your disk while you are not protected you go into problems.

Best regards,

Justo.

[Jacob_2]

Hi

I would suggest a daily/weekly ignit-ux backup of the vg00 ( through cron )

and use the snapshot feature of Online JFS to take a backup of the DATA volumegroups (more dynamic data).

This will reduce the risk of unmirrored DATA vg's during backup and also the I/O hits in case it was done by SPLIT/MERGE method.

The overhead is just the 15% extra diskspace required for snap FS.