Sauvegarde et Restauration OpenLDAP

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).

 

Catégorie: 

Tag: