H1: Maintenance
-http://www.openldap.org/faq/data/cache/286.html
+System Administration is all about maintenance, so it is only fair that we
+discuss how to correctly maintain an OpenLDAP deployment.
H2: Directory Backups
+MORE
+
+You can use {{slapcat}}(8) to generate an LDIF file for each of your {{slapd}}(8)
+back-bdb or back-hdbdatabases.
+
+> slapcat -f slapd.conf -b "dc=example,dc=com"
+
+For back-bdb and back-hdb, this command may be ran while slapd(8) is running.
+
+MORE
+
H2: Berkeley DB Logs
+Berkeley DB log files grow, and the administrator has to deal with it. The
+procedure is known as log file archival or log file rotation.
+
+Note: The actual log file rotation is handled by the Berkeley DB engine.
+
+Logs of current transactions need to be stored into files so that the database
+can be recovered in the event of an application crash. Administrators can change
+the size limit of a single log file (by default 10MB), and have old log files
+removed automatically, by setting up DB environment (see below). The reason
+Berkeley DB never deletes any log files by default is that the administrator
+may wish to backup the log files before removal to make database recovery
+possible even after a catastrophic failure, such as file system corruption.
+
+Log file names are {{F:log.XXXXXXXXXX}} (X is a digit). By default the log files
+are located in the BDB backend directory. The {{F:db_archive}} tool knows what
+log files are used in current transactions, and what are not. Administrators can
+move unused log files to a backup media, and delete them. To have them removed
+automatically, place set_flags {{DB_LOG_AUTOREMOVE}} directive in {{F:DB_CONFIG}}.
+
+Note: If the log files are removed automatically, recovery after a catastrophic
+failure is likely to be impossible.
+
+The files with names {{F:__db.001}}, {{F:__db.002}}, etc are just shared memory
+regions (or whatever). These ARE NOT 'logs', they must be left alone. Don't be
+afraid of them, they do not grow like logs do.
+
+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
+
+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
+the {{F:DB_CONFIG}} file. This magic file can be created in BDB backend directory
+set up by {{slapd.conf}}(5). More information on this file can be found in File
+naming chapter. Specific directives can be found in C Interface, look for
+{{DB_ENV->set_XXXX}} calls.
+
+Note: options set in {{F:DB_CONFIG}} file override options set by OpenLDAP.
+Use them with extreme caution. Do not use them unless You know what You are doing.
+
+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
+ 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 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.
+This chapter is a set of small pages with examples in C language. Non-prorgamming
+people can skip this examples without loss of knowledge.
+
H2: Checkpointing
+MORE/TIDY
+
+If you put "checkpoint 1024 5" in slapd.conf (to checkpoint after 1024kb or 5 minutes,
+for example), this does not checkpoint every 5 minutes as you may think.
+The explanation from Howard is:
+
+'In OpenLDAP 2.1 and 2.2 the checkpoint directive acts as follows - *when there
+is a write operation*, and more than <check> minutes have occurred since the
+last checkpoint, perform the checkpoint. If more than <check> minutes pass after
+a write without any other write operations occurring, no checkpoint is performed,
+so it's possible to lose the last write that occurred.''
+
+In other words, a write operation occurring less than "check" minutes after the
+last checkpoint will not be checkpointed until the next write occurs after "check"
+minutes have passed since the checkpoint.
+
+This has been modified in 2.3 to indeed checkpoint every so often; in the meantime
+a workaround is to invoke "db_checkpoint" from a cron script every so often, say 5 minutes.
+
projects / openldap / commitdiff