When you restore data, the procedure to follow depends on whether the OpenDJ directory server is replicated.
Procedure 10.3. To Restore a Stand-alone Server
To restore OpenDJ when the server is online, you start a restore task
by connecting to the administrative port and authenticating as a user with
the backend-restore privilege, and also setting a start
time for the task by using the --start option.
To restore data when OpenDJ is stopped, you run the restore command without connecting to the server, authenticating, or requesting a restore task.
-
Use one of the following alternatives.
-
Stop the server to restore data for Example.com.
The following example stops OpenDJ, restores data offline from one of the available backups, and then starts the server after the restore is complete.
$ stop-ds Stopping Server... [13/Jun/2011:15:44:06 +0200] category=BACKEND severity=NOTICE msgID=9896306 msg=The backend userRoot is now taken offline [13/Jun/2011:15:44:06 +0200] category=CORE severity=NOTICE msgID=458955 msg=The Directory Server is now stopped $ restore --backupDirectory /path/to/opendj/bak --listBackups Backup ID: 20110613080032 Backup Date: 13/Jun/2011:08:00:45 +0200 Is Incremental: false Is Compressed: false Is Encrypted: false Has Unsigned Hash: false Has Signed Hash: false Dependent Upon: none $ restore --backupDirectory /path/to/opendj/bak --backupID 20110613080032 [13/Jun/2011:15:47:41 +0200] category=JEB severity=NOTICE msgID=8847445 msg=Restored: 00000000.jdb (size 341835) $ start-ds ... The Directory Server has started successfully
-
Schedule the restore as a task to begin immediately.
The following example requests an online restore task, scheduled to start immediately.
$ restore --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --backupDirectory /path/to/opendj/bak --backupID 20110613080032 --start 0 Restore task 20110613155052932 scheduled to start Jun 13, 2011 3:50:52 PM CEST
-
Procedure 10.4. To Restore a Replica
After you restore a replica from backup, replication brings the replica up to date with changes that happened after you created the backup. In order to bring the replica up to date, replication must apply changes that happened after the backup was made. Replication uses internal change log records to determine what changes to apply.
Internal change log records are not kept forever, though. Replication is configured to purge the change log of old changes, preventing the log from growing indefinitely. Yet, for replication to determine what changes to apply to a restored replica, it must find change log records dating back at least to the last change in the backup. In other words, replication can bring the restored replica up to date as long as the change log records used to determine which changes to apply have not been purged.
Therefore, when you restore a replicated server from backup, make sure the backup you use is newer than the last purge of the replication change log (default: 3 days). If all your backups are older than the replication purge delay, do not restore from a backup, but instead initialize a new replica as described in Initializing Replicas.
-
Restore the server database from the backup archive that you are sure is newer than the last purge of the replication change log.
$ stop-ds Stopping Server... [13/Jun/2011:15:44:06 +0200] category=BACKEND severity=NOTICE msgID=9896306 msg=The backend userRoot is now taken offline [13/Jun/2011:15:44:06 +0200] category=CORE severity=NOTICE msgID=458955 msg=The Directory Server is now stopped $ restore --backupDirectory /path/to/opendj/bak --listBackups Backup ID: 20110613080032 Backup Date: 13/Jun/2011:08:00:45 +0200 Is Incremental: false Is Compressed: false Is Encrypted: false Has Unsigned Hash: false Has Signed Hash: false Dependent Upon: none $ restore --backupDirectory /path/to/opendj/bak --backupID 20110613080032 [13/Jun/2011:15:47:41 +0200] category=JEB severity=NOTICE msgID=8847445 msg=Restored: 00000000.jdb (size 341835) $ start-ds ... The Directory Server has started successfully
