Replaces missing operations in a replica that has been restored from backup
restorereplica [ –c·omment comment | –cfi·le comment-file-pname | –cq·uery
| –cqe·ach | –nc·omment ] [ –f·orce ] [ –override ]
[ –invob vob-selector | [ –rep·lace ] replica-selector ... ]
Warning: Execute this command immediately after you restore a replica from backup. Proceeding with normal development at a restored replica before executing this command causes irreparable inconsistencies among the replicas in a family.
restorereplica replaces missing changes in a VOB replica that has been restored from backup, as follows:
The current replica remains in the restoration state until you have received and applied (using syncreplica –import) all the restoration updates needed to bring the replica up to date with the state of the family. Collectively, these updates include all the changes to the family since the backup was made, including changes made in the current replica before its failure.
You cannot recover changes that were made after the last synchronization export from your current replica. For example, if your replica was backed up on Wednesday at 12:30 P.M. and your last synchronization export was Thursday at 3:00 P.M., you can recover all changes made until Thursday at 3:00 P.M. All changes made after that time are lost.
During the process of restoration, the lsreplica –long command annotates its listing to indicate which replicas must send restoration updates to the replica.
For a description of the replica restoration procedure, see Restoring and Replacing VOB Replicas.
restorereplica locks the current replica’s VOB object. Locking it ensures that while restoration proceeds through execution of syncreplica –export and syncreplica –import commands, no other changes are made to the current replica.
When syncreplica applies the final required update, it displays a message indicating that the restoration process is complete. At this point, use the cleartool unlock vob: command to unlock the restored VOB replica, enabling normal development to proceed.
By default, restorereplica requires that the replica receive restoration updates from all other replicas in its family (either directly or indirectly). Only after all the updates are imported does the syncreplica command display the message indicating that restoration is complete.
In some cases, you can relax this requirement without compromising the correctness of the restoration process. The replica will be brought up to date if it receives a restoration update from only one replica—the last one to which the replica sent an update before it was restored from the backup version. You can specify the name of that last-updated replica (or a list of replicas, one of which must be the last-updated one) to restorereplica. syncreplica displays the restoration-completed message after receiving restoration updates from all the specified replicas.
Warning: If you use this optimization incorrectly, you can make the restored replica irreparably inconsistent with other replicas.
Identities: You must have one of the following identities:
Locks: No locks apply.
Mastership: No mastership restrictions.
Default
Creates one or more event records, with commenting controlled by the standard ClearCase user profile (default: –cqe). See Event Records and Comments in the multitool reference page. To edit a comment, use cleartool chevent.
–c·omment comment-string | –cfi·le comment-file-pname | –cq·uery | –cqe·ach | –nc·omment
Overrides the default with the specified comment option.
Default
restorereplica prompts you for confirmation.
–f·orce
Suppresses the confirmation step.
Default
Processes the replica that contains the current working directory.
–invob vob-selector
Processes the current replica in the specified family. Specify vob-selector in the form [vob:]pname-in-vob
pname-in-vob
|
Pathname of the VOB tag (whether or not the VOB is mounted) or of any file system object within the VOB (if the VOB is mounted)
|
Default
The syncreplica command declares the replica to be restored completely only after updates are received from all other members of the VOB family and imported.
Warning: Incorrect use of these options allows new changes to be made to the replica before all missing changes are received from other replicas. This may place the entire family in an irreparably inconsistent state.
replica-selector ...
Specifies a subset of replicas from which updates are required before syncreplica declares the replica to be restored completely. Specify replica-selector in the form [replica:]replica-name[@vob-selector]
–rep·lace replica-selector ...
Changes the subset of replicas from which restoration updates are required.
–override
Overrides normal restoration processing and declares the VOB to be restored completely. The lsreplica –long command no longer annotates any replicas as needing to provide updates, and you can use cleartool unlock vob: to place the replica back in normal service.
When you specify this option, the command displays a list of replicas from which updates have not been received and prompts you to cancel the operation or continue.
For an example of restoring a replica, see Restoring and Replacing VOB Replicas.
chepoch, lsepoch, lsreplica, syncreplica