CTS backups and DS replication purge delay

Replication replays each update on all directory servers, so they eventually converge on the same directory, token, session, SAML v2.0, and OAuth 2.0 data. DS data replication ensures directory services remain available for reads and writes when a server crashes or network connection goes down.

The directory servers store historical information to replay updates in the right order. DS servers periodically purge this historical information to prevent it from growing indefinitely. The setting that governs how long to retain historical information is the DS replication-purge-delay.

The default DS replication-purge-delay is 3 days. Although this setting is generally appropriate for most data, it may be too long for volatile CTS data in high-volume deployments.

If you have separated your DS servers for CTS from DS servers for other data, you can lower the replication purge delay on all DS replicas. For example, the following command sets it to 12 hours for a single DS replica on cts.example.com:

You must decide whether CTS data backups are important in your deployment. It may not be worth backing up the CTS data. Losing CTS tokens may be acceptable if the worst-case scenario means users have to log in again.

For deployments with critical long-lived sessions or long-lived refresh tokens, losing tokens may not be acceptable. If losing CTS tokens is not acceptable, back up CTS data.

When backing up CTS data, be aware that DS backups older than the replication purge delay are useless. DS replication can only bring a replica up to date when it has the historical information to replay changes in the right order. If you restore a DS server from data older than the replication purge delay, the other DS servers will have already purged the historical information needed to replay the pending changes. For details, refer to Backup and restore in the PingDS documentation.