Restoring an Automatic Backup Copy

If you have used the automatic backup feature described in Chapter 10, Configuring Automatic Backups (csstored),, you can use the hot backup copy when your live database is corrupted.

This sections covers how to restore the two different automatic backups:

• Before You Restore

• To Restore a Hot Backup

• To Restore an Archive Backup

Before You Restore

Before you restore a backup, be sure that you have:

• Tried to diagnose which transaction caused the corruption of the live database.

• Removed or corrected the corrupting transaction so the new archive will not be corrupted.

• Preserved the corrupted database by copying it to another directory or removable media. This is necessary should you need to contact technical support.

To Restore a Hot Backup

Hot backups should be your first choice of backup when your live database is corrupted. To restore a hot backup, follow these steps:

1. Identify any log files that were unapplied or open for writing in the corrupted live database directory.

2. Close the log that was open for writing. It contains the most recent transactions.

3. Create a new (recovery) directory.

4. Copy the current hot backup copy into the new recovery database directory.

5. Copy the log.* files from your corrupted live database directory into your new recovery database directory.

6. If you are keeping an archive copy of the database, copy the logs that had not been applied to the live database into the archive directory, so your archive backup copy will be complete.

7. Run db_recover with the -c -h options specified against the new recovery database.

   For example, if your new recovery directory is called recoverydb, then the command would be as follows:

   db_recover -c -h recoverydb

8. Leave the log.* files in the new recovery directory.

   The db_recover program applied the log files to the new recovery databases, but starting with version 42, the Berkeley DB expects them to remain.

9. Run db_verify against the database files in the new recovery directory.

   For instructions, see To Check for Calendar Database Corruption.

10. Run csdb -v list against the new recovery directory.

11. If the new recovery directory passed all three preceding recovery steps, replace the old corrupted live database with the new recovery database.

12. Copy the new live database into your hot backup directory to function as the new snapshot.

    All new logs will be applied to this copy until the next regular snapshot is taken.

13. Start Calendar Server.

14. If the new recovery directory failed any of the steps, identify an uncorrupted older hot backup as follows:

    1. Working backward through your hot backups, find the most recent copy that is not corrupted by running db_verify and csdb -v list on each in turn.

    2. The first hot backup copy that passes can be restored to your live database directory.

       Replace the corrupted live database with the clean hot backup, as described in To Restore a Hot Backup. (Be sure to read Before You Restore first.)

    3. If none of your hot backups work and you do not have archive backups to try, call technical support. If you do have archive backups, follow the procedure that followsTo Restore an Archive Backup. (See also, Before You Restore.)

To Restore an Archive Backup

If you do not have an uncorrupted hot backup, but have archive backups and their transaction logs, you can restore the most current uncorrupted version of the archived database by performing the following steps:

1. Identify any log files that were unapplied or open for writing in the corrupted live database directory.

2. Close the log that was open for writing. It contains the most recent transactions.

3. Create a new (recovery) directory.

4. Copy the most recent archive copy and its log files into the new recovery database directory.

5. Copy any unapplied log.* files from your corrupted live database directory into your new recovery database directory.

6. Run db_recover with the -c -h options specified against the new recovery database.

   For example, if your new recovery directory is called recoverydb, then the command would be as follows:

   db_recover -c -h recoverydb

7. Leave the log.* files in the new recovery directory.

   The db_recover program applied the log files to the new recovery databases, but starting with version 4.2, Berkeley DB expects the log files to still be there.

8. Run db_verify against the database files in the new recovery directory.

   For instructions, see To Check for Calendar Database Corruption.

9. Run csdb -v list against the new recovery directory.

10. If the new recovery directory passed all three preceding recovery steps, replace the old corrupted live database with the new recovery database.

11. Copy the new live database into your hot backup directory to function as the new snapshot.

12. Start Calendar Server.

13. If the new recovery directory failed any of the steps, identify an uncorrupted older archive backup as follows:

    1. Working backward through your archive backup copies, find the most recent copy that is not corrupted by running the three recovery programs against each of them in turn: db_recover -c-h, db_verify and csdb -v list.

    2. The first archive copy that passes can be restored to your live database directory.

       Replace the corrupted live database with the clean archive backup, as shown in To Restore an Archive Backup.

    3. If none of your archive backups work, call technical support.