Making an Off-Host Backup of an Online Database

As illustrated in Example System Configuration for Off-Host Database Backup, the primary database volumes to be backed up, dbase_vol and dbase_logs, are configured on disks attached to controllers c1 and c2, and the snapshots are created on disks attached to controllers c3 and c4. There is no requirement for the OHP host to have access to the disks that contain the primary database volumes.

Example System Configuration for Off-Host Database Backup

Click the thumbnail above to view full-sized image.

To make an off-host backup of an online database:

1. On the primary host, use the following command to make a full-sized snapshot, snapvol, of the tablespace volume by breaking off plexes from the original volume:
   # vxsnap -g volumedg make source=volume/newvol=snapvol/nmirror=N

   The nmirror attribute specifies the number of mirrors, N, in the snapshot volume.

   If the volume does not have any available plexes, or its layout does not support plex break-off, use the procedure described in Creating a Volume for Use as a Full-Sized Instant Snapshot to prepare an empty volume for the snapshot, and then use the following command to create the snapshot:

   
   # vxsnap -g volumedg make source=volume/snapvol=snapvol

   If a database spans more than one volume, specify all the volumes and their snapshot volumes as separate tuples on the same line, for example:

   
   # vxsnap -g dbasedg make source=vol1/newvol=svol1 \
   source=vol2/newvol=svol2 source=vol3/newvol=svol3

   ---

     Note    This step sets up the snapshot volumes ready for the backup cycle, and starts tracking changes to the original volumes. When you are ready to make a backup, proceed to step 2.

   ---

2. If the volumes to be backed up contain database tables in file systems, suspend updates to the volumes:
   • DB2 provides the write suspend command to temporarily suspend I/O activity for a database. As the DB2 database administrator, use a script such as that shown in Script to Suspend I/O for a DB2 Database. Note that to allow recovery from any backups taken from snapshots, the database must be in LOGRETAIN RECOVERY mode.
   • Oracle supports online backup by temporarily suspending updates to the datafiles of the tablespaces, provided that the database is running in archive mode and the tablespaces are online. As the Oracle database administrator, put each tablespace into hot backup mode using a script such as that shown in Script to Put Oracle Database into Hot Backup Mode.
   • Sybase ASE from version 12.0 onward provides the Quiesce feature to allow temporary suspension of writes to a database. As the Sybase database administrator, put the database in quiesce mode by using a script such as that shown in Script to Quiesce Sybase ASE Database.

3. On the primary host, refresh the contents of the snapshot volumes from the original volume using the following command:
   # vxsnap -g volumedg refresh snapvol source=vol \
     [snapvol2 source=vol2]... syncing=yes

   The syncing=yes attribute starts a synchronization of the snapshot in the background.

   For example, to refresh the snapshots svol1, svol2 and svol3:

   
   # vxsnap -g dbasedg refresh svol1 source=vol1 svol2 source=vol2 \
   svol3 source=vol3 syncing=yes
4. If you temporarily suspended updates to volumes in step 1, release all the tablespaces or databases from suspend, hot backup or quiesce mode:
   • As the DB2 database administrator, use a script such as that shown in Script to Resume I/O for a DB2 Database.
   • As the Oracle database administrator, release all the tablespaces from hot backup mode using a script such as that shown in Script to End Oracle Database Hot Backup Mode.
   • As the Sybase database administrator, release the database from quiesce mode using a script such as that shown in Script to Release Sybase ASE Database from Quiesce Mode.

5. Use the following command to wait for the contents of the snapshot to be fully synchronous with the contents of the original volume:
   # vxsnap -g volumedg syncwait snapvol

   For example, to wait for synchronization to finish for all the snapshots svol1, svol2 and svol3, you would issue three separate commands:

   
   # vxsnap -g dbasedg syncwait svol1
   # vxsnap -g dbasedg syncwait svol2
   # vxsnap -g dbasedg syncwait svol3

   ---

     Note    You cannot move a snapshot volume into a different disk group until synchronization of its contents is complete. You can use the vxsnap print command to check on the progress of synchronization.

   ---

6. On the primary host, use the following command to split the disks containing the snapshot volumes into a separate disk group, snapvoldg, from the original disk group, volumedg:
   # vxdg split volumedg snapvoldg snapvol ...
7. On the primary host, deport the snapshot volume's disk group using the following command:
   # vxdg deport snapvoldg
8. On the OHP host where the backup is to be performed, use the following command to import the snapshot volume's disk group:
   # vxdg import snapvoldg
9. The snapshot volumes are initially disabled following the split. Use the following commands on the OHP host to recover and restart the snapshot volumes:
   # vxrecover -g snapvoldg -m snapvol ...
   # vxvol -g snapvoldg start snapvol ...
10. On the OHP host, back up the snapshot volumes. If you need to remount the file system in the volume to back it up, first run fsck on the volumes. The following are sample commands for checking and mounting a file system:
    # fsck -F vxfs /dev/vx/rdsk/snapvoldg/snapvol
    # mount -F vxfs /dev/vx/dsk/snapvoldg/snapvol mount_point

    ---

      Note    On Linux, use the -t option, and on AIX, use the -V option, instead of the -F option for both commands.

    ---

    Back up the file system at this point using a command such as bpbackup in VERITAS NetBackup. After the backup is complete, use the following command to unmount the file system.

    
    # unmount mount_point
11. On the OHP host, use the following command to deport the snapshot volume's disk group:
    # vxdg deport snapvoldg
12. On the primary host, re-import the snapshot volume's disk group using the following command:
    # vxdg [-s] import snapvoldg

    ---

      Note    Specify the -s option if you are reimporting the disk group to be rejoined with a shared disk group in a cluster.

    ---

13. On the primary host, use the following command to rejoin the snapshot volume's disk group with the original volume's disk group:
    # vxdg join snapvoldg volumedg
14. The snapshot volume is initially disabled following the join. Use the following commands on the primary host to recover and restart a snapshot volume:
    # vxrecover -g volumedg -m snapvol
    # vxvol -g volumedg start snapvol

Repeat steps 2 through 14 each time that you need to back up the volume.

For an example of a script that uses this method, see Script to Initiate Online Off-Host Oracle Database Backup.

In some instances, such as recovering the contents of a corrupted volume, it may be useful to resynchronize a volume from its snapshot volume (which is used as a hot standby):

The destroy attribute specifies whether the plexes of the snapshot volume are to be reattached to the original volume. For example, to resynchronize the volume dbase_vol from its snapshot volume snap2_dbase_vol without removing the snapshot volume:

Reattaching Snapshot Plexes

Using the following command, some or all plexes of an instant snapshot may be reattached to the specified original volume, or to a source volume in the snapshot hierarchy above the snapshot volume:

By default, all the plexes are reattached, which results in the removal of the snapshot. If required, the number of plexes to be reattached may be specified as the value assigned to the nmirror attribute.

For example the following command reattaches 1 plex from the snapshot volume, snapmyvol, to the volume, myvol:

While the reattached plexes are being resynchronized from the data in the parent volume, they remain in the SNAPTMP state. After resynchronization is complete, the plexes are placed in the SNAPDONE state.