Backup and Restore
The backup topology of DS in the CDM:
Some important DS backup and restore considerations in the CDM:
Six DS instances are deployed using Kubernetes stateful sets (three each for
DS data backups are stored in Google Cloud Service, Amazon S3, or Azure Blob Storage. Before deploying the CDM set up a cloud storage container and the necessary credentials to access the container.
Backups must be scheduled using the
schedule-backups.shscript in the
/path/to/forgeops/binpath on your local computer.
By default, an incremental backup of the CTS and identity repository directory instances is performed every hour. The first incremental backup created is a full backup.
The backup schedule can be customized separately for CTS and identity repository DS instances based on your recovery objectives.
By default, the backups are scheduled from the last (or
-2) pod of each DS instance. You can customize and schedule backups from any pod of a DS instance. You can also schedule backups from multiple pods.
DS server instances use cryptographic keys to sign and verify the integrity of backup files, and to encrypt data. Server instances protect these keys in a deployment by encrypting them with the shared master key. For portability, servers store the encrypted keys in the backup files.
idrepoinstance can be restored using the backup of any other
idrepoinstance, as long as it holds a copy of the shared master key used to encrypt the keys.
ctsinstance can also be restored using the backup of another
ctsinstance, as long as the shared master key is available to the
You can set up new DS instances with data from a previous backup when you deploy CDM.
After you deploy the CDM, schedule backups of the directory data.
The default backup schedule creates incremental backups of the
instance at the beginning of every hour, and the
cts instance at 10 minutes
past every hour.
schedule-backups.sh script to start backing up
idrepo instances using the default schedule:
In the CDM deployment, DS is deployed to the
namespace. So you would specify
prod as the namespace in the above
command. If you have deployed DS in another namespace, you must specify
the corresponding namespace.
You can customize the backup schedule for
separately. You can also schedule backups from any DS pod.
To customize the schedule for the
idrepo instance, and to schedule backups
ds-idrepo-1 pod in addition to the
schedule-backups.shfile in the
/path/to/forgeops/binfolder and change the line
BACKUP_SCHEDULE_IDREPO="0 * * * *"to suit your backup schedule for
For example, the following line schedules an incremental backup for the
idrepoinstance every 30 minutes:
BACKUP_SCHEDULE_IDREPO="*/30 * * * *"
kustomization.yamlfile in the
/path/to/forgeops/kustomize/base/kustomizeConfigfolder on your local computer and change the line that begins with
$ /path/to/forgeops/bin/schedule-backups.sh prod
Similarly, edit the
schedule-backups.sh script and change the line
BACKUP_SCHEDULE_CTS="10 * * * *" to suit your backup schedule for the
cts instance. If you want to add or change the
cts pod that performs
backup, edit the
kustomization.yaml file in the
/path/to/forgeops/kustomize/base/kustomizeConfig folder. Then run
schedule-backups.sh script stops any previously scheduled
backup jobs before initiating the new schedule.
When the CDM is deployed, new, empty DS instances are created. You can enable the automatic restore capability in CDM to:
Deploy new DS instances using the data from a previous backup.
Set up the
idrepoDS pods to recover from operational failures.
The automatic restore capability to deploy new instances with backup data is useful when a system disaster occurs, or when directory services are lost. It is also useful when you want to port test environment data to a production deployment. Note that when you restore a DS instance, all its replicas are restored.
You can enable automatic restore before you deploy CDM. To enable automatic restore, you must set up the DS data backup to cloud storage, copy the backup data to the cloud storage location, and then follow these steps:
Change to the
kustomization.yamlfile and set the
AUTORESTORE_FROM_DSBACKUPparameter to "true".
Deploy platform as described in CDM Deployment.
In a CDM deployment that has automatic restore enabled, you can recover a failed pod:
Delete the PVC attached to the failed DS pod using the
kubectl delete pvccommand. The PVC might not get deleted immediately if the attached pod is running.
In another terminal window, stop the failed DS pod using the
kubectl delete podcommand. This will delete the PVC.
The automatic restore feature of CDM recreates the PVC, copies data from the backup, restores the DS pod with the latest backup, and replicates the current data from other DS pods.
You can also perform manual restore of DS. For more information about how to manually restore DS, see the Restore section in the ForgeRock Directory Services Maintenance Guide.
Consider following these best practices:
Use a backup that is newer than the last replication purge.
When you restore a DS replica using backups that are older than the purge delay, that replica will no longer be able to participate in replication. Reinitialize the replica to restore the replication topology.
If the available backups are older than the purge delay, then initialize the DS replica from an up-to-date master instance. For more information on how to initialize a replica, see Manual Initialization in the ForgeRock Directory Services Configuration Guide.