From 5ea77a75dd2d2158401331879f3c8f47940a732c Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 18:35:32 +0200 Subject: Adding upstream version 2.5.13+dfsg. Signed-off-by: Daniel Baumann --- doc/guide/admin/maintenance.sdf | 77 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 doc/guide/admin/maintenance.sdf (limited to 'doc/guide/admin/maintenance.sdf') diff --git a/doc/guide/admin/maintenance.sdf b/doc/guide/admin/maintenance.sdf new file mode 100644 index 0000000..62a5532 --- /dev/null +++ b/doc/guide/admin/maintenance.sdf @@ -0,0 +1,77 @@ +# $OpenLDAP$ +# Copyright 2007-2022 The OpenLDAP Foundation, All Rights Reserved. +# COPYING RESTRICTIONS APPLY, see COPYRIGHT. + +H1: Maintenance + +System Administration is all about maintenance, so it is only fair that we +discuss how to correctly maintain an OpenLDAP deployment. + + +H2: Directory Backups + +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 LMDB database itself + +The LMDB database can be copied live using the mdb_copy command. If the database +is a sparse file via the use of the "writemap" environment flag, the resulting +copy will be the actual size of the database rather than a sparse copy. + +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-mdb databases. + +> slapcat -f slapd.conf -b "dc=example,dc=com" + +For back-mdb this command may be ran while slapd(8) is running. + + +H2: Checkpointing + +Setting a checkpoint is only necessary when back-mdb has the dbnosync flag set. Otherwise +it has no effect. With back-mdb the kbyte option is not implemented, meaning it will only +run a checkpoint based on the elapsed amount of minutes flag. + +H2: Migration + +The simplest steps needed to migrate between versions or upgrade, depending on your deployment +type are: + +.{{S: }} +^{{B: Stop the current server when convenient}} + +.{{S: }} ++{{B: slapcat the current data out}} + +.{{S: }} ++{{B: Clear out the current data directory (/usr/local/var/openldap-data/)}} + +.{{S: }} ++{{B: Perform the software upgrades}} + +.{{S: }} ++{{B: slapadd the exported data back into the directory}} + +.{{S: }} ++{{B: Start the server}} + +Obviously this doesn't cater for any complicated deployments with {{SECT: N-Way Multi-Provider}}, +but following the above sections and using either commercial support or community support should help. Also check the +{{SECT: Troubleshooting}} section. -- cgit v1.2.3