Restoring and replacing VOB replicas

Occasionally, a VOB storage directory is lost. This can occur because of a hardware failure (for example, disk crash), a software failure (for example, operating system-level file system corruption), or a human error (for example, an rm –fr or del command). If an unreplicated VOB storage directory is lost, you can restore a recent copy from backup and resume development work. The changes made between the time of the backup and the time of the failure are not recoverable.

Similarly, if you lose the storage directory of a replicated VOB (that is, the storage for the replica used by developers at your site), you can restore a recent copy from backup. But matters are more complicated:
  • Some of the work done between the time of the backup and the time of the failure may be recoverable. If some of the operations were sent to other replicas in update packets, these operations must be retrieved and imported.
  • The restored copy of the replica is out of date. You must make this replica consistent with the other replicas in the VOB family before development can proceed in the replica. Failure to reestablish consistency can lead to irreparable damage.

Because this procedure involves substantial effort, it is intended for situations where serious damage has occurred. (For example, the disk containing a replica is unusable.)

The method you use to restore the replica depends on how you back it up:
  • If you lock your primary replica to back it up, you must restore it from the backup medium and perform the restorereplica procedure. See Restoring a replica from backup.
  • If you never lock your primary replica and rely solely on a replica at your site as backup, you must replace the replica completely. See Replacing an existing replica.