Bundesamt für Sicherheit in der Informationstechnik

M 6.150 Datensicherung beim Einsatz von OpenLDAP

Verantwortlich für Initiierung: Fachverantwortliche, Leiter IT

Verantwortlich für Umsetzung: Administrator

Datensicherungen des Open LDAP -Servers sind regelmäßig durchzuführen. Sie sind eine wichtige Voraussetzung, um aufgetretene Fehler zu korrigieren und gelöschte Daten wieder einspielen zu können.

Umfassende Datensicherung

Bei einer Datensicherung wird oftmals nur daran gedacht, die Nutzdaten zu sichern. Bei OpenLDAP sind das die Objekte im Verzeichnis. Um den tatsächlichen Weiter- bzw. Wiederbetrieb zu gewährleisten, müssen darüber hinaus auch die Konfigurationsdateien gesichert werden. Je nachdem, wie die Konfiguration durchgeführt wird (siehe M 4.384 Sichere Konfiguration von OpenLDAP ), heißt das entweder, dass die Konfigurationsdatei "slapd.conf" zu sichern ist, oder aber, im Fall der Online-Konfiguration, das Suffix "CN=config". Darüber hinaus darf die erzeugte Sicherung physikalisch nicht auf dem gleichen IT-System verbleiben, da sie dann bei einem Ausfall des IT-Systems gegebenenfalls nicht verfügbar ist (siehe auch M 6.20 Geeignete Aufbewahrung der Backup-Datenträger ).

Datensicherung der Datenbanken

Die bewährte Methode zur Datensicherung von OpenLDAP ist es, das slap*-Werkzeug slapcat zu verwenden, um einen Datenexport im Format LDIF zu erzeugen, während der slapd-Server gestoppt ist. Der erzeugte Export kann vor der Ablage komprimiert werden, da die Klartext-Struktur der LDIF-Dateien unnötig große Dateien erzeugt.

Werden die Daten des Verzeichnisdienstes bei laufendem slapd-Server mittels slapcat exportiert, kann dies zu Inkonsistenzen der Datensicherung führen, wenn Daten während des Exports verändert werden. Es ist auch möglich, die zu sichernden Datenbanken in einen Nur-Lese-Zustand zu versetzen. Zu beachten ist aber, dass der Server dann nicht für schreibende Zugriffe verfügbar ist und auf diese Weise auch nicht die Online-Konfiguration gesichert werden kann. Zwar lässt sich auch das Suffix "CN=config" in einen Nur-Lese-Zustand versetzen, es kann aber nicht mehr ohne Neustart aus diesem Zustand befreit werden. Eine konsistente und vollständige Sicherung ist deswegen grundsätzlich nicht ohne einen Stopp des slapd-Servers möglich.

Rücksicherung

Für die Rücksicherung der Datenbestände sollte immer das Werkzeug slapadd eingesetzt werden. Prinzipiell ist auch das Werkzeug ldapadd oder eine geeignete Client-Anwendung in der Lage, Objekte aus LDIF-Dateien in einen Verzeichnisdienst einzufügen. Dies hat jedoch mehrere Nachteile:

  • Das Werkzeug slapcat erzeugt den LDIF-Export entsprechend der physikalischen Reihenfolge der Objekte in der Datenbank. Wird diese Datei mittels ldapadd oder ähnlicher Client-Anwendungen in einen Verzeichnisdienst eingefügt, können Objekte gegebenenfalls nicht angelegt werden, wenn die ihnen übergeordneten Objekte noch nicht eingelesen wurden (weil sie in der gesicherten Datenbank physikalisch erst hinter den ihnen untergeordneten Objekten abgelegt wurden).
  • Client-Anwendungen wie ldapadd kommunizieren mit dem laufenden slapd-Server über eine bestehende, möglichst verschlüsselte Netzverbindung. Der initiale Import einer Datensicherung auf diese Weise beansprucht unnötig viel Zeit, Bandbreite und Ressourcen.
  • Der Import über ldapadd oder andere Client-Anwendungen erfordert einen laufenden slapd-Server, auf den schreibender Zugriff gewährt wird. Es besteht die Gefahr, dass während eines Imports durch andere Clients bereits auf unvollständige Daten zugegriffen wird oder Objekte in einer Weise angelegt oder geändert werden, die mit noch rückzusichernden Datensätzen in Konflikt stehen.

Sicherung einer Replik bei hohen Ansprüchen an die Verfügbarkeit

Bestehen Verfügbarkeitsanforderungen an den slapd-Server, die eine Unterbrechung des Serverbetriebs (Downtime) oder eine Beschränkung auf Lesezugriffe für den Zeitraum der Sicherung nicht zulassen, so stellt die Sicherung über eine Replik (siehe M 4.389 Partitionierung und Replikation bei OpenLDAP ) eine gute Alternative dar. Dafür ist die oben beschriebene Vorgehensweise auf einen Consumer anzuwenden. Der Provider ist weiter verfügbar, während der Consumer angehalten wird. Nach Abschluss der Datensicherung werden beim Neustart des slapd-Servers auf dem Consumer über den "syncrepl"-Mechanismus alle in der Zwischenzeit am Provider vorgenommen Änderungen beim Consumer automatisch nachvollzogen. Unterschiede in einer gesicherten Konfiguration zwischen Provider und Consumer sind zu beachten.

Weitere Einsatzmöglichkeiten

Die hier beschriebene Datensicherung eignet sich auch gut, um damit initial eine Verzeichnisdienstreplik zu befüllen (siehe M 4.389 Partitionierung und Replikation bei OpenLDAP ), um OpenLDAP zu aktualisieren (siehe M 4.390 Sichere Aktualisierung von OpenLDAP ) oder die Migration zu einem anderen Verzeichnisdienst zu begleiten. In diesen Fällen ist jedoch Vorsicht geboten, wenn die Konfiguration als Teil des Verzeichnisbaums in einen Verzeichnisdienst geladen wird. Beispielsweise würde eine unangepasste Übertragung der Konfiguration eines Providers einen identischen Provider (statt eines Consumers) erzeugen, was Netzprobleme aufgrund zweier in kürzester Zeit inkonsistenter Provider zur Folge hätte.

Prüffragen:

  • Werden regelmäßig Datensicherungen des OpenLDAP-Servers samt seiner Verzeichnisdienstobjekte und Konfigurationseinstellungen erstellt?

  • Werden alle Partitionen des OpenLDAP-Servers von der Datensicherung berücksichtigt?

  • Werden die Daten bei einem Datenverlust ausschließlich mit geeigneten Werkzeugen wiederhergestellt?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK