Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Administration Guide 11g Release 1 (11.1.1.5.0) |
Part I Directory Server Administration
2. Directory Server Instances and Suffixes
3. Directory Server Configuration
6. Directory Server Access Control
7. Directory Server Password Policy
8. Directory Server Backup and Restore
Restoring the Supplier in a Single-Master Scenario
Restoring a Supplier in a Multi-Master Scenario
Restoring a Dedicated Consumer
Restoring a Master in a Multi-Master Scenario
To Begin Accepting Updates Through the Command Line
To Make a Backup for Disaster Recovery
To Restore for Disaster Recovery
9. Directory Server Groups, Roles, and CoS
10. Directory Server Replication
13. Directory Server Attribute Value Uniqueness
15. Directory Server Monitoring
Part II Directory Proxy Server Administration
16. Directory Proxy Server Tools
17. Directory Proxy Server Instances
19. Directory Proxy Server Certificates
20. Directory Proxy Server Load Balancing and Client Affinity
21. Directory Proxy Server Distribution
22. Directory Proxy Server Virtualization
23. Virtual Data Transformations
24. Connections Between Directory Proxy Server and Back-End LDAP Servers
25. Connections Between Clients and Directory Proxy Server
26. Directory Proxy Server Client Authentication
27. Directory Proxy Server Logging
28. Directory Proxy Server Monitoring and Alerts
Part III Directory Service Control Center Administration
This section explains how to perform a binary backup of directory data. In addition to the binary backup procedures in this section, you can make a binary copy to use for initializing a suffix in a replication topology. See Initializing a Replicated Suffix by Using Binary Copy.
A binary data backup saves a copy of your directory data that you can use if the database files later become corrupted or deleted. This operation takes the back up of the database only and does not back up any other data such as configuration data and certificates. If you want to back up the whole Directory Server for disaster recovery, see Disaster Recovery.
Caution - The maximum period between two backups should not exceed the smaller of repl-purge-delay and repl-cl-max-age. The repl-cl-max-age property specifies the period of time, after which internal purge operations are performed on the change log. The change log maintains a record of updates, which might or might not have been replicated. Get the purge delay information using the following command: dsconf get-suffix-prop -h host -p port suffix-DN repl-purge-delay repl-cl-max-age If your backup is performed less frequently than the purge delay, the change log might be cleared before it has been backed up. Changes will therefore be lost if you use the backup to restore data. The consumer server stores internal information about updates to the replicated suffix contents, and the purge delay parameter, repl-purge-delay, specifies how long it must keep this information. The purge delay determines in part how long replication between the consumer and its master can be interrupted and still recover normally. It is related to the repl-cl-max-age parameter of the change log on its supplier server. The shorter of these two parameters determines the longest time that replication between the two servers can be disabled or down and still recover normally. The default value of 7 days is sufficient in most cases. |
All backup procedures described in this section store a copy of the server files on the same host by default. You should then copy and store your backups on a different machine or file system for greater security.
Your Directory Server must be stopped to run the dsadm backup command.
You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.
$ dsadm backup [ -f FLAG ] ... INSTANCE_PATH ARCHIVE_DIR
For example:
$ dsadm backup /local/dsInst /local/tmp/20091005
Note - By default, binary backup commands will run a database recovery on the backup databases. See dsadm(1M) for disabling this behavior.
You can back up directory data while the server is running by using the command dsconf backup command. However, if changes are made to the directory data while the backup is running, proper recovery will take longer.
Never stop the server during a backup operation.
For more information about the dsadm backup, dsconf backup commands and backup flags, see the dsadm(1M) and dsconf(1M) man pages.
When restoring a server, all the configuration data such as certificates, schema, and plugins must contain the same configuration information as when the server was backed up. The following task shows how to back up the dse.ldif file and the rest of the configuration information can be backed up in the same manner.
$ cp instance-path/config/dse.ldif archive-dir
When you perform the following actions, Directory Server automatically backs up the dse.ldif configuration file in the directory instance-path/config.
When you start Directory Server, a backup of the dse.ldif file is created in a file named dse.ldif.startOK.
When you make modifications to the cn=config branch, the file is first backed up to a file named dse.ldif.bak in the config directory before the server writes the modifications to the dse.ldif file.
This procedure optionally uses the frozen mode feature. Frozen mode enables you to stop database updates on disk so that a file system snapshot can be taken safely. You can use frozen mode as an additional measure for ensuring a robust backup.
If the server instance is stopped, frozen mode does not apply.
Your server must not write user data on the disk while the file system backup is in progress. If you are sure that no updates will occur during a certain time frame, make your backup during this time. If you cannot guarantee that there will be no updates, put your server into frozen mode before making a backup.
A server in frozen mode continues to write to the access and errors logs. In a single-server topology, operations received when frozen mode is on result in an LDAP error being returned. The error message logged is the standard error for the database being offline. In a replicated topology, a referral is returned. For frozen mode to work correctly, no other tasks should be running on the databases.
Note that the databases of a server in frozen mode are more stable than those in read-only mode. Unlike frozen mode, read-only mode permits tasks to be created and configuration entries to be modified. When frozen mode is on, all configured databases are taken offline. Any internal operations in progress are notified of the database going offline. LDAP operations in progress are completed, and the database environment is flushed. Subsequent incoming operations, including searches to user data, are refused until frozen mode is set to off. You can, however, search configuration parameters while frozen mode is on.
Frozen mode can be active only when the server is running. Restarting the server instance will also reset frozen mode to off.
For parts of this procedure, you can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help. Other parts of the procedure can only be done using the command line.
$ dsconf set-server-prop -h host -p port read-write-mode:frozen
$ dsconf set-server-prop -h host -p port read-write-mode:read-write
If your server receives replication updates from another server, replication updates will start as soon as frozen mode is turned off.
For parts of this procedure, you can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help. Other parts of the procedure can only be done using the command line.
$ dsadm stop instance-path
$ dsadm start instance-path