VOB backup strategies

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, DevOps Code 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 DevOps Code ClearCase on the VOB host. The time required to stop and start DevOps Code ClearCase might not add significantly to the time it takes to back up the VOB. While DevOps Code 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 DevOps Code 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.