S 6.51 Restoring a database

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

A concept must be drawn up for the restoration of databases that specifies the procedures for restoring databases from database backups. This concept is based on the following:

Based on this information, it must be determined which database backups must be restored and how to restore them.

The restoration of a database can become a complex task requiring extreme care and the procedures of which must be tested in regular test runs. In spite of this, it is still possible to encounter errors or difficulties during the restoration process.

Two aspects must be coordinated during restoration. On the one hand, the affected database should be made available again as quickly as possible to the users and, on the other hand, it is necessary to determine the cause of the damage and to restore the database to the most current state possible. If the failure of the database cannot be attributed unambiguously to damaged hardware, it is often very difficult to determine the number of inconsistencies. In addition, it is not always possible to restore the database up to the last transaction performed before the error was discovered without encountering problems.

In such cases, it must be decided if it is better to accept a limited loss of the most recent data or a longer interruption to database operations. This depends mainly on what the database is used for, the type of error, and the amount of time between the first occurrence of the error and the detection of and/or initial reaction to the error. It is often difficult to determine the scale of the damage, especially when the damage was caused by incorrect administration or unauthorised manipulation.

Guidelines for making these decisions and the corresponding instructions must be included in the restoration concept. To make the database available again as quickly as possible, the affected database should be restored and released for use by the users on a separate system or storage area. If the data access functions are stored separately from the data (see S 2.134 Guidelines for database queries), the database can mostly be restored without the users even noticing it.

In no case should the destroyed database simply be overwritten by restoring the database from a database backup without further examination (see S 6.48 Procedures in case of a loss of database integrity). In many cases, it is possible to correct a database considered inconsistent by restoring individual databases, without having to perform a full restoration of the database. Even in the case of a partial restoration, consideration should be given to restoring the database at a different location on a test system first and then correcting the original database after ensuring it is possible to restore the database properly.

Even if it is impossible to repair the corrupt database, it should still be kept for the purpose of analysing and determining the cause of the failure of the database.

The restoration concept should specify which resources must be held in reserve and in which amounts in case of an emergency. Basic values to take into consideration when specifying this include, in particular, the memory capacities and the free hard disk space. These values must be examined regularly and compared to the current size of the database to ensure that it is possible to minimise the effects to other databases in an emergency.

Review questions:

© Federal Office for Information Security. All rights reserved.