Administrators should have a comprehensive backup strategy and schedule that comprise of daily, weekly, and monthly backups including incremental and full backups of the directory server data, configuration, and backends. Administrators should also have a backup plan for the underlying file system. This dual purpose approach provides excellent coverage in the event that a server database must be restored for any reason.

Note: Backups can be configured as recurring tasks with dsconfig create-recurring-task, and then scheduled to run when added to a recurring task chain.

The PingDirectory Server provides efficient backup and restore command-line tools that support full and incremental backups. The backups can also be scheduled using the UNIX-based cron scheduler or using the Directory Server’s Task-based scheduler. The Directory Server can run backups with the server online while processing other requests, so that there is no need to shut down the server or place it in read-only mode prior to starting a backup.

If you back up more than one backend, the backup tool creates a subdirectory below a specified backup directory for each backend. If you back up only a single backend, then the backup files will be placed in the specified directory. A single directory can only contain files from one backend, so that you cannot have backup files from multiple different backends in the same backup directory.

When performing a backup, the server records information about the current state of the server and backend, including the server product name, the server version, the backend ID, the set of base DNs for the backend, and the Java class used to implement the backend logic. For JE backends, the backup descriptor also includes information about the Berkeley DB JE version and information about the attribute and VLV indexes that have been defined.

When restoring a backup, the server compares the descriptor obtained from the backup with the current state of the server and backend. If any problems are identified, the server generates warnings or errors. The administrator can choose to ignore the warnings with the ignoreCompatibilityWarnings option to the restore tool, whereas errors will always cause the restore to fail. For example, when restoring a newer backup into an older version of the server, a warning will be generated. When restoring an older backup into a new version of the server, no warning will be generated, but because the config and schema backends require special handling, the server generates an error if the server versions do not match exactly (major, minor, point, and patch version numbers).

Both the backup and restore tools provide encryption options --promptForEncryptionPassphrase, --encryptionPassphraseFile, and --encryptionSettingsDefinitionID that can be used to specify which key to use for encrypting the backup. For backups encrypted with an encryption settings definition or an internal topology key, the server will automatically determine the correct key. Or, the --doNotEncrypt argument can be used to force a backup to be unencrypted even if automatic encryption is enabled.

If needed, the --maxMegabytesPerSecond argument can be used to impose a limit on the rate at which the backup may be written to disk.