Restoring a VOB from backup without vob_restore

About this task

In most cases, the easiest way to restore a VOB is to run the vob_restore utility and follow its instructions. The procedure presented here is an alternative approach for circumstances in which you cannot use vob_restore.

Procedure

  1. Log on to the VOB host as a privileged user.
  2. Verify that the target volume has adequate disk space.
    In most cases, an in-place restore does not require more disk space than is available in the VOB’s currently registered storage directory. If you are restoring the VOB to a different location, you can determine the space needed in any of several ways:
    • If the VOB’s admin directory is intact, you can check the VOB storage node of the DevOps Code ClearCase® Administration Console or use the cleartool space command.
    • If the VOB’s admin directory has been destroyed or has data that is not current, you can use ordinary file-system utilities such as dir, ls, or du to get a rough idea of the space consumed by the VOB storage directory.
  3. Stop DevOps Code ClearCase.
    This ensures that the existing VOB’s server processes are stopped.
  4. Remove the existing VOB storage directory.
    Use any file-system utility (rmdir, rm) or a GUI such as Windows® Explorer.
  5. Restart DevOps Code ClearCase.
    Starting DevOps Code ClearCase makes other VOBs and views on the host available.
  6. Load the backup.
    Re-create the VOB storage directory if necessary; then restore the VOB storage directory’s contents from the backup. Use a copy utility that preserves file and directory protections. On Windows, follow the procedures in Preserving NTFS ACLs when copying a VOB or view storage directory. On Linux and the UNIX system, each VOB storage directory includes a subdirectory named .identity, which stores files with special permissions: the setuid bit is set on file uid; the setgid bit is set on file gid. You must preserve these permissions when you copy the backup data to the target:
    • If you use tar, specify the –p option when restoring the VOB. You must run the tar command as root. Otherwise, the –p flag is ignored.
    • If you use cpio, no special options are required.
    Note: On all supported operating systems, if the VOB was locked when it was backed up (the most likely case), it is locked when it is restored. If the VOB was not locked when it was backed up, the backup is probably worthless.
  7. Fix storage directory protections if necessary.
    If your Windows backup tool does not back up and restore ACLs correctly, you might need to fix them now. See Repairing storage directory ACLS on NTFS for details.
  8. Restore remote pools.
    If the VOB is on a host running Linux or the UNIX system and it has any remote storage pools, restore them now. You can simply copy them from the backup to their target locations. Remote pools must be in place when you run checkvob in Step 10.
  9. If you restored the VOB to a new location, re-register the VOB.
    You can use the ClearCase Registry node in the DevOps Code ClearCase Administration Console or cleartool commands to re-register the VOB. For example, if you restored the VOB to new location /vobst_aux/flex.vbs:

    # cleartool unregister –vob  /vobstore/flex.vbs
    # cleartool register –vob  /vobst_aux/flex.vbs
    # cleartool mktag –vob –replace –tag /vobs/flex  /vobst_aux/flex.vbs

  10. Run checkvob.
    After the target directory is populated with the backup data and optional database snapshot, vob_restore prompts you to run checkvob, a utility that can detect and optionally fix discrepancies between the VOB database and storage pools. You can specify the types of pools to check and whether checkvob should try to fix any problems that it finds. These problems are more likely to occur in a VOB that has been restored with a database snapshot, because the database and the pools have been backed up at different times. Periodic maintenance and the checkvob reference page contain more information about checkvob. Review this information, especially if you are going to run checkvob in –fix mode.
    Attention: If you decide to run checkvob in –fix mode, vob_restore unlocks the VOB, then locks it again specifying –nusers username where username is the name of the user running vob_restore. If the VOB is replicated, this user must not make any modifications to the VOB other than those made by checkvob –fix. Otherwise, replication failures and replica divergence will occur.
  11. If the VOB is replicated, run the restorereplica command.
    You must perform this processing while the VOB is still locked.
  12. While the VOB is still locked, run some consistency checks.
    For example, in a view with the default config spec, access the restored VOB and verify that all expected elements and versions are present.
  13. Unlock the restored VOB.

What to do next

The restored VOB is now ready for use, but you might need to take two additional steps: