]> git.sur5r.net Git - openldap/blobdiff - doc/guide/admin/maintenance.sdf
updated replicated directory diagram.
[openldap] / doc / guide / admin / maintenance.sdf
index 7ed638fb55fa3bdf521388cb2605a66a57a4b91b..5c97ac4077886cfe6e085e4fa27757439bbad408 100644 (file)
@@ -1,5 +1,5 @@
 # $OpenLDAP$
-# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved.
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 
 H1: Maintenance
@@ -10,7 +10,40 @@ discuss how to correctly maintain an OpenLDAP deployment.
 
 H2: Directory Backups
 
-MORE
+Backup strategies largely depend on the amount of change in the database
+and how much of that change an administrator might be willing to lose in a 
+catastrophic failure. There are two basic methods that can be used:
+
+1. Backup the Berkeley database itself and periodically back up the transaction 
+log files:
+
+Berkeley DB produces transaction logs that can be used to reconstruct
+changes from a given point in time. For example, if an administrator were willing to only
+lose one hour's worth of changes, they could take down the server in
+the middle of the night, copy the Berkeley database files offsite, and bring
+the server back online. Then, on an hourly basis, they could force a
+database checkpoint, capture the log files that have been generated in the
+past hour, and copy them offsite. The accumulated log files, in combination
+with the previous database backup, could be used with db_recover to
+reconstruct the database up to the time the last collection of log files was
+copied offsite. This method affords good protection, with minimal space
+overhead.
+
+
+2. Periodically run slapcat and back up the LDIF file:
+
+Slapcat can be run while slapd is active. However, one runs the risk of an
+inconsistent database- not from the point of slapd, but from the point of
+the applications using LDAP. For example, if a provisioning application
+performed tasks that consisted of several LDAP operations, and the slapcat
+took place concurrently with those operations, then there might be
+inconsistencies in the LDAP database from the point of view of that
+provisioning application and applications that depended on it. One must,
+therefore, be convinced something like that won't happen. One way to do that
+would be to put the database in read-only mode while performing the
+slapcat. The other disadvantage of this approach is that the generated LDIF
+files can be rather large and the accumulation of the day's backups could
+add up to a substantial amount of space.
 
 You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8) 
 back-bdb or back-hdb databases.
@@ -19,8 +52,7 @@ back-bdb or back-hdb databases.
 
 For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
 
-MORE
-
+MORE on actual Berkeley DB backups later covering db_recover etc.
 
 H2: Berkeley DB Logs
 
@@ -54,10 +86,10 @@ To understand the {{F:db_archive}} interface, the reader should refer to
 chapter 9 of the Berkeley DB guide. In particular, the following chapters are 
 recommended:
 
-- Database and log file archival
-- Log file removal
-- Recovery procedures
-- Hot failover
+* Database and log file archival - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/archival.html}}
+* Log file removal - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/logfile.html}}
+* Recovery procedures - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/recovery.html}}
+* Hot failover - {{URL:http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/hotfail.html}}
 
 Advanced installations can use special environment settings to fine-tune some 
 Berkeley DB options (change the log file limit, etc). This can be done by using 
@@ -71,10 +103,10 @@ Use them with extreme caution. Do not use them unless You know what You are doin
 
 The advantages of {{F:DB_CONFIG}} usage can be the following:
 
-- to keep data files and log files on different mediums (i.e. disks) to improve 
+* to keep data files and log files on different mediums (i.e. disks) to improve 
   performance and/or reliability;
-- to fine-tune some specific options (such as shared memory region sizes);
-- to set the log file limit (please read Log file limits before doing this).
+* to fine-tune some specific options (such as shared memory region sizes);
+* to set the log file limit (please read Log file limits before doing this).
 
 To figure out the best-practice BDB backup scenario, the reader is highly 
 recommended to read the whole Chapter 9: Berkeley DB Transactional Data Store Applications.