Transaction logging with backup and restore

Domino transaction logging is required on a Domino server that performs backup and restore.

Transaction logging provides the following benefits:
  • Database consistency, improved performance, and fast recovery from server crashes With transaction logging, database changes are written to the transaction log first and then the transaction log process writes the changes asynchronously into the database. Transaction logging improves database consistency and access/lock functionality. In addition, if a server crashes, transaction log changes are applied to a database which makes its recovery dramatically faster.
  • Incremental backup and point-in-time recovery Transaction log files are used in conjunction with full database backups to provide point-in-time restore of databases. When you restore a database, the user interface leverages transaction logs behind the scene to allow you to select a precise point in time for recovery since the last full database backup. Circular, linear, and archived styles of transaction logging are all supported.

With circular or linear style logging, transaction log files are stored on the Domino server. The primary benefit of this style of logging is server crash recovery and server performance. After the disk space is filled, Domino starts overwriting old transactions, starting with the oldest. Circular logging allocates a maximum of 4GB for transaction logging.

With archived-style transaction logging, transaction log files are not overwritten and the Domino Backup task or a third-party solution takes care of backing them up to ensure they can be restored for point-in-time recovery. This style of transaction logging is more difficult to configure and administer and therefore we recommend that you start with circular or linear style logging and only move to archive style logging if necessary.

Note: Transaction logging identifies each database by a unique database instance ID (DBIID). When a database DBIID changes, it's important to make a new, full backup of the database. The following actions cause a database DBIID to change and require a full backup of the database:
  • Disabling and re-enabling transaction logging on the server.
  • Disabling and re-enabling transaction logging for a specific database.
  • Compacting a database using an option other than -b.
  • Running Fixup on a database.
  • Restoring a database. Restoring a databases changes the DBIID of the restored copy.
  • Moving a database and then returning it to its original location.