Restoring a Secondary RLINK
Prev Restoring the Secondary from online backup Next

Restoring a Secondary RLINK

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 Storage Checkpoint exists. If a Primary Storage Checkpoint still exists, it can be used if there is no Secondary Storage 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 vxrlink -c checkpoint_name restore rlink command, which causes the Secondary to request all updates which were made subsequent to the Storage Checkpoint from the Primary.

As with Primary Storage Checkpoints, if the Storage Checkpoint is not used before the SRL wraps around and the SRL overflows, the Storage Checkpoint will become STALE. If the Storage 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.

To prevent the Storage Checkpoint from becoming STALE, make sure the SRL is large enough to hold all of the updates which occur between the vxrlink -c checkpoint pause command and the vxrlink -c checkpoint restore command.

Synchronizing the RLINK to prevent STALE Storage Checkpoints

On the Secondary:

  1. Assuming the RLINK is in the fail state, restore the backup to the data volumes.
  2. Restore the RLINK to initiate updates to the Secondary data volumes:
    # vxrlink -g diskgroup -c checkpoint_name restore rlink_name

Note:

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:

# vxrlink -g diskgroup -w pause rlink_name

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 restore command.

While the restore is occurring, the RLINK is inconsistent. It becomes consistent when the vxrlink restore command completes successfully.

Prev Up Next
Restoring from Secondary Storage Checkpoints Home Using VVR for off-host processing