Apuntes de la Historia minera en las comunidades del Altiplano-Wirikuta

When a mirrored database is the target of a Caché 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.

Caché 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 remove it from the mirror; for more information, see Removing Mirrored Databases from Mirrors in the “ Mirroring ” chapter of the High Availability Guide.

• 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.

2.8.5.1 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 Caché Online Backup Restore Utility in this chapter) or non-interactively via the EXTALL entry point (see External Entry Points of ^DBREST in this chapter):

• A full backup restore on the system that created the backup works as it does for non-mirrored 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:

1. Activate the mirrored databases by restoring the required journal files.

2. Link the mirrored databases into the active mirror (if the mirror exists and a copy of the database does not already exist).

2.8.5.2 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 they should be restored. You can specify a path, an “ X ” or “ x ” (to skip the directory), or press ^Enter to restore it to the path stored in the backup.

When restoring a backup on a mirror member other than the system that created the backup, pressing Enter for a mirrored directory restores it to the corresponding copy of that database on the local system. If there is no corresponding local copy, a message is displayed and you are asked to enter an explicit path or to skip it.

• 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 non-mirrored database or a different mirror database).

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 ^EXTSELECT entry point (see External Entry Points of ^DBREST in this chapter), 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 non-mirrored 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:

1. Activate the mirrored databases by restoring the required journal files.

2. Link the mirrored databases into the active mirror (if the mirror exists).

2.8.5.3 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).