There are two ways to use MultiSite as a backup strategy:
Using multiple replicas in a local area network may help with reliability, availability, performance, and backup strategy. However, recovery issues limit how easily and rapidly clients may be switched from one replica to another. The details of the recovery process are described in Restoring and Replacing VOB Replicas.
Using MultiSite for backups means that the backup replica needs to remain online so that it can be updated frequently from the original. Almost twice as much disk space is required (you do not need exactly twice as much space, because derived objects are not replicated and the cleartext pool for the backup replica is smaller or nonexistent). Also, you need a MultiSite license as well as a Rational ClearCase license for each developer who accesses the replicated VOB.
To back up a VOB consistently, the ClearCase administrator must lock the VOB. However, many administrators cannot find convenient times to lock the VOB so that the lock does not interfere with development work. One solution is to use MultiSite to create a replica of a VOB in the same local area network as the original. Updates from the original VOB to the backup replica are scheduled to match the recovery characteristics desired, that is, how much development work you can afford to lose. At backup time, the backup replica is locked and backed up, thereby not interfering with development work at the original VOB.
The most important thing to note is that some objects in a VOB are not replicated. The following objects are not replicated, and therefore are not restored from backup:
After a recovery from backup, developers must rebuild derived objects associated with the VOB. Checked-in derived objects are replicated, so they are backed up.
To ensure that you can re-create triggers after a restoration from backup, you must record information about all triggers in a VOB replica. For example, use the command lstype –kind trtype to list all triggers in a VOB, use the describe trtype: command to list details about each trigger, and then save that information somewhere outside the VOB.
As with triggers, you must record information about nonobsolete locks. You can write scripts that capture and re-create the trigger and lock information.
Also, pool assignments are specific to a replica, so re-creating the replica from a backup replica can undo changes made to them. If you make major changes to a VOB’s pool structure, use the chpool command to duplicate these changes at the backup replica. (At replica creation, you can also use the –pooltalk option with mkreplica –import to make pool assignments.)
You must determine the frequency and direction of synchronization. Typically, synchronization occurs in one direction only; that is, the backup replica never sends packets to the development replica, except during restoration.
Frequency of synchronization depends on your development environment. Some replicas synchronize every 24 hours, but replicas with rapid development may synchronize every 15 minutes.
When you use a replica as an incremental backup of a VOB, you still back up the original VOB. You set up a replica of the original VOB in the same local area network, and schedule frequent unidirectional synchronizations. If you restore the original VOB from backup, the replica serves as an incremental backup by supplying changes made since the last backup.
This strategy reduces the frequency of backups at the original replica. It avoids some of the procedures described in Restoring a Replica from Backup, but still requires saving information about triggers, locks, and major pool changes. It also has the same limitations as unreplicated recovery from backup: a view and a VOB may not be consistent with each other after ClearCase recovery. It can, however, reduce the frequency of backups enough to fit into normal maintenance schedules.
The backup replica must be registered with a different registry host.
Use the procedure described in Restoring a Replica from Backup.