Backup and restore
Plan DS backup and restore procedures for your deployment.
Description
Estimated time to complete: 20 minutes
Safely and regularly back up your directory data to recover quickly when accidents happen.
In this use case, you:
-
Back up directory data using DS tools.
-
Cause an incident requiring recovery.
-
Restore directory data after an incident.
-
Validate the data restore procedure.
Goals
In completing this use case, you learn to:
-
Use DS backup and restore tools.
-
Schedule a recurring backup task.
-
Restore directory data from backup files.
-
Purge outdated backup files.
Example scenario
As a directory service administrator, Pat plans to deploy directory services for critical identity data such as login credentials.
Pat knows good backup and restore plans are a must for identity and access services. If the data is lost, end users cannot authenticate, and account profiles are lost.
Pat plans to show other identity administrators how the backup and restore procedures work and get them to review the process before deployment.
Prerequisites
Knowledge
Before you start, bring yourself up to speed with Pat:
-
Pat is familiar with the command line on the target operating system, a Linux distribution in this example.
-
Pat knows how to use basic LDAP commands, having worked examples to learn LDAP.
-
Pat has already successfully completed directory service installation and setup procedures.
Actions
Before you try this example, set up two replicated DS directory servers on your computer as described in Install DS and Learn replication.
Tasks
Pat demonstrates how to back up and restore DS directory data from the evaluation profile. The order of the tasks is the same in deployment, but the directory data is different.
Task 1: Schedule a recurring backup operation
When you use the DS tools, backup operations are incremental. You can take regular backups with a reasonable amount of disk space relative to your data.
Configure backup tasks
-
Schedule a regular backup task.
The following example schedules an hourly backup task:
$ /path/to/opendj/bin/dsbackup \ create \ --backupLocation bak \ --recurringTask "00 * * * *" \ --description "Back up every hour" \ --taskId HourlyBackup \ --completionNotify diradmin@example.com \ --errorNotify diradmin@example.com \ --hostname localhost \ --port 4444 \ --bindDN uid=admin \ --bindPassword password \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin -
Schedule a task to remove backup data older than the replication purge delay.
When you restore data from backup, the backup you restore must be more recent than the replication purge delay. If you restore from older data, the replica you restore can’t replicate with other servers. The default replication purge delay is three days.
The following example schedules an hourly task to remove outdated backup data:
$ /path/to/opendj/bin/dsbackup \ purge \ --backupLocation bak \ --recurringTask "00 * * * *" \ --description "Purge old backups every hour" \ --olderThan "3 days" \ --taskId HourlyPurge \ --completionNotify diradmin@example.com \ --errorNotify diradmin@example.com \ --hostname localhost \ --port 4444 \ --bindDN uid=admin \ --bindPassword password \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pinThis task ensures you won’t fill up the disk with old backup data.
(Optional) Back up data now
At this point, the recurring backup task is scheduled; however, the next backup operation won’t start until the top of the hour. If you want to continue this example without waiting for the task to run, you can back up the data now.
These steps demonstrate offline backup:
-
Stop the server:
$ /path/to/opendj/bin/stop-ds -
Back up the data with the server offline:
$ /path/to/opendj/bin/dsbackup \ create \ --backupLocation bak \ --offlineThe command writes the backup data to the
bak/directory under the server installation directory. -
Start the server:
$ /path/to/opendj/bin/start-ds
Task 2: Simulate the loss of a server
-
Make sure you have at least one set of backup files:
$ /path/to/opendj/bin/dsbackup \ list \ --backupLocation bak \ --offlineThis command runs on the files and can run in offline mode even if the server is up.
If you are waiting for the hourly backup task to run, there may not be any backup files yet.
-
Simulate the loss of a server by stopping it abruptly and deleting the files.
This example removes the
second-dsserver:$ kill -9 <second-ds-pid> $ rm -rf /path/to/replica -
Change an entry.
You use this change later to validate the restore procedure and show replication replays changes occurring after the last backup operation:
$ /path/to/opendj/bin/ldapmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDn uid=bjensen,ou=People,dc=example,dc=com \ --bindPassword hifalutin << EOF dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify replace: description description: Updated after the replica crashed EOF
Task 3: Recover and restore the lost server
-
Replace the lost server with the same configuration but don’t start it.
This example uses the evaluation profile:
$ cd ~/Downloads && unzip ~/Downloads/DS-7.5.0.zip && mv opendj /path/to/replica $ export DEPLOYMENT_ID=<deployment-id> $ /path/to/replica/setup \ --serverId second-ds \ --deploymentId $DEPLOYMENT_ID \ --deploymentIdPassword password \ --rootUserDn uid=admin \ --rootUserPassword password \ --hostname localhost \ --ldapPort 11389 \ --ldapsPort 11636 \ --adminConnectorPort 14444 \ --replicationPort 18989 \ --bootstrapReplicationServer localhost:8989 \ --profile ds-evaluation \ --set ds-evaluation/generatedUsers:0 \ --acceptLicenseRebuilding the basic server configuration depends on your deployment. For testing and deployment, adapt the commands to fit your process.
-
Restore the server data from backup:
$ /path/to/replica/bin/dsbackup \ restore \ --offline \ --backendName dsEvaluation \ --backupLocation /path/to/opendj/bak -
Start the server:
$ /path/to/replica/bin/start-dsAfter the server starts and connects to other servers, replication replays changes from after the backup operation.
Validation
Demonstrate the server you restored has the same data as the other replica.
-
Read the description you changed after the backup operation and server crash on
first-ds:$ /path/to/opendj/bin/ldapsearch \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDn uid=bjensen,ou=People,dc=example,dc=com \ --bindPassword hifalutin \ --baseDn dc=example,dc=com \ "(cn=Babs Jensen)" \ description dn: uid=bjensen,ou=People,dc=example,dc=com description: Updated after the replica crashed -
Read the same data on the
second-dsserver you restored from backup:/path/to/replica/bin/ldapsearch \ --hostname localhost \ --port 11636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDn uid=bjensen,ou=People,dc=example,dc=com \ --bindPassword hifalutin \ --baseDn dc=example,dc=com \ "(cn=Babs Jensen)" \ description dn: uid=bjensen,ou=People,dc=example,dc=com description: Updated after the replica crashedThe data is the same on both servers. You have shown your backup and restore procedure is sound.
What’s next
After demonstrating the process, Pat implements backup and restore procedures for testing and deployment. These procedures become part of the organization’s runbook, so operators can implement them quickly and easily.
Pat realizes disaster recovery is more than restoring backup files. Pat also implements disaster recovery procedures for testing and deployment as part of the organization’s runbook.
Explore further
This use case can serve as a template for DS test and production deployments. Adapt this example for deployment:
-
Make sure the backup tasks run on more than one DS replica to avoid a single point of backup failure.
-
To keep things simple, this example shows a backup on the local filesystem.
In testing and deployment, make sure you store backup files remotely. For example, consider backing up to cloud storage.
-
If the filesystem on your servers supports atomic snapshots, consider backing up DS with filesystem snapshots.