vxfs snapshot

[Gilles Stenger]

Hello All,
We would like to implement vxfs snapshot on an rx4640/Online JFS3.5.
Taking snapshot work great but we have to size the device required by the snapshot because this size depend on snapped file system activity.
How do I know about the used size on the snapshot device.

Regards,
Gilles

[Steven E. Protter]

Shalom,

The size you choose is based on system activity.

The rule of thumb I got verbally from HP was 20-25% of the logical volume size of the actual database. The snapshot holds delta, or changes, not all the data.

I've run simulations on active databases and found that this was reasonable. Is it possible to have a problem with this rule? Yes. It depends on the write volume to your databases.

Another idea came to mine while typing(watch out for those kind of ideas) Check the amount of space your archive logs (Oracle) use during a period of time. If this is more than 25% of the logical volume holding the filesystem then there may be a problem.

SEP

[Duncan Edmonstone]

Gilles,

>>How do I know about the used size on the snapshot device.

The short answer is you don't. At least not through any officially supported tools. There is a tool available through HP called snapbdf that reports on usage on snapshot filesystems - getting them to give it to you could be difficult, and it will come 'as is' - i.e. no support.

As you on Integrity/11iv2, you could aslo look at upgrading to VxFS4.1, which would allow you to use STorage Checkpoints as well (these ar a might more flexible). Have a read here:

http://docs.hp.com/en/5991-1833/5991-1833.pdf

HTH

Duncan

[A. Clay Stephenson]

The version of online JFS you can purchase directly from Veritas contains a utility that does allow you to see the amount of snapshot buffer used but the OEM'ed version from HP does not. I have used vxfs snapshots for years for backup and even on active filesystems (including databases) I have never exceeded my snapshot buffers which at sized at 15% of the original filesystem. Note that only the FIRST write to any given block of data actually occupies space in the snapshot buffer; subsequent writes to that same block don't matter at all.

In my case, the databases are quite active and the backup takes about 6 hours rto complete each day and I have never exceeded my 15% snapshot buffer size.

You should also note that nothing really terrible happens when you do exceed the buffer. Read()'s from the snapshot fail but the original filesystems doesn't skip a beat -- so your application will continue to run.

[A. Clay Stephenson]

Oh, and should tell you about a "gotcha" that is not so obvious but can cause a hang in the original filesystem (unlike filling up the snapshot buffer). If the snapshot buffer's physical disk fails, then the original and snapshot mounted filesystems can hang. The fix is to make sure that not only is the original filesystem LVOL mirrored but also the snapshot buffer LVOL is mirrored (or is part of an array LUN with multiple SCSI paths).