Backing up related databases together

Data in multiple repositories is often related, especially when UCM is in use. Related databases should be backed up together.

About this task

Typical database relationships include the following:

UCM operations such as joining a project, making an activity, delivering or rebasing a stream are likely to change the data in multiple related databases and, in some cases, the relationships themselves. Even if UCM is not in use, changes in an administrative VOB hierarchy (for example, creating a global type and a local copy) can affect multiple VOBs with a single operation. The longer the interval between the time that the first member group of related databases is backed up and the time that the last member is backed up, the greater the chance that these relationships will be skewed when any of the backups are restored.

In all but the simplest configurations (those with a few small VOBs), it is unlikely that this procedure could be completed in a reasonable length of time. Even if all the related databases could be backed up at the same time, it is unlikely that they would be restored together. It is far more likely that one or two databases from the set would be restored into an environment where the others were intact, which would again result in skew between the restored and intact databases. Many types of skew between databases can be reconciled by using tools and procedures described in Restoring one or more members of a set of related databases.

The following procedure illustrates a more practical backup strategy.

Procedure

  1. Determine database relationships.

    In an environment where UCM is not in use, database relationships are determined primarily by the structure of administrative VOB hierarchies. Use the HCL VersionVault Administration Console or cleartool describe to display the AdminVOB hyperlinks that point to or from a VOB. (As described in Administrative VOB hierarchies and global types, a VOB can have exactly one AdminVOB hyperlink pointing to its superior in an administrative VOB hierarchy and can have zero or more AdminVOB hyperlinks pointing to it from other VOBs in the hierarchy).

    In a UCM environment, database relationships are determined by the organization of the project. All the modifiable components in a project, as well as its PVOB are related and must be backed up together. (Nonmodifiable components must be backed up also, but because the references held to these components by the PVOB are likely to be valid for longer intervals, you might not need to back up these components on the same schedule as the others.) You can use the Project Explorer or cleartool lsproject to display the components in a project.

  2. Back up the component VOBs.
    If possible, use the vob_snapshot tool, which minimizes backup time for each VOB.
  3. Back up the PVOB using vob_snapshot.
    PVOBs that do not also contain components have no data in their pools and can be backed up by vob_snapshot without risk of data loss. If your configuration includes multiple PVOBs that have a common administrative VOB, back up all the PVOBs and the administrative VOB as a unit. (Lock all the PVOBs and their administrative VOB, back them up, then unlock them.)

Results

This strategy maximizes the chances that, on restore, the PVOB is newer than the component VOBs, which in turn simplifies the reconciliation of database skew.

Regardless of the backup strategy that you use, include these practices:
  • Back up all members of a related group of databases in the shortest amount of time possible.
  • Back up the entire group frequently. On restore, a backup performed yesterday generates far less skew than a backup performed last week.