Sur un serveur Linux, la configuration OpenLDAP se trouve dans /etc/openldap, et plus précisément dans /etc/openldap/slapd.d.
Les données, quant à elles, se trouvent... où on leur a dit de se mettre, puisque ceci est défini pour chaque rootSuffix.
Par exemple, si pour notre rootSuffix, nous définissons dans le fichier /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif les informations suivantes (extrait) :
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /data/openldap/data/example-com
olcSuffix: dc=example,dc=com
Nous pouvons en déduire que les données sont dans le répertoire correspondant à l'attribut olcDbDirectory : /data/openldap/data/example-com. Ainsi, il suffit de sauvegarder les répertoires suivants :
- /etc/openldap : configuration, schéma, etc
- /data/openldap : données de l'annuaire
Note : par défaut, les données sont dans /var/lib/openldap-data/
Il est également possible de faire des sauvegardes à chaud, sans arrêter l'annuaire, via la commande slapcat.
Sauvegarde et restauration à base de fichiers
Sauvegarde
La sauvegarde peut donc être faite simplement via un script shell :
#!/bin/bash # BACKUPDIR=/data/backup/openldap DATADIR=/data/openldap/data ROOTSUFFIX=example-com # echo "Sauvegarde du paramétrage" cd /etc tar cf $BACKUPDIR/etc-openldap.tar openldap echo "Sauvegarde des données" service slapd stop # On attend que le service soit arrêté sleep 5 cd $DATADIR tar cf $BACKUPDIR/data-openldap-$ROOTSUFFIX.tar $ROOTSUFFIX service slapd start echo "Sauvegarde terminée"
A ce stade, les 2 fichiers présents dans le répertoire $BACKUPDIR sont suffisants pour reconstruire une instance de l'annuaire.
Restauration
Pour la restauration des données, on repart d'une machine "vierge", sur laquelle les répertoires sont créés, et sur laquelle les binaires openldap ont été installés, via votre gestionnaire de paquets.
Il "suffit" alors d'écraser la configuration de base avec la sauvegarde, et de mettre en place les données. Ici encore un script shell peut être utilisé :
#!/bin/bash # BACKUPDIR=/data/backup/openldap DATADIR=/data/openldap/data ROOTSUFFIX=example-com # echo "Arrêt du service" service slapd stop sleep 5 echo "Restauration du paramétrage" cd /etc mv openldap openldap-Distrib tar xvf $BACKUPDIR/etc-openldap.tar echo "Restauration des données" cd $DATADIR tar xvf $BACKUPDIR/data-openldap-$ROOTSUFFIX.tar echo "Démarrage de slapd" # service slapd start echo "Restauration OpenLDAP terminée"
Vérifier ensuite que le répertoire de données appartient bien à l'utilisateur ldap
chown -R ldap:ldap /data/openldap/data
Dans le cas où les annuaires étaient répliqués, il vaut mieux dans un premier temps supprimer la partie réplication du fichier de configuration.
Sauvegarde et restauration des données à base de LDIF
Le principal intérêt de réaliser des sauvegardes à base de LDIF est de permettre une sauvegarde à chaud des données, qui n'impose pas d'arrêt du service. Dans ce cas la procédure de sauvegarde et de restauration est quelque peu différente. Il convient aussi de sauvegarder le répertoire contenant les certificats, si on les utilise (par défaut, les certificats sont stockés dans /etc/openldap/cacerts, ce qui permet de les sauvegarder en même temps que la configuration).
Notez que la sauvegarde par LDIF ne sauvegarde pas la configuration de l'annuaire, et qu'il faut de toute manière lancer une sauvegarde du répertoire /etc/openldap
Sauvegarde
La sauvegarde s'effectue simplement avec la commande slapcat.
/usr/sbin/slapcat -b$BASE -l $LDIFFILE
Les options utilisées sont :
- -b database-name : fournit le rootSuffix qui sera restauré
- -l fichier.ldif : précise le fichier LDIF utiliser pour la sauvegarde
Restauration
Si la sauvegarde a été effectuée par la commande slapcat, on peut restaurer avec la commande slapadd. Dans ce cas, il faut que le processus slapd soit arrêté.
La restauration s'effectue alors de la manière suivante :
# service slapd stop Arrêt de slapd : [ OK ] # slapadd -c -b dc=example,dc=com -l Export-Example-com.ldif
Les options utilisées sont :
- -c : continue en cas d'erreur
- -b database-name : fournit le rootSuffix qui sera restauré
- -l fichier.ldif : précise quel fichier LDIF utiliser
La commande slapadd donne une estimation du temps de restauration :
slapadd -c -b dc=example,dc=com -l Export-Example-com.ldif bdb_db_open: warning - no DB_CONFIG file found in directory /data/openldap/data/example-com: (2). Expect poor performance for suffix "dc=example,dc=com". => bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995) => bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995) slapadd: could not add entry dn="dc=example,dc=com" (line=1): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995) _# 5.61% eta 01h56m elapsed 06m55s spd 12.7 k/s
Note : la commande slapadd peut être lancée avec le compte ldap. Si on la lance via le compte root, il faut ensuite positionner correctement le propriétaire des fichiers de données, via la commande :
chown -R ldap:ldap /data/openldap/data/example-com
La durée estimée est donnée par le eta (Estimated Time of Arrival). Dans mon cas (VM avec 1Go de RAM, 1 CPU), il faudra compter près de 3 heures pour importer le contenu complet de l'annuaire comprenant plus de 165 000 entrées.
Le message d'erreur provient dans ce cas du fait que le rootSuffix avait été recréé manuellement.
Améliorer les performances lors de la restauration
Lorsqu'on utilise la commande slapadd, ceci génère des fichiers de transaction (log.xxxxx), qui ralentissent de manière très nette le processus de restauration.
On peut ajouter l'option -q , qui ne génère pas de ficiers de logs. On a un gain de temps assez phénoménal dans ce cas.
Il est également recommandé de créer un fichier DB_CONGIF dans le répertoire des données, et de positionner correctement les valeurs du cache.
Note : La restauration des données à partir d'un sauvegarde des fichiers est nettement plus rapide. L'utilisation de slapcat/slapadd permet cependant de réaliser des sauvegardes à chaud...
Dans le cas d'une architecture avec des annuaires répliqués, on peut imaginer avoir le mécanisme suivant :
- Arrêt d'un des annuaires esclaves
- Sauvegarde "à froid" des données de cet annuaires
- Redémarrage de l'annuaire, qui va se resynchroniser
On dispose ainsi d'une sauvegarde cohérente des fichiers (configuration + données).