22.5.7 Using the Dump and Load Procedure to Recover a Calendar Database

This sections contains the following topics:

• 22.5.7.1 Dump and Load Overview

• To Perform the Dump and Load Procedure

22.5.7.1 Dump and Load Overview

Use the dump and load procedure to try to recover a corrupted database. The dump and load procedure uses the Berkeley database db_dump and db_load utilities, which Calendar Server includes in the following directory:

cal-svr-base/SUNWics5/cal/tools/unsupported/bin

The db_dump utility reads a database file and writes the database entries to an output file, using a format that is compatible with the db_load utility.

For documentation about the db_dump and db_load utilities, refer to the Sleepycat Software Web site:

http://www.sleepycat.com/docs/utility/index.html

Your success in recovering a database using the db_dump and db_load utilities depends on the degree of corruption of your database. You might need to try several db_dump options before you successfully recover your database. If your database is severely corrupted, however, recovery might not be possible, and you might need to revert to the last good hot backup or archive backup of your database.

Before you perform the dump and load procedure, your calendar database must be Berkeley DB version 3.2.9, or later. If you have an earlier version, first run the cs5migrate utility to upgrade your calendar database.

For the most up to date version of cs5migrate, call Sun technical support.

To Perform the Dump and Load Procedure

1. Log in as the user and group under which Calendar Server is running, such as icsuser and icsgroup, or as superuser (root).

2. Stop Calendar Server, if necessary.

3. Backup your corrupted database using a utility such as csbackup, the Sun StorEdge Enterprise Backup^TM software, or Legato Networker®.

   For more information refer to Chapter 17, Backing Up and Restoring Calendar Server Data.

4. Dump each corrupted database file using the db_dump utility.

   The database files are ics50calprops.db, ics50journals.db, ics50alarms.db, ics50events.db, ics50todos.db, and ics50gse.db.

   Run db_dump using the following options, in order, until your database is recovered (or until you determine that the database can’t be recovered):

   • No options for minor database corruption.

   • -R option for moderate database corruption.

   • -R option for severe database corruption. The -R option dumps more data than the -r option, including partial and deleted records, from the corrupted database.

     For example, to run db_dump with the -r option:

     db_dump -r ics50events.db \> ics50events.db.txt

5. Load the output file into a new database file using the db_load utility.

   For example:

   db_load new.ics50events.db < ics50events.db.txt

   If db_load reports an odd number of keys or data entries, edit the db_dump output file, and remove the odd key or data entries. Then run db_load again.

6. Repeat the previous two steps for the other corrupted database files.

   That is, run db_dump for the other corrupted database files.

7. Rebuild the recovered database files using the csdb rebuild command, as described in 22.5.6 Rebuilding a Corrupted Calendar Database.

   When rebuild has finished, review the output in the output file. If the rebuild was successful, the last line in the rebuild.out file should be:

   Calendar database has been rebuilt

   If the csdb rebuild command was not successful, dump your database using the next db_dump option (-r or -R).

   If the db_dump -R option does not recover your corrupted database, contact your Sun Microsystems technical support or sales account representative for assistance. In the meantime, you might need to revert to the last good backup of your database.