Mirrored Database Considerations

When a mirrored database is the target of an InterSystems IRIS backup restore, the source database must match the target (that is, it must be the same mirrored database).

Note:

Mirrored database backups created on a failover mirror member can be restored to any member of that mirror (that is, another failover member or an async member). If you are restoring from a backup created on an async mirror member, see Restoring from Async Mirror Members.

In this section, the term “active mirrored database” refers to a database that is currently included in a mirror to which its host system belongs, even if that mirror is not currently in operation. It does not include databases that were once mirrored, or that were included in a mirror to which the host system no longer belongs.

InterSystems IRIS backup restore in a mirror behaves differently depending on whether it is being restored on the mirror member where the backup was created or on a different system:

Primary Failover Member — ^DBREST does not let you restore an active mirrored database on the primary failover member. However, if the database must be restored, you can temporarily remove it from the mirror (see Removing Mirrored Databases from Mirrors). The database is restored as a mirrored database, however (since it was backed up as one), and the functionality described in the following sections applies, including automatic restore of the journal files required to activate the database in the mirror.

Backup Failover Member — On the backup failover member, restoring a mirrored database that is active, or newer than the copy in the backup, results in a warning message:
- For a full backup restore, these databases are skipped.
- For a selective restore, you are given a chance to overwrite the target if that is what you really want to do.

Full Backup Restores of Mirrored Databases

The following differences apply to full backup restores of mirrored databases, whether they are done interactively via the ^DBREST utility (see Online Backup Restore Utility) or non-interactively via the EXTALL entry point (see External Entry Points of ^DBREST):

A full backup restore on the system that created the backup works as it does for nonmirrored systems, except that local mirrored databases that are newer than the copies in the backup — which, by definition, includes databases that are currently active — are skipped; all databases are restored to their original locations.
A full backup restore on a mirror member other than the system that created the backup restores only mirrored databases that already exist on the system. However, mirrored databases on the target system that are newer than those in the backup are skipped.
A full backup restore that specifies a new top-level directory restores all the databases in the backup after generating the new path for the databases. If the user ends up with two copies of any of the mirrored databases after the restore, they are warned that the copy being restored cannot be activated because it is already active on the system.

Following a full backup restore the system attempts to:

Activate the mirrored databases by restoring the required journal files.
Link the mirrored databases into the active mirror (if the mirror exists and a copy of the database does not already exist).

Selective Backup Restores of Mirrored Databases

The following differences apply to selective backup restores of mirrored databases:

When a backup is being restored, you are asked whether to limit the restore to only mirrored databases; depending on your response:
- yes — Only the mirrored databases are displayed.
- no — You are prompted to select destinations for all the databases in the backup.
During the database selection phase of a selective restore, you are presented with a list of the databases in the backup and asked to specify a path where each should be restored. You can specify a path, enter an “X” or “x” to skip that directory, or press Enter to restore it to the path stored in the backup, if you are restoring on the source system.
When restoring a backup on a mirror member other than the system that created the backup, the result of pressing Enter for a mirrored database directory varies depending on whether an active mirrored database with the same mirror database name exists on that system.
- If the database exists, pressing Enter overwrites the existing database with the restored database, regardless of the existing database’s directory path, including whether that path is the same as on the source system.
- If the database does not exist, the database is restored to the directory path it has on the source machine. If that path does not exist, you must confirm the creation of the needed directories. If a database already exists at that location, no action is taken.
If a selective backup restore detects that the restore is going to overwrite a mirrored databases in the following situations, you are warned that continuing will destroy the target database and asked if you want to continue:
- The database from the backup is older than the current database.
- The database from the backup is not a copy of the current database (for example, it could be a nonmirrored database or a database of the same mirror database name from a different mirror).
If you continue, the target database is removed from the mirror and overwritten as requested.
If a selective backup restore is being done non-interactively via the EXTSELCT entry point (see External Entry Points of ^DBREST), the database selection file the source and target paths can be specified with either path names or mirror databases names.
For a mirrored database, if the target is left blank it means restore to the corresponding mirror database on the local machine. If the target is not blank, then the database must be one of the following:
- The correct, local copy of that mirrored database.
- If a local copy of that mirrored database does not already exist on the system, a nonmirrored database (or a directory/database that does not exist) .
- A mirror database name.
Note:

If the target is a mirror database name (or blank) and that mirrored database does not exist on the local system (or is dismounted), the target is created only if the backup is being restored on the system that created it. If the backup is being restored on another mirror member the database is skipped.

As with full backup restores, following a selective backup restore, the system attempts to:

Activate the mirrored databases by restoring the required journal files.
Link the mirrored databases into the active mirror (if the mirror exists).

Restoring from Async Mirror Members

The following considerations apply when restoring from mirrored databases created on async mirror members:

Mirrored databases backups created on a async mirror member can be restored to any async member of the same mirror.
Mirrored databases backups created on a async mirror member can only be used to create new copies of the mirrored database (that is, they cannot be restored over an existing mirrored database on a failover member).

Unattended Restore Using ^DBREST