CTS Backups and DS Replication Purge Delay

Replication is the process of copying updates between directory servers to help all servers converge to identical copies of directory, token, session, SAML v2.0, and OAuth 2.0 data. DS uses advanced data replication methods to ensure that directory services remain available in the event of a server crash or network interruption.

The historical information needed to resolve the latest changes is periodically purged to prevent it from becoming an unmanageable size. The age at which the information is purged is known as the replication-purge-delay.

With CTS, the default replication-purge-delay for DS is 3 days. Unless you have configured a separate DS server for CTS data, you may have to balance the needs for backups, the requirements for replication, disk space, and different useful lifetimes for CTS tokens and other DS data. Adjustments may be required. For example, to set the replication-purge-delay period to four hours, use the following command:

$ /path/to/opendj/bin/dsconfig set-synchronization-provider-prop \
--provider-name "Multimaster Synchronization" \
--set replication-purge-delay:4h \
--hostname 'cts.example.com' \
--port 4444 \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePasswordFile /path/to/opendj/config/keystore.pin \
--bindDN uid=admin \
--bindPassword str0ngAdm1nPa55word \
--no-prompt

At this point, you need to understand whether CTS data backups are important in your deployment. Session, SAML v2.0, and OAuth 2.0 token data is often short-lived. In some deployments, the worst-case scenario is that users have to log in again.

If CTS data backups are important in your deployment, note that DS backups that are older than the replication-purge-delay are useless and must be discarded. You can use the DS dsbackup command to schedule backups. For more information, see Backup and Restore in the ForgeRock Directory Services Maintenance Guide.

If you adjust the time periods associated with replication-purge-delay and backups, you need to backup more frequently so that the change log records required to restore date are not lost.