Checkpoint and Recovery Help

The Backup Server function of the admin tool sends a request to a server to checkpoint its internal handle database. In order to be able to checkpoint a server, the administrator must be identified as an administrator for that server (in the backup_admins section of the config.dct file on the server).

The checkpoint operation consists of several steps. Upon receiving an authenticated request to backup the database, the server will

1. Copy the main database files (handles.jdb and nas.jdb) to backup files (handles.bak and nas.bak)
2. Reset the transaction log (dbtxns.log)

After these steps the handles.bak and nas.bak files can be safely copied to another location for a backup. The dbtxns.log file will contain all of the changes made to the database since the handles.bak and nas.bak files were made. The dbtxns.log file will allow you to restore the backup up to the last transaction that was successfully performed if something were to go wrong with the main database.

To perform the checkpointing, enter the IP address and port number of the server that you want to perform the checkpoint operation. Note: During the checkpoint process, the server will reject all requests to create, modify, or delete handles. For this reason, it is usually preferable to perform the checkpoint operation when there is little administrative activity on the server. Checkpoint operations should only be performed on primary servers since secondary servers do not keep transaction logs for their databases.

To recover the database using the backup files and transaction log you can perform the following steps:

1. Make sure that the server is NOT running.
2. Make extra copies of all files (doesn't hurt to be safe!)
3. Run the command:

   java -cp handle.jar net.handle.apps.tools.RecoverJDB  <server_dir>

4. Restart the server. The server should now have its database restored to it's pre-disaster state.