Running vob_restore

About this task

This topic summarizes the steps required to restore a VOB when you use the in-place restore scenario. Both variants are described.
Note: Many vob_restore prompts allow you to quit. If you quit at any of these prompts, vob_restore saves its current state in a restart file and displays the name of that file on standard output. You must use this file name as the restart_path argument to vob_restore to restart after you have quit.

Procedure

  1. Log on to the VOB host.
    Log on 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 to a different location, you can determine the space needed for the VOB in any of several ways:
    • If the VOB’s admin directory is intact, you can check the VOB storage node of the HCL VersionVault 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. Exit any view context.
    You cannot run vob_restore in a view.
  4. Run vob_restore.
    Unless you are restarting an incomplete vob_restore, the command takes a single argument that specifies the VOB tag:

    vob_restore vob-tag

    If you are restarting an incomplete vob_restore, you must also supply the –restart restart_path option. vob_restore displays some introductory information and requests confirmation to proceed.
  5. Enter the target path.
    This is the path to which you want to restore the VOB. On a computer running Linux or the UNIX system, specify a host-local path (for example, /vobstg/libpub.vbs). On a Windows® computer, specify a UNC path (for example, \\ccsvr01\vobstg\libpub.vbs).
  6. Enter the source path.
    This is the path where vob_restore can find the backup data. If you use the variant of the in-place restore that requires a temporary staging area, enter its pathname. Otherwise, enter the pathname of the VOB’s currently registered storage directory (the same pathname you entered in Step 5), but do not copy the backup data to that path until you are prompted by vob_restore (see Step 16).
  7. Enter the path at which vob_restore can find the database snapshot.
    If you are restoring a VOB backed up with vob_snapshot, supply the snapshot pathname now. Otherwise, press RETURN to skip this step.
  8. Specify whether the backup is currently accessible.
    If the backup data is available at the path you entered in Step 6, enter yes at this prompt. Otherwise, enter no.
  9. Review the summary information and decide whether to proceed.
    If the information is correct and you are ready to proceed with the restore, enter yes. Otherwise, enter no.
  10. Check the VOB database.
    If the backup and optional database snapshot are accessible, vob_restore might prompt you to allow it to validate the integrity of the database if either of these conditions exist:
    • You are restoring a database snapshot (you entered a path in Step 7).
    • You are using a standard backup (you did not enter a path in Step 7) and vob_restore detects that the database was not locked during backup.
    If the database fails this test, vob_restore cannot continue. (If you answered no in Step 8, the database check is deferred until you have loaded the backup in Step 16.)
  11. Restore remote pools.
    If the VOB is on a host running Linux or the UNIX system, it might have remote storage pools. The vob_restore command prompts you to restore them now. Copy them from the backup to their target locations. Press Return when the remote pools have been restored, or, if there are no remote pools, to continue.
  12. Verify that the database snapshot should replace the database in the backup.
    If you are restoring a VOB backed up with vob_snapshot, vob_restore prompts you to confirm that it can overwrite the database in the backup with the one in the snapshot. To do this, enter yes. Otherwise, enter quit and rerun this procedure specifying no in Step 7.
  13. Remove the VOB tag and unregister the VOB.
    Before it can continue, vob_restore must remove the VOB tag and unregister the VOB. vob_restore prompts you to remove any tags that might exist in other registry regions and to unregister the VOB in any other registries. Press Return when you have completed this task or, if there are no other tags or registries, to continue.
  14. Verify that it is safe to shut down HCL VersionVault.
    vob_restore has to stop the VOB’s server processes before the restore can proceed.
  15. Remove the existing VOB storage directory.
    After it has stopped HCL VersionVault, vob_restore prompts you to remove the existing VOB storage directory. Press Return when the directory has been deleted.
  16. Copy the backup data to the target.
    If you responded no in Step 8, vob_restore prompts you to load the backup now. Press Return when the backup has been loaded.
    Note: 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.
  17. 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.
  18. If the VOB is replicated, run the restorereplica command.
    You must perform this processing while the VOB is still locked.
  19. 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.
  20. Unlock the restored VOB.
    vob_restore always leaves the VOB locked when it exits.

What to do next

The restored VOB is now ready for use, but you might need to take two additional steps:
Limitation: On UNIX and Linux systems, vob_restore changes the owner/group of the VOB storage directory and its db directory from the original VOB owner/group to root/root group, with the following consequences:
  • If the db snapshot directory is specified for db backup, vob_restore exits without starting checkvob because the owner/group of the VOB db directory changed from the original owner to root, the identity that started vob_restore).
  • If the db snapshot directory is not specified for db backup, vobs_restore starts checkvob and then fails for the same reason (that is, root has become the owner).
To address these situations, change the owner/group of the VOB directory (*.vbs) and its db directory (*.vbs/db) back to the original VOB owner/group using the UNIX commands chown/chgroup and then run vob_restore -restart.