Mirror/UX, third mirror, split, backup and resync

[Mark Jones_1]

Does anyone have any opinions (I'm sure you do!) concerning the validity and efficiency of the following:
I want to have a set of mirrored logical volumes backed up to tape without having to wait for the backup to complete. The obvious way to achieve this is to have a third mirror copy, which can be split from the other two and the third copy can be backed up whilst the originals can be accessed and updated (this might be a database for example). Once the backup is complete, resyncronise the copy.

My questions are:
1) Are there any figures/statistics available that might give some clue has to how long the resync process will take?
2) Also what performance impact would the resync have on the 'original' copies?

I appreciate that it is very dependent on the hardware being used (to be decided) and the amount of data (probably around 100GB)...

Many thanks

[Mark Grant]

Mark, I don't have any figures for you but I can tell you that lots of people do this. It is a very common approach to doing a database backup in those cases where it is possible to take the database down while you split the mirror.

[A. Clay Stephenson]

1) The resync times are directly proportional to both the size of the LVOL's and the amount of change that occurred during the "split" interval. A VERY rough estimate would be about 2GB/min. depending upon the hardware and quantity of changed data.

2) The resync's impact can be noticable especially during times of busy activity; of course, if the disks are that busy running the application during normal periods then the application was probably not written very well in the first place.

Let me suggest a Plan B. Rather than using lvsplit use the OnlineJFS option snapof= to create a snapshot of the original filesystem. The snapshot takes only seconds on very large filesystems and you don't take the large performance hit of resyncing. There is no free lunch because the IO hit is spread across the time when the database is in normal use while the snapshot is in effect. The hit is rather small because only THE FIRST TIME that a given block is changed in the original filesystem must that block first be copied to the snapshot buffer. The snapshot is actually a composite of the original filesystem's unchanged blocks plus a version of the changed blocks as they were when the snapshot mount was created.

[Mark Jones_1]

Plan B (it's always good to have one) did occur to me, but I've never looked at it in any detail.

Are there any threads that go into it in more detail?

Thanks again...

[Chris Wilshaw]

Assuming that you're using the standard lvsplit/lvmerge commands it shouldn't take too long. Other options are available depending on your hardware/software - for example, you could use Veritas Volume Manager.

We used to use this process ( with lvsplit/lvmerge) to back up a 30GB database, and it had no noticeable impact during the process. The split took up to 30 seconds, and the merge 10-15 seconds.

Things to consider;

1) When you split the mirror, any applications should be down to ensure that the copy is not corrupted (due to files being in use). For the resync, your applications can remain active.

2) You will need to fsck the split filesystems to be able to mount them and back up the data.

[Steven E. Protter]

1) You are better off gathering your own statistics. I find resynch to seem painfully slow. The pain increases with systems activity.

2)I expect the peformance impact to be noticeable, however I've done this during the day many times and never had a complaint.

I would suggest another method to do this with no(little) impact on peformance.

Online JFS snapshot.

Leave the mirror at two copies. Allocate the logical volume that was the second mirror as a "hot" backup section. It usually needs about one fifth of the disk space of a full mirror.

make a mountpoint for this purpose

mkdir /snapshot
# lets call the logical volume snapshot
# lets call the original logical volume mountpoint /data

mount -F vxfs -o snapof=/dev/vg01/lvol1 /dev/vg01/snapshot /snapshot

You run your backup against the original mountpoint /data

What happens is that while the snapshot is open, the kernel takes all block changes and stores them in the /snapshot mount logical volume snapshot.

Its just like a cold backup. You can down the oracle database, set the snapshot and bring it right back up.

To close the snapshot:

umount /snaphot

The block changes are moved back where they really happened, data.

Slick, fast, reliable.

SEP

[Ashwani Kashyap]

Just some other options :

Timefinder BCV/SRDF from EMC on EMC symetrix/DMX storage .

buisness copy from HP on XP storage

will do the same what you are aiming for .

[Ted Buis]

For the EVA, VA, EMC Symmetrix, an XP arrays, HP's OmniBack can do a almost zero impact backup using Business Copy. The nice thing about this approach is you can and should use a totally separate server connected to the arrays to do the backup, so almost no cycles are consumed by the original server at all. The assumption is that the array has enough I/O capacity not to impact the peformance of the application and is fast enough for the backup server to keep data streaming to tape.