LDAP: backup with slapcat vs ldapsearch
Good summary, some additional points:
slapcatdumps from whatever the (local) direct storage backend is, it need not be Berkeley (hdb or bdb), it also works with OLC (
cn=config). It dumps to LDIF format. (By direct I mean directly managed by OpenLDAP, not for example an SQL backend, even if its stored locally.)
ldapaddrequires that slapd is running,
slapaddrequires that it is not running
slapcatdoesn't care if it's running with a BDB backend, as you noted
slapcatis the way to get a good backup that you can restore quickly, albeit with downtime on the master (you can work around this with various types of replication set up). This is what you should use for a general backup, and pre-upgrade backups.
+) will get you a portable backup you can probably load with little difficulty into any other directory server, but it will only be a viable restore in a simple OpenLDAP set up (no replication, no special overlays, no rewriting), and if you don't care about preserving UUID/create/modify meta-data. You'll need any extra schema files that go along with your data too.
ldapadd(using its other identity
ldapmodify) can be used to easily apply LDAP modifications (object modify, delete and rename) which are not feasible or possible with
For most admins the main considerations arise from the slightly different contents of the LDIF in each case, and the requirement for
slapd to be running (or not). The more important differences are:
slapcatis faster because it simply dumps the database, skipping the LDAP protocol overheads, authentication, access control, object and time limits, overlays; and it does not search according to the LDAP hierarchy.
slapaddis faster (again, no LDAP protocol overheads), and in the case that you are restoring a known-good backup you can run in quick mode (
-q) to speed up large imports. You can also disable schema checking (
-s), though note than small changes in schema or data validation between OpenLDAP versions are not unheard of.
slapcatis limited to local databases, it will not cross over to other directories (e.g. with
back-meta) the way
ldapsearchwill. The same applies to
ldapsearchwill return dynamic attributes which are not stored in a backend, e.g.
hasSubordinatesor those maintained by overlays (e.g.
slapo-memberof). You will have problems loading these with
ldapadd(e.g. operational attributes with no-user-modification). Rewriting (slapo-rwm) may also distort
ldapsearch's view of the directory contents.
slapcatincludes internal (operational) attributes, if you are using replication these attributes are critical. With replication then you are somewhat less dependent on backups, but if you use
ldapaddto reload your master, every object will be recreated by replication (changed
entryCSN) Although you can include operational attributes by using the special "+" attribute with
allopoverlay), this is not the same thing as
slapcat, see the previous point for why this is so. These attributes also include create/modify DN and timestamps, which may be important to some applications.
slapcatdoes not observe the LDAP hierarchy (implied ordering), there's no guarantee that its data ordering is going to be viable with
ldapadd- i.e. even if you strip out the operational attributes,
ldapaddcan complain because sub-ordinates may appear before their superiors (parents). The LDAP specs require a parent to exist, but also leave the search result ordering undefined in this respect. See Howard's comment below, OpenLDAP's
slapaddsilently supports unordered data for some backends. In a pinch you may be able to repeatedly use
slapaddwith the continue on error option (
-c) until all the "out of order" parents are created, stopping when you no longer receive any error code 32 (no such object, meaning missing parent) and receive only code 68 (already exists) for every object.
ldapaddis subject to the LDAP rules and overlays, e.g. referential integrity, ppolicy (password policy)
slapcatprefers to use base-64 encoded attribute values for at least userPassword (indicated with
::after the attribute name)
ldapsearchhas more options for LDIF formatting, and writing large attributes to separate files. It may also handle referrals and aliases.