test

Sun Java System Calendar Server 6.3 Administration Guide

22.5.8 Restoring an Automatic Backup Copy

If you have used the automatic backup feature described in Chapter 9, 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:

22.5.8.1 Before You Restore

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

ProcedureTo 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. To run db_verify:

    1. Stop the Calendar Server using these commands.

      cd /opt/SUNWics5/cal/sbin

      ./stop-cal

    2. Create another copy of the Calendar Server database (csdb) using this command.

      cp -Rp /var/opt/SUNWics5/csdb /var/opt/SUNWics5/csdb.db_verify

    3. Run db_verify on the copy of csdb.

      Note –

      Do not run db_verify on the original csdb.

      LD_LIBRARY_PATH=/opt/SUNWics5/cal/lib
export LD_LIBRARY_PATH
cd /opt/SUNWics5/cal/tools/unsupported/bin
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50alarms.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50calprops.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50events.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50gse.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50journals.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50recurring.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
./db_verify -o -h /var/opt/SUNWics5/csdb.db_verify ics50deletelog.db
      Note –

      Run db_verify with -o option for ics50deletelog.db.

      If db_verify completes running successfully, you will not get any error messages. If the database file gets corrupted, it throws error messages. For example:


      ./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
db_verify:Page 612: last item on page sorted greater than parent entry
db_verify: Page 612: incorrect next_pgno 885 found in leaf chain (should be 501)
db_verify: Page 0: page 501 encountered a second time on free list
db_verify: DB->verify: ics50todos.db: DB_VERIFY_BAD: Database verification failed

  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 22.5.8.1 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, 22.5.8.1 Before You Restore.)

ProcedureTo 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.

    Steps in the To Restore a Hot Backup procedure, explains how to run db_verify.

  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.