OnlineJFS and Snapshotting

[Eric Buckner]

Up until now we have been doing cold backups, but our users are starting to have needs that require the db to be up longer and longer.

I am back trying to figure out ways now to keep out db's running as long as possible and give the dba's a good reliable backup everytime.

We are running Data Protector 5.1 on HPUX 11i w/ OnlineJFS. We are currently researching RMAN integration w/ DP and I am curious about snapshotting.

Specifically, I am interested in knowing:


1. How much space do you have to have available for snapshotting per filesystem. I am going to assume a heavily used database.

2. How exactly do you set it up? I ran across and old doc describing AdvancedJFS, is it still the same? Meaning I need to create a volume to hold the snap changes, or does the filesystem deal w/ that now?

3. Assuming we have to allocate space into a volume, what happens if the snap data area fills up while you are running the backup?

Thanks!
Eric

[A. Clay Stephenson]

1) It depends - how long will the snapshot remain mounted? how many 1st time updates will be done during the mounted period? -- only the 1st update of a given block count. I have never seen a snapshot buffer require more than 20% of the original and 15% is considered an extremely safe buffer size.

2) mount -F vxfs snapof=/u01/oradata /dev/vg04/lvol1 /u01/snaporadata

/dev/vg04/lvol1 is the snapshot buffer and /u01/snaporadata is the snapshot mountpoint

3) Reads from the snapshot mount will then fail but nothing bad happens in the original.

4) Unasked but answered anyway -- if however the snapshot buffer fails (e.g. an unmirrored LVOL suffers a failed disk) then the original filesystem can hang --- BAD, BAD. Therefore, make certain that the snapshot buffer as well as the original filesystem is mirrored (or RAID'ed).

This is really my preferred method of Oracle backup. You have all the warm-fuzzy of a cold backup with almost all the uptime of a hotbackup. The total database downtime is typically about two minutes but your mileage will vary.

[Eric Buckner]

Thanks for the info Clay!

Just for clarification, I believe I just understood that a 20% buffer is more than adequate for snapshotting?

I would say that our DBAs would prefer a 'cold' backup as well. If this is what will give it to them, then we may be looking at doing this and then making what we would call our CRITSYS backup happen nightly (This is a backup of all Prod DBs while they are down). Currently it is only happening on Saturday and we do individual DBs during the week.

And another question for you. Which filesystem do you backup? The buffer? What exactly is going on there? At 20% the size there is no way it can hold all the data. And how do you restore that exactly?

[A. Clay Stephenson · Accepted solution]

Yes, 20% is an extremely generously sized snapshot buffer --- which is completely invisible to you. You actually backup the snapshot mountpoint. When you restore, you restore as the original filesystem mountpoint (or rename it after the restore).

The reason the snapshot buffer can be so small is that the snapshot itself is composed of both the original filesystem and the buffer and a changemap. Here is what happens: When the snapshot is first made the changemap is marked as clean and nothing is in the snapshot buffer. Just before a block in the original filesystem is updated for the first time since the snapshot was started (subsequent changes to that block don't count) via a write(), the original contents of that block are written to a block within the snapshot buffer and the changemap is updated to indicate that that block was changed. The write() operation in the original filesystem then proceeds normally. Now, when reading from the snapshot, the changemap is consulted. If a given block has not been updated the the block is read from the original filesystem otherwise it is read from the snapshot buffer. The entire snapshot mount of a large filesystem can be done in a few seconds because nothing is really copied at that point.

I do all of this including shutting down the database, snapshotting, and restarting the database in OmniBack pre-exec scripts; the snapshot is removed by a simple umount and rmdir in a post-exec script.



I hope I have been somewhat clear, Clay.

[Eric Buckner]

Thanks again Clay!

It really seems like something we would want to persue.

Is it to much to ask to see your pre and post exec scripts for doing this?

[A. Clay Stephenson]

Sorry, can't do that for security reasons.

[Eric Buckner]

Not even for a bunny?

Seriously. You have been a great help.

I wasn't looking for anything that is specific to your site. Just some generic, this is what I do kind of stuff.

So anything that you got that can help it would be appreciated.

Thanks again!
Eric

[Steve Bonds]

Generic process:

1. mount snapshot filesystems via "snapof="
2. back up that mounted snapshot (not the original)
3. unmount the snapshot
4. repeat for all filesystems

This link is related, but not specific to backups. It does, however, give some really specific examples of how to use snapshots:

http://mailman.eng.auburn.edu/pipermail/veritas-vx/2001-March/001483.html

I'm sure Mr. Stephenson would provide script examples if he could. Posting code here is fraught with problems in today's litigous environment.