---
title: CTS backups and DS replication purge delay
description: 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.
component: pingam
version: 7.2
page_id: pingam:cts-guide:cts-backup-repl-purge-delay
canonical_url: https://docs.pingidentity.com/pingam/8.1/cts/cts-backup-repl-purge-delay.html
llms_txt: https://docs.pingidentity.com/pingam/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
superseded_by: https://docs.pingidentity.com/pingam/8.1/cts/cts-backup-repl-purge-delay.html
---

# 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:

```bash
$ /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](https://docs.pingidentity.com/pingds/7.2/maintenance-guide/backup-restore.html) in the ForgeRock Directory Services documentation.

If you adjust the time periods associated with `replication-purge-delay` and backups, you must back up more frequently, so that the change log records required to restore data are not lost.