The following illustration shows a data backup cycle, where three points in time of disk failure occurrences are marked for the following recovery examples. Examples of tape labels that CONTROL uses to identify the individual save actions are given in parentheses on the right.
If the log is also damaged, the recovery procedures outlined in the following three examples require the existence of at least one intact log devspace which can be used in log mode DUAL or NORMAL to recover the defective log devspace (see Section Backup / Restore / Devspace).
Recovery After Disk Failure A
To recover the database after the disk failure A, only the first backup version of the data devspace must be restored using Backup / Restore / Data. The subsequent restart completes the data devspace redoing the transactions recorded in the log.
Recovery After Disk Failure B
When disk failure B occurs, there are several ways of recovering the serverdb. The quickest method of recovery consists of reloading the database using Backup / Restore / Data and subsequently reloading the modified pages using Backup / Restore / Updated Pages. Finally, Backup / Restore / Log (UNTIL) must be performed to restore the backups of the log segments 7 and 8.
The correct choice of the log segments 7 and 8 after restoring the pages (1.2) corresponds to the ascending serverdb version which can be found in the protocol of the corresponding data backup. A correct selection prevents failures.
Since Restore / Log overwrites the log, the current log version, which is not contained in the log segments saved so far, must be backed up to an external backup device or a host file using Save / Log (Cold). Then the backups of the log segments can be restored using Restore / Log. In log mode DUAL or NORMAL, the backup of a log segment is implicitly copied onto both log devspaces. Once the log segments 7 and 8 are restored, the copy of the current log that was backed up using Save / Log (Cold) must be restored using Restore / Log. Restart completes the recovery.
First restore variant:
There is a choice of previous backups of the log segments which can be used for the recovery of the serverdb.
Second restore variant:
Third restore variant:
Recovery After Disk Failure C
When disk failure C occurs, the serverdb can be recovered in the following way:
Only the last backup version of the data devspace needs to be restored. If this version is not readable for some reason, older data backup versions can be restored which require that the corresponding log segments are redone.
First restore variant:
Second restore variant:
The same procedure must be used if organizational reasons require an older database state to be restored. Backup / Restore / Log (UNTIL) can then be used to select the point in time of the desired database state.
Recovery After Disk Failure D
Example 1:
Of a restored log segment that does not match the restored data save.
The most recent complete backup is to be used for the recovery before loading the backups of the log segments. Usually, you proceed according to the backup protocol loading the log segments in the order of creation.
For this restore variant, the version number 201 in the LOG_B1_1 label shows that log segment 11 was completed before the complete DATA_B0_A save. Therefore, the error -8003 is returned when this log segment is restored after the complete DATA_B0_A save. This error can be ignored and the next save of a log segment (see the backup protocol file) LOG_B2_1 can be loaded.
Example 2:
Of a restored log segment that does not match the restored data save.
First restore variant for disk failure B in this section:
In this example, log segment 1, LOG_A1_1, is loaded erroneously instead of log segment 7. The version numbers 178 and 131 within the labels show that DATA_A8_A cannot be followed by LOG_A1_1. The error message "-8003 log and data must be compatible" is output. In this case, you only need to continue with the correct log segment 7. The next log segment to be restored can be looked up in the backup protocol file.