Restoring the Database from a Backup

You can change the contents of CentraSite's internal database back to a previous state by restoring a backup. When you restore a backup, you completely replace the current contents of the database by the contents that existed when the backup was made.

Repository changes that are made between one backup and the subsequent backup are stored in session logs. When you restore from a backup, you can optionally choose to include or omit the data from the session logs.

As soon as the restore step successfully finishes, the repository is automatically started in standby mode. Then the recover step is started, in which all changes that were made since the last backup are reapplied from the session logs. Finally, the repository is shut down again. The restore function can only be used when the repository is inactive (stopped).

Note:

During the installation of CentraSite, a backup of the initial repository state is automatically created, with a timestamp equal to the date and time when you install the product. If you for any reason wish to restore the repository to its initial state, i.e., the state immediately after product installation, you can use this backup.

3. Decide which backup file you wish to use for the restore operation. You can show a list of all available backups and their backup keys (the unique identifiers for the backups) by using the command:

Select the recover option that you want to use. If you do not specify a recover option, this has the same effect as using the option recover all. The following recover options are available:

Option	Action
recover all	The database will be restored to the state stored in the backup, and all session logs created since the backup are included. This is the default option.
recover no	The database will be restored to the state stored in the backup. No session log data will be processed.
recover <UntilDateTime>	All session logs created after the specified time and date are excluded from the recovery. The format of this field is: DD-MMM-YYYY:HH:MM:SS Note that the month is given as a 3-letter abbreviation, using the first 3 characters of the month's name. Example: 23-OCT-2012:16:52:30
recover	This has the same effect as recover all.

The following example restores the database from a backup whose backup key is 001334732430. All database changes that occurred after the backup was made, up to and including 11:30am on October 25, 2012, will also be retrieved from the session logs.

If you choose to restore a backup without full recovery by using the recovery option no, and there are one or more backups that are more recent than the backup being restored, these more recent backups will be set to disabled.

If you choose to restore a backup without full recovery by using the option recover <UntilDateTime> , and there are one or more backups that are more recent than the time specified by this option, these more recent backups will be set to disabled.

A disabled backup cannot be accessed any more from any of the CentraSite user interfaces, and in particular cannot be accessed for restore or recover operations. It is not displayed in the list of available backups.

Disabled backups remain on the backup location on your disk as long as there are older, non-disabled backups. If you delete all non-disabled backups that are older than a given disabled backup, CentraSite automatically deletes the disabled backup.

If you should wish to reactivate a disabled backup, please archive it using standard operating system functionality and contact your software supplier.

Under normal circumstances, a database backup that is created on one machine can only be restored to the same machine. However, a database backup that originated on one machine can be configured, so that it can be restored onto another machine. For more information, see Moving a Database to Another Location.