Backup and restore a Remote Secondary Server(RSS)

It is possible to archive a Remote Secondary Server and to back up logical logs on that node, using onbar or ontape. This archive may then be used to rebuild the RSS if necessary, saving time over using an archive that is taken on the primary and copied to the secondary machine.

Although an archive and log backups taken on an RSS node may be used to restore a primary node, they are recommended for this purpose only when no other archive exists. The logical log position on the secondary is often several logs behind that of the primary, which means the last logical logs backed up on the RSS may not be the last log completed on the primary. This is not a problem when the archive is used to recreate the RSS, because once reconnected to the primary the logs will be resynchronized and no transactions will be lost.

Prerequisites for taking archives and log backups on an RSS node are as follows:

  1. Enable the feature by setting the BAR_SEC_ALLOW_BACKUP configuration parameter to 1 and restarting the RSS. This parameter may not be tuned dynamically.
  2. Ensure that the RSS node has one or more active temporary dbspaces, and that they are listed in the DBSPACETEMP configuration parameter. Once an archive begins, all pages physically logged for a particular space will need to be stored until that space has been archived. The temporary dbspaces listed in DBSPACETEMP are used for this before-image storage. The total amount of temporary space required will vary according to the update load on the RSS during the archive, which will fail to complete if it runs out of temporary space.
  3. Set the TAPEDEV, LTAPEDEV, and BAR-related configuration parameters to appropriate values depending on your preferred backup utility.
  4. The primary node must not contain any of the following non-logged objects:

    1) BLOB spaces

    2) Non-logged smartblobs

    3) No-log databases

    4) Raw tables

    If any of these unlogged objects are present in the instance, an archive taken on the RSS node will fail because the archive would be incomplete and therefore unusable for restoration on a primary node.

  5. In order to back up logical logs on an RSS node the LTAPEDEV configuration parameter must not be set to the Null device. If logical logs will not be backed up on the RSS node, LTAPEDEV must be set to the Null device. Note that these two rules apply on an RSS node only when BAR_SEC_ALLOW_BACKUP is set to 1. When BAR_SEC_ALLOW_BACKUP is set to 0 the setting of LTAPEDEV on the RSS node must be in sync with that of the primary, and no logical log backups will be allowed or required on the RSS node regardless of the LTAPEDEV setting.

If it becomes necessary to recreate the RSS node from an archive and log backups taken on that node, the same procedures used for restoring archives taken on the primary may be used with the local archive. No new configuration changes or steps are required.

Even when taking archives and log backups on an RSS node, it is recommended that archives and log backups be taken on the primary as well, because restoration of the primary is likely to be faster with a local backup and there is a greater chance that all committed transactions will be salvaged and restored. Again, the risk of lost transactions is not an issue when recreating the RSS from a local backup as long as the primary node can forward all missing logs to the RSS during synchronization.

In an emergency it is possible to perform a cold restore of a primary node using an archive taken on an RSS and log backups taken either on the RSS or the primary. This process is made simpler with the ontape utility but is also feasible with onbar.

  • If using ontape, simply restore the archive and roll forward the log backups as usual, regardless of the origin of these backup elements.
  • If using onbar the storage manager containing all backup objects must be available on the primary, and you must replace the ixbar file on the primary with the ixbar file from the RSS node before performing the restore.

Using an archive taken on an RSS node for a warm restore on the primary node is not recommended.