Dolibarr sichern und wiederherstellen

Die vier Bestandteile einer Sicherung, die eingebaute automatische Sicherung von Dolibarr und eine auf einer neuen Instanz getestete Wiederherstellung. Ohne den Schlüssel aus conf.php bleiben Kunden-IBANs und API-Schlüssel unlesbar.

Betroffene Versionen
Dolibarr 24.0.1 (getestet, offizielles Docker-Image, MariaDB 11.4); das Prinzip gilt für alle aktuellen Versionen
Was geprüft wurde
Tests am 13.10.2026 mit Dolibarr 24.0.1: Datenbanksicherung und Dokumentenarchiv über die Oberfläche, geplanter Sicherungsjob dreimal mit Aufbewahrung von 2 Dateien ausgeführt, vollständige Wiederherstellung auf einer neuen Instanz (gleiche Version), dann Lesen der verschlüsselten Daten mit dem richtigen und mit einem anderen Instanzschlüssel. Code von Dolibarr gelesen (dolEncrypt, dolibarr_set_const, Utils::dumpDatabase).

Eine Dolibarr-Sicherung, mit der man wirklich neu starten kann, besteht aus vier Teilen. Die ersten drei sind bekannt; der vierte wird fast immer vergessen, und ohne ihn bleibt ein Teil der Daten nach der Wiederherstellung unlesbar.

Wir haben alles am 13. Oktober 2026 mit Dolibarr 24.0.1 geprüft: Sicherung, Wiederherstellung auf einer neuen Instanz, dann Lesen der Daten mit dem richtigen und mit einem falschen Schlüssel.

Die vier Teile einer Sicherung

  1. Die Datenbank: Geschäftspartner, Rechnungen, Einstellungen, Benutzer.
  2. Der Ordner documents: erzeugte PDFs, angehängte Dateien, Logo, ODT-Vorlagen. Wo er liegt, steht in conf.php, Variable $dolibarr_main_data_root.
  3. Der Ordner custom: externe Module (zum Beispiel aus dem DoliStore), in htdocs/custom. Das von Dolibarr angebotene Dokumentenarchiv enthält ihn nicht.
  4. Der Instanzschlüssel in htdocs/conf/conf.php: $dolibarr_main_instance_unique_id, oder $dolibarr_main_dolcrypt_key, falls vorhanden. Unter Docker ist es die Variable DOLI_INSTANCE_UNIQUE_ID, also die Datei .env.

Warum der Schlüssel zählt

Dolibarr verschlüsselt mit diesem Schlüssel bestimmte Daten der Datenbank:

  • die IBANs der Kunden (für SEPA-Lastschriften);
  • die API-Token der Benutzer;
  • Einstellungen, deren Name auf _KEY, _PASS, _PASSWORD, _PW oder _SECRET endet, wenn sie am Bildschirm eingegeben werden: Passwort des E-Mail-Servers, Schlüssel der Online-Zahlungsmodule…

Wir haben eine Datenbank auf einer neuen Instanz mit einem anderen Schlüssel wiederhergestellt. Das API-Token wurde abgelehnt („Error user not valid (not found with api key…)“), und die IBAN eines Kunden erschien so:

dolcrypt:AES-256-CTR:5efe1028549de1db:HSkQmbe/oNN7CN/CER+o5uHUC5qQN70IWV2T

Mit dem richtigen Schlüssel war die IBAN wieder lesbar: Die Daten sind nicht verloren, aber man braucht den ursprünglichen Schlüssel. Die IBAN Ihres eigenen Bankkontos wird nicht verschlüsselt.

Über die Oberfläche sichern

Admin-Tools › Datensicherung bietet zwei Assistenten:

  • die Datenbank: Methode „MySQL Dump (mysqldump)“, Gzip-Komprimierung, Sicherung erzeugen. Die Datei liegt in documents/admin/backup/.
  • der Ordner documents: die zweite Schaltfläche Sicherung erzeugen. Das Archiv liegt in documents/admin/documents/.

Beide Dateien bleiben auf demselben Server: Laden Sie sie herunter, auf derselben Seite, sonst gehen sie mit ihm verloren. Die Seite erwähnt auch den Schlüssel aus conf.php, den sie selbst nicht anzeigen kann: Dafür braucht es Zugriff auf die Dateien des Servers.

Automatisch sichern, ohne Skript

Dolibarr enthält einen geplanten Sicherungsjob, der standardmäßig deaktiviert ist. Er braucht das Modul Geplante Jobs und einen Cron, der ihn ausführt (unter Docker siehe Dolibarr mit Docker Compose installieren).

Admin-Tools › Geplante Jobs, Job Lokales Datenbank-Backup, Bearbeiten. Seine Parameter, durch Kommas getrennt:

gz,auto,1,auto,10,0,0

Der Reihe nach: Komprimierung (gz, bz oder none), Datenbanktyp (auto), 1, Dateiname (auto), Anzahl der aufzubewahrenden Sicherungen, dann zwei technische Optionen, die auf 0 bleiben. Stellen Sie die Häufigkeit ein (standardmäßig einmal pro Woche), speichern Sie und aktivieren Sie den Job.

Getestet mit einer Aufbewahrung von 2: Nach drei Läufen waren nur die beiden letzten Sicherungen übrig. Der Kommentar im Code sagt, dieser Parameter werde „noch nicht verwendet“; er wird es. Wie bei der manuellen Sicherung bleiben diese Dateien auf dem Server: Kopieren Sie sie anderswohin.

Auf der Kommandozeile sichern

Mit Docker und der Konfiguration aus unserer Installationsanleitung, im Projektordner:

docker compose exec -T db sh -c 'mariadb-dump -u"$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"' | gzip > dolibarr.sql.gz
tar -czf dolibarr-dateien.tar.gz data/documents data/custom .env docker-compose.yml

Auf einem klassischen Server gilt dasselbe Prinzip: Lesen Sie in conf.php den Datenbanknamen ($dolibarr_main_db_name), den Benutzer und den Dokumentenordner, dann:

mariadb-dump -u benutzer -p datenbankname | gzip > dolibarr.sql.gz
tar -czf dolibarr-dateien.tar.gz /pfad/zu/documents /pfad/zu/htdocs/custom /pfad/zu/htdocs/conf/conf.php

Mit einem MySQL-Server heißt der Befehl mysqldump. Bei manchen aktuellen MariaDB-Installationen gibt es nur noch mariadb-dump: So ist es im offiziellen Image von MariaDB 11.4, in dem mysqldump nicht gefunden wird.

Eine vollständige Datenbanksicherung endet mit -- Dump completed:

gzip -dc dolibarr.sql.gz | tail -1

Wiederherstellen, auf demselben oder einem neuen Server

Stellen Sie auf derselben Dolibarr-Version wieder her wie bei der Sicherung: Die Struktur der Datenbank hängt von der Version ab. Für einen Versionswechsel erst wiederherstellen, dann aktualisieren. Dolibarr erlaubt keine Wiederherstellung aus der Anwendung heraus, aus Sicherheitsgründen: Alles geschieht auf dem Server.

Mit Docker, in dieser Reihenfolge (so haben wir es getestet):

  1. Dateien zurücklegen: data/documents und data/custom entpacken und die alte .env übernehmen, mit derselben INSTANCE_UNIQUE_ID.

  2. Nur die Datenbank starten und warten, bis sie bereit ist:

    docker compose up -d db

  3. Die Sicherung einspielen:

    gzip -dc dolibarr.sql.gz | docker compose exec -T db sh -c 'mariadb -u"$MARIADB_USER" -p"$MARIADB_PASSWORD" "$MARIADB_DATABASE"'

  4. Dolibarr starten:

    docker compose up -d

    Das Log (docker compose logs web) muss „install.lock exists and database exists so we cancel database init“ melden: Das Image hat eine bestehende Installation erkannt und legt keine neue an.

  5. Anmelden mit einem Administratorkonto, das zum Zeitpunkt der Sicherung existierte.

In unserem Test war alles da: die 13 Rechnungen mit ihren PDFs, der Ordner custom, die Anmeldung des Administrators und das API-Token, akzeptiert, weil der Instanzschlüssel derselbe war.

Auf einem klassischen Server: dieselbe Dolibarr-Version installieren, die Ordner documents und custom zurücklegen, den Instanzschlüssel in die neue conf.php übernehmen, die Datenbank mit mariadb (oder mysql bei einem MySQL-Server) einspielen, dann anmelden.

Wenn der Schlüssel fehlt

Verschlüsselte Daten sind nicht verloren, aber unlesbar. Finden Sie die alte conf.php wieder, setzen Sie einfach den Schlüssel zurück: Alles wird wieder lesbar. Andernfalls die IBANs der Kunden neu eingeben, die API-Token neu erzeugen und das Passwort des E-Mail-Servers sowie die Schlüssel der Zahlungsmodule neu eintragen.

Testen Sie Ihre Sicherung

Eine Sicherung, die nie wiederhergestellt wurde, ist nur eine Annahme. Stellen Sie sie ab und zu auf einer separaten Instanz wieder her, wie in diesem Test, und prüfen Sie, dass sich eine Rechnung öffnen lässt und ihr PDF angezeigt wird.

Das ist auch der erste Schritt jedes Updates: Das Paket Abgesichertes Update beginnt mit dieser Kopie und hält eine Sicherung für den Rückweg bereit.

Siehe auch

DolibarrBackupDatensicherungWiederherstellungUmzugServermysqldumpconf.php