If a Secondary volume becomes corrupted due to I/O errors, the volume can be restored from backup. When a
restore is initiated, a request is sent to the Primary to begin updates from a previously recorded checkpoint. A r
estore is not guaranteed to succeed though because checkpoints can become stale which means that the Primary has stopped maintaining the updates necessary for the restore. If this occurs, the Secondary RVG must be re-initialized using a Primary checkpoint or an autosync attach instead of being restored from backup.
If a Secondary data volume fails the RLINK is put into the fail state. A restore from an online backup copy becomes necessary. This can only be done if a suitable Primary or Secondary checkpoint exists. If a Primary checkpoint still exists, it can be used if there is no Secondary checkpoint.
To restore a Secondary from an on-line backup, first restore the data from the on-line backup to all of the volumes. Because of internal constraints, you must restore all volumes even if only one has failed. (The normally read-only Secondary data volumes are writable while the Secondary is in fail state.) Then, execute the
rlink command, which causes the Secondary to request all updates which were made subsequent to the checkpoint from the Primary.
As with Primary checkpoints, if the checkpoint is not used before the SRL wraps around and the SRL overflows, the checkpoint will become STALE. If the checkpoint becomes STALE, you cannot use the methods described in this section to restore the data. You must synchronize the RLINK. See Methods to synchronize the Secondary for details. To prevent the checkpoint from becoming STALE, make sure the SRL is large enough to hold all of the updates which occur between the
pause command and the
On the Secondary:
vxrlink -g diskgroup
In situations where you need to perform a restore when the RLINK is not in a fail state, use the following command to get the RLINK in a fail state:
For example, you need to get an RLINK back in the fail state if a data volume fails, you restore from backup, and then after performing the restore command, you realize that the wrong backup was used. In this case, you need to get the RLINK back in the fail state before you perform the
While the restore is occurring, the RLINK is inconsistent. It becomes consistent when the
restore command completes successfully.