An effective VOB backup strategy must provide maximum coverage
while minimizing disruptions to ongoing VOB access.
When planning a VOB backup strategy, you must consider several things:
- The backup tool must capture all necessary data.
- The VOB must be locked during the backup. A locked VOB can defer or disrupt
many development activities. If backups cannot be scheduled for off hours,
the backup strategy might need to focus on reducing the duration of each VOB
lock to a practical minimum.
- A VOB might be part of a group of VOBs that are connected by hyperlinks
and must be backed up and restored together.
- If UCM and Rational® ClearQuest® are
in use, a PVOB and a Rational ClearQuest database
are likely to hold references to each other. These references can become incorrect
when the PVOB or the Rational ClearQuest database
is restored.
Note: When choosing backup tools and strategies for VOBs, it is helpful
to understand the file system layout of VOB storage directories, as described
in
The VOB storage directory.
Choosing between standard
and snapshot backups
An effective backup strategy can be based on
either or both of the following strategies:
- A standard backup strategy that uses the tools you normally use to back
up the file systems of VOB server hosts
- A snapshot backup strategy that uses the vob_snapshot utility
to reduce VOB lock time
The standard VOB backup procedure requires that you lock the VOB,
back up the entire VOB storage directory, and then unlock the VOB. The VOB
must remain locked for the duration of the backup. If you use a backup utility
that cannot capture files open for writing, Rational ClearCase® must
be stopped also.
Use the standard backup procedure on ordinary or UCM
component VOBs whenever users can accept the duration of required locks. Locking
a VOB prevents checkins, checkouts, and other operations that affect VOB data
and metadata. These include UCM deliver operations and any UCM rebase operations
that require merging. Users can still work with checked-out or (in a snapshot
or Web view) hijacked versions while a VOB is locked.
clearmake and
omake are
designed to cope with locked VOBs. They can be configured to “sleep” when
they are unable to open an object in a locked VOB, and then retry (see the
clearmake reference
page). When you use a standard backup procedure:
- You can use a tool that cannot back up files that are open for writing,
but only if you first stop Rational ClearCase on
the VOB host. The time required to stop and start Rational ClearCase might
not add significantly to the time it takes to back up the VOB. While Rational ClearCase is stopped,
no VOBs or views on the host are accessible.
- No extra disk space is required if you are backing up to a different physical
device.
- The VOB restore procedure is simplified. Because the VOB database and
storage pools are backed up as a unit, it is unlikely that data will be lost
when the VOB is restored.
Snapshot backups, which copy only the VOB database, can significantly
reduce the duration of a VOB lock, especially for larger VOBs. The
vob_snapshot utility
helps automate the most critical parts of a snapshot backup and can easily
be run as a
Rational ClearCase scheduled
task. When you use
vob_snapshot:
- You must use a backup tool that can back up files that are open for writing.
After vob_snapshot is finished and the VOB has been unlocked,
you must back up the remainder of the VOB storage directory. If the VOB is
in use while this backup is in progress, it is likely that one or more files
in the VOB storage directory will be open for writing. If they are not backed
up, data can be lost when the VOB is restored.
- More disk space is required. A copy of the VOB database must be written
to disk, ideally on the local host. In addition, each of the VOB’s source
pool data containers, when replaced by a container with new version data,
is retained for an additional 30 minutes to improve the chances that source
containers can be reconstructed when checkvob resynchronizes
the VOB database and the storage pools when the VOB is restored.
- The VOB restore procedure is more complex. Because the VOB storage pools
and the VOB database are backed up at different times, they must be resynchronized
when you restore the VOB. In particular, DO and version data added or removed
in the interval between the database snapshot and storage pool backup cause
database or pool skew that must be resolved by the checkvob utility.
- Some data can be lost when the VOB is restored. If the restored
pools are older than the restored VOB database, data missing from the pools
is lost (as expected). If the restored pool backup is newer than the database,
pool version data newer than the snapshot is not added to the restored database. Minimizing data loss with checkvob -force -fix explains
these risks in more detail.
Note: PVOBs that do not contain any components have no data in their
pools and can be backed up by vob_snapshot without risk
of data loss. Use vob_snapshot to back up PVOBs.