1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
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.
|
