Backing Up the Secondary

You must take backups on the Secondary on a regular basis to guard against the consequences of disk failures. The Secondary checkpointing facility allows volume-level backups of the RVG to be restored at the Secondary node.

To get a consistent backup, replication must not be active. You do this by initiating a Secondary checkpoint at the Secondary node. This causes a request to be sent to the Primary node to pause updates and record the Secondary checkpoint in the SRL. While replication is paused, take a block-level backup of the RVG at the Secondary node. When the backup is complete, resume replication. Initiating a resume at the Secondary node causes a request to be sent to the Primary node to resume updates. Note that the Secondary cannot do a checkpoint if it has lost contact with the Primary.

If you must recover from Secondary data volume failure, then after the block-level backup has been restored, subsequent updates can be replayed from the Primary starting at the checkpoint and the Secondary can be brought up-to-date. The Secondary can be brought up-to-date only if the updates are still in the SRL. You can display a list of checkpoints on the Secondary using the vxrlink cplist command. For more information, see Displaying a List of Checkpoints.

Checkpoint Pause/Resume Secondary RLINK

If a Secondary data volume fails and there is a checkpoint backup created as outlined above, you can restore from this backup copy without having to do a full Primary resynchronization of all the volumes. This procedure is also referred to as doing an online restore for the Secondary, because it is not necessary to stop the Primary RVG to bring a new copy of the Secondary data volume up-to-date.

The checkpoint string can be up to 19 characters long for either a Primary or a Secondary checkpoint. Only the most recent Primary checkpoint string is displayed in the Primary RVG.

Unlike a simple Secondary pause, a checkpoint Secondary pause will fail if the Secondary is disconnected from the Primary at the time the command is executed, because communication with the Primary is required to create the checkpoint.

  To create a Secondary checkpoint

On the Secondary:

1. Pause the RLINK using a checkpoint.
     # vxrlink -g diskgroup -c sec_checkpointname pause rlink_name

   ---

     Note    Pausing the RLINK with a checkpoint on the Secondary creates the Secondary checkpoint.

   ---

2. Back up all the volumes in the Secondary RVG, using a block-level backup.
3. Resume the RLINK.
     # vxrlink -g diskgroup resume rlink_name

  To delete a Secondary checkpoint

1. Pause the RLINK using a checkpoint on Secondary.
     # vxrlink -g diskgroup -c sec_checkpointname pause rlink_name
2. Delete the Secondary checkpoint, using the following command:
   # vxrlink -g diskgroup -c sec_checkpointname checkdelete \ rlink_name

   ---

     Note    Perform step 2 only on the Primary.

   ---

Restoring the Secondary from Online Backup

Restoring from Secondary Checkpoints

If a Secondary volume becomes corrupted due to I/O errors, the volume can be restored from backup. When a vxrlink restore is initiated, a request is sent to the Primary to begin updates from a previously recorded checkpoint. A restore 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.

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 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 vxrlink -c checkpoint_name restore 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 vxrlink -c checkpoint pause command and the vxrlink -c checkpoint restore command.

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.