Well, the first of my UNIX tips section.
I have been playing with Veritas snapshots to do an off-host backup solution for several large databases. The situation is that I have a production quality disk array which the database uses, and a cheap disk array that is used to house the backup data. The process uses the pre-4.0 vxassist snapshot method, as I have run in to issues with the 4.0 vxsnap process. The snapshots maintain a DCO log which tracks changes. The 4.0 method uses a version 20 of this log, which I do not think is up to par. I ran in to problems with data being written when it should not have been written. The pre-4.0 snapshot method uses a version 0 DCO log, where I have not had this problem.
In this setup, we have prod_dg with proddisk1 as a disk. the volume prod_lv contains the production database. We will create a snapshot, prod_slv, which will be in another disk group, snap_dg, using snapdisk1. the disk groups, and the volume prod_lv is already created. the disk snapdisk1 is mapped to both the production database server and the backup server. disk proddisk1 is only seen by the production server. Both hosts require a veritas volume manager key, as well as a veritas flashsnap key.
Now the goodies.
1. Add a DCO log to the production volume. This is a bitmap type log that tracks changes to the volume.
vxassist -g prod_dg addlog prod_lv logtype=dco
2. Enable fast resync on the production volume. This sets a flag where you can only sync changed data on a snap resync.
vxvol -g prod_dg set fastresync=on prod_lv
3. Join the snapshot disk group to the production disk group.
vxdg join snap_dg prod_dg
4. Create a snapshot of prod_lv, on to snapdisk1. This will create a plex of prod_lv, as well as a disabled DCO log attached to that plex.
vxassist -b -g prod_dg snapstart prod_lv snapdisk1
5. Monitor the sync process.
vxtask list or vxprint -ht -g prod_dg | grep SNAPDONE
6. You now want to make prod_lv quiet.
shutdown database, or put in to hot backup mode.
7. Perform a snapshot split. This will take the plex created by the snapstart, and make it an independent volume.
vxassist -g prod_dg snapshot prod_lv prod_slv
8. You can use prod_lv once again.
startup database, or remove from hot backup mode
9. Split the snapshot disk in to its own disk group, and deport.
vxdg split prod_dg snap_dg prod_slv
vxdg deport snap_dg
10. You can then import, mount and backup prod_slv on the off-host backup server.
To perform a snapshot refresh:
1. Import the snapshot disk group.
vxdg import snap_dg
2. Recover and start the snapshot volume.
vxrecover -g snap_dg -m prod_slv
vxvol -g snap_dg start prod_slv
3. Join the snapshot disk group to the production disk group.
vxdg join snap_dg prod_dg
4. Resync the snapshot volume from the production volume. Because of the DCO log, and fastresync, only changed blocks are copied.
vxassist -g prod_dg snapback prod_slv
5. Monitor the resync.
vxtask list or vxprint -ht -g prod_dg | grep SNAPDONE
6. Once resync is complete, make disks quiet.
Throw oracle in to hot-backup mode
7. Perform a snapshot split.
vxassist -g prod_dg snapshot prod_lv prod_slv
8. You can once again use the disks.
Remove oracle from hot-backup mode
9. Split and deport the snapshot disks.
vxdg split prod_dg snap_dg prod_slv
vxdg deport snap_dg
I do not support the above, but it works for me.