Veritas Storage Foundation 5.0 for Oracle RAC Configuration Guide Extracts for HP Serviceguard Storage Management Suite, Second Edition, May 2008

Using Storage Checkpoints and Storage Rollback
Using Storage Checkpoints and Storage Rollback for Backup and Restore
Chapter 4
43
Using Storage Checkpoints and Storage Rollback for
Backup and Restore
SG Oracle RAC provides a Storage Checkpoint facility that is similar to the snapshot file
system mechanism; however, a Storage Checkpoint persists after a system reboot. A
Storage Checkpoint creates an exact image of a database instantly and provides a
consistent image of the database from the point in time the Storage Checkpoint was
created. The Storage Checkpoint image is managed and available through the HP
Storage Management suite command line interface (CLI).
For more information on creating Storage Checkpoints with the CLI:
See “Creating Storage Checkpoints Using dbed_ckptcreate” on page 55.
A direct application of the Storage Checkpoint facility is Storage Rollback. Because each
Storage Checkpoint is a consistent, point-in-time image of a file system, Storage
Rollback is the restore facility for these on-disk backups. Storage Rollback rolls back
changed blocks contained in a Storage Checkpoint into the primary file system for
restoring the database faster.
For more information on Storage Checkpoints and Storage Rollback, see the Veritas File
System Administrator’s Guide.
About Storage Checkpoints and Storage Rollback
A Storage Checkpoint is a disk and I/O efficient snapshot technology for creating a
“clone” of a currently mounted file system (the primary file system). Like a snapshot file
system, a Storage Checkpoint appears as an exact image of the snapped file system at
the time the Storage Checkpoint was made. However, unlike a snapshot file system that
uses separate disk space, all Storage Checkpoints share the same free space pool where
the primary file system resides unless a Storage Checkpoint allocation policy is assigned.
A Storage Checkpoint can be mounted as read-only or read-write, allowing access to the
files as if it were a regular file system. A Storage Checkpoint is created using the
dbed_ckptcreate command.
Initially, a Storage Checkpoint contains no data—it contains only the inode list and the
block map of the primary fileset. This block map points to the actual data on the primary
file system. Because only the inode list and block map are needed and no data is copied,
creating a Storage Checkpoint takes only a few seconds and very little space.
A Storage Checkpoint initially satisfies read requests by finding the data on the primary
file system, using its block map copy, and returning the data to the requesting process.
When a write operation changes a data block n in the primary file system, the old data is
first copied to the Storage Checkpoint, and then the primary file system is updated with
the new data. The Storage Checkpoint maintains the exact view of the primary file
system at the time the Storage Checkpoint was taken. Subsequent writes to block n on
the primary file system do not result in additional copies to the Storage Checkpoint
because the old data only needs to be saved once. As data blocks are changed on the
primary file system, the Storage Checkpoint gradually fills with the original data copied
from the primary file system, and less and less of the block map in the Storage
Checkpoint points back to blocks on the primary file system.