upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-01-24 07:43:16 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Backup strategy discussions. db_recover example to do.

Browse source
This commit is contained in:
Gavin Henry 2007-10-18 23:50:08 +00:00
parent 10fcc30970
commit 33222eb428
1 changed files with 35 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
doc/guide/admin/maintenance.sdf
View file

@ -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