Restoring a replica from backup

If you lock your primary replica to back it up, you must restore it from the backup medium and perform the restorereplica procedure.

About this task

To restore a replica from backup:
  1. Follow the procedure in the DevOps Code ClearCase Administrator's Guide to load the backup copy of the VOB storage directory.
  2. Run checkvob against the restored VOB backup to check for and resolve any container issues before running the restorereplica command. After the restorereplica command has locked the VOB for restoration, you can not interrupt the restorereplica process to make checkvob updates.
  3. Run the command to restore the replica: 
    multitool restorereplica –invob vob-selector

    This places a special lock on the VOB object, which is separate from the ClearCase® lock created during the backup process. Between this point and the when you complete the final syncreplica –import operation later in this process, the syncreplica –import command adjusts the ClearCase lock temporarily to permit application of the update, then restores the full lock. During this time, only syncreplica –import can modify the replica.

  4. Verify that all update packets have been processed at their destination replicas.
  5. (Applicable only if the replica you are restoring was used to create one or more new replicas between the time of the backup and the time of the failure, and the other replicas in the family do not have information about the new replicas.) The new replicas are unknown to your restored replica and all other replicas in the family, and lsreplica does not list them. If this is the case:
    1. At each new replica, set the estimated states of the siblings to their actual states. (Use chepoch –actual or lsepoch/ chepoch. See Recovering from lost packets.)
    2. At each new replica, export update packets to all other replicas in the family except the restored replica.
    3. Import the packets exported in the preceding step.
  6. At the restored replica, generate update packets for all other replicas, and send the packets to the sibling replicas.

    You can send the packets using your standard synchronization method. To recover the replica more quickly, create the packets with syncreplica –export –fship.

    Because your replica is in the special restoration state, each outgoing update packet includes a special request for a return acknowledgment. It also includes your replica’s old epoch numbers, which are now its current epoch numbers, by virtue of the restoration backup in the first step of this procedure. Each destination replica uses these numbers to roll back its row for your replica.

  7. Wait for each other replica in the family to send an update packet to the restored replica. As in the preceding step, you can accelerate the creation and delivery of the update packets.

    Collectively, these update packets include all operations that occurred between the time of the backup and the last update that your replica sent out before its storage was lost, even operations that originated at your replica. (The packets also include more recent operations that originated at other replicas.) In addition, each incoming packet includes the requested return acknowledgment from the sending host.

  8. Process the incoming update packets with syncreplica –import. When your replica has received return acknowledgments from all other replicas in the VOB family, syncreplica –import reports that restoration of the replica is complete: 
    VOB has completed restoration: ...
  9. (Applicable only if you had to perform Step 5) At one of the replicas that did not have information about the new replicas before the restoration procedure, export update packets to all of the new replicas and import the packets at the new replicas. (Do not perform this export from the restored replica.)
  10. Unlock the VOB object in the restored replica. 
    
cleartool unlock vob:pname-in-vob
Unlocked versioned object base "VOB-tag".

Development work in the replica can now resume.