Restoring Databases

After a database failure, for example due to a hardware error, you can restore your database or revert it to an earlier state by importing data backups and log backups from data carriers.

Note that if you need to import a lot of data, restoring the database can take quite a long time. During restoring, the database is not available to users. For information about how to make the database available for users more quickly, see Restoring from a Group of Parallel Data Carriers and Replication and High Availability.

When it starts the restore process, the database system first attempts to import redo log entries still present in the log area. If you want to prevent this and force the deletion of all redo log entries in the log area, initialize the log area before starting to recover your database (this is a part of the restore procedure in Database Studio). More information: Initializing Databases

Prerequisites

You have the data and log backups for the database.

More information:
- Backing Up Data
- Backing Up Log Entries
If you want to restore the database using data carriers on a remote computer (not the database computer), then additional preparations may be necessary.
More information: Backing Up and Restoring Data with Remote Computers
If you used a third-party backup tool to create your backups, use that tool for the restore process as well.
More information: Using Third-Party Backup Tools

Procedure

To restore a database, use Database Studio or Database Manager CLI.

Display the backup history and determine both the last complete and incremental data backup.
More information:
- Database Studio, Opening the Backup History
- Database Manager CLI Tutorial, Evaluating the Restart Information and Backup History for Importing Backups
Import the last complete data backup.

Note
If you have initialized the database before the restore process, then overwrite all original database user information (database system administrators and users, but not DBM operators) with the information in the data backup. This is done when the data backup is imported. If you have changed the database user information after creation of the data backup, then these changes are lost when the data backup is imported.

End of the note.

If necessary, import the last incremental data backups and log backups as well.

The backups to be imported must, in their entirety, contain all the contents of the database without any gaps. The database system can only automatically recover the last log entries still in the log area if the log volumes are still intact. If the log volumes still contain all the log entries since the last data backup import, it is enough to restart the database after importing the data backup. The system then imports the content of the log area. If you need to import more log backups after the data backup(s), the database system recognizes the page starting from which the missing content can be imported from the log area. The log backup import terminates at this point, the system recovers the remaining log pages from the log area and automatically transfers the database to the ONLINE operational state.

It is also possible to restore the database only as far as a certain consistent state before the error occurred.

More information:
- Database Studio, Restoring Databases
- Database Manager CLI Tutorial, Restoring the Database
If necessary, restore any damaged indexes.
More information:
- Database Studio, Restoring Damaged Indexes
- Database Manager CLI, sql_recreateindex
- Database Administration in CCMS, Index Analysis

Example

During normal operation, you back up your database using complete and incremental data backups and log backups.

Database Backup: Complete and Incremental Data Backups and Log Backups (Example)
After a system failure, you recover your database.

You can choose between different recovery paths.

Database Recovery: Different Recovery Paths (Example)

Note that after you have restored log backups, you can no longer restore incremental data backups.