Considerations for restoring journaled objects

 

For an object that is restored and associated with a local journal in standby state, journaling starts for that object, but no restore entry is deposited in the journal receiver. If the object is being restored-over and is currently journaled to a local journal in standby state, the restore is not prevented, and no restore entry is deposited in the journal receiver.

The system will send a diagnostic message for any object in which the 'object restored' journal entry cannot be sent due to a problem with the journal or attached journal receiver, unless the journal is in standby state. The system always attempts to start journaling for an object that was journaled at save time to the same named journal, in the same named library, during a restore operation. This is still true, and there are no processing changes to note if a local journal is found by the restore processing. However, if a remote journal is found by the restore processing, the restore is completed successfully, but journaling is not started for the restored object. A diagnostic message is sent that indicates that a remote journal was found by the restore processing. This message is followed by the message that is already sent that indicates journaling was not started.

In a hot-backup configuration, a local journal is used on the backup system to capture the changes that are made to the objects on the remote system. This occurs when the remote system is logically promoted to assume the role of the primary system. The local journal that is being used on a backup system might not be in the exact same-named library as the journal that is being used for the object at save time. If this occurs, you are responsible for starting journaling for the restored objects. This is a fundamental reason to use library redirection for all defined remote journals.

 

Parent topic:

Considerations for save and restore operations with remote journals