Dolibarr Docker Update ohne verlorene Migrationen

Das offizielle Docker-Image dolibarr/dolibarr kann die Datenbank beim Start selbst aktualisieren. Das ist bequem, und deshalb ist die Versuchung groß, einfach die Versionsnummer in docker-compose.yml zu ändern, neu zu starten und weiterzumachen.

Wenn Sie mehrere Versionen auf einmal überspringen, ist die Datenbank danach unvollständig, und nichts weist Sie darauf hin. Wir haben es am 27. September 2026 geprüft: Eine in 20.0.4 installierte Instanz, die nach der Dokumentation des Images direkt auf 24.0.0 gebracht wurde, meldet Version 24.0.0 und schreibt „Migration successful” ins Protokoll. Trotzdem fehlen ihr 17 Tabellen: 389 statt 406 bei derselben Instanz, die Version für Version aktualisiert wurde. Die Migrationen der Versionen 22 und 23 wurden nie ausgeführt.

Warum Migrationen verloren gehen

Beim Start vergleicht der Container die Version der Datenbank mit der seiner Dateien. Weichen sie ab, ruft er das Migrationsskript von Dolibarr ein einziges Mal auf, von der installierten Version bis zur Zielversion. Dieses Skript wählt aber nur zwei Dateien aus: die, die bei Ihrer Version beginnt, und die, die bei der Zielversion endet. Bei einem Wechsel von 20 auf 24 führt es die Migration 2021 und die Migration 2324 aus. Alles dazwischen wird ignoriert.

Der Web-Assistent von Dolibarr hat diesen Fehler nicht: Er führt Sie Schritt für Schritt durch. Das Problem entsteht durch den automatischen Ablauf des Images.

Die Anwendung startet normal, die Anmeldung funktioniert, die wichtigsten Masken öffnen sich. Der Fehler zeigt sich erst später, an dem Tag, an dem jemand eine Funktion nutzt, die eine fehlende Tabelle braucht: Kategorien an Rechnungen oder Aufträgen, Kostenrechnung und anderes. Dann denkt niemand mehr an das Update.

Prüfen, ob Ihre Datenbank vollständig ist

Diese Abfrage sucht für jede Version von 17 bis 24 ein Element, das nur die Migration dieser Version anlegt. Sie verändert nichts. Führen Sie sie auf der Dolibarr-Datenbank aus:

SELECT m.version, m.objet AS fehlt FROM (
  SELECT '17' AS version, 'llx_bank_extrafields' AS objet
  UNION ALL SELECT '18', 'llx_c_invoice_subtype'
  UNION ALL SELECT '20', 'llx_product_thirdparty'
  UNION ALL SELECT '21', 'llx_bank_import'
  UNION ALL SELECT '22', 'llx_categorie_invoice'
  UNION ALL SELECT '23', 'llx_accounting_analytic_axis'
  UNION ALL SELECT '24', 'llx_ai_request_log'
) m
WHERE m.objet NOT IN (
  SELECT table_name FROM information_schema.tables WHERE table_schema = DATABASE()
)
UNION ALL
SELECT '19', 'llx_c_tva.entity' FROM DUAL WHERE NOT EXISTS (
  SELECT 1 FROM information_schema.columns
  WHERE table_schema = DATABASE() AND table_name = 'llx_c_tva' AND column_name = 'entity'
)
ORDER BY 1;

Es dürfen nur Versionen oberhalb Ihrer eigenen erscheinen. Sind Sie auf 24 und die Abfrage liefert eine Zeile, wurde eine Migration übersprungen. Getestet wurde sie auf normal installierten Instanzen der Versionen 16, 18, 20, 22 und 24: Jede meldet nur die Versionen über ihr.

Die Abfrage setzt das Standard-Tabellenpräfix llx_ voraus. Verwenden Sie ein anderes, passen Sie die Namen an.

Der richtige Ablauf

Die Idee passt in einen Satz: immer nur eine Hauptversion, mit Ihrer eigenen Sicherung vor dem Start. Die Dienstnamen unten (web, mariadb) sind die des offiziellen Beispiels; passen Sie sie an Ihre an.

1. Sichern Sie selbst. Die Datenbank und die beiden persistenten Ordner: Dokumente und externe Module.

   docker compose exec -T mariadb sh -c 'mariadb-dump -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE"' > sicherung-vor-update.sql

   Das Image kopiert die Datenbank zwar vor jeder Migration, aber immer unter demselben Namen, und die Kopie wird beim nächsten Schritt überschrieben: Nach zwei Schritten gibt es die Kopie Ihrer Ausgangsversion nicht mehr.

2. Legen Sie eine genaue Versionsnummer fest in docker-compose.yml, nie latest. Mit latest kann ein einfaches docker compose pull Sie auf eine neue Hauptversion bringen, ohne dass Sie das entschieden haben.

3. Gehen Sie nur eine Hauptversion höher: Ersetzen Sie zum Beispiel dolibarr/dolibarr:20.0.4 durch dolibarr/dolibarr:21.0.4.

4. Löschen Sie die Installationssperre, sonst wird die Datenbank nicht aktualisiert und Dolibarr bleibt auf einer gesperrten Installationsseite hängen:

   docker compose exec web rm -f /var/www/documents/install.lock

5. Starten Sie neu und lesen Sie das Protokoll, bis „Migration successful” erscheint:

   docker compose pull web && docker compose up -d && docker compose logs -f web

6. Wiederholen Sie das für die nächste Version, bis zur Zielversion.

Neueste offizielle Images jedes Zweigs am 4. Oktober 2026: 16.0.5, 17.0.4, 18.0.9, 19.0.4, 20.0.4, 21.0.4, 22.0.5, 23.0.4 und 24.0.1. Die 18.0.10 und die 24.0.2 gibt es, aber noch ohne Image. Lesen Sie vor dem Wechsel auf 24 die Falle mit dem unveränderbaren Protokoll in Dolibarr Update: Checkliste und Versionen 16 bis 24.

Vor jedem Schritt erledigt das kostenlose Modul Update-Bereitschaftsprüfung die meisten Prüfungen, ohne etwas zu verändern: Es liest den Code jedes externen Moduls gegen die Zielversion, prüft PHP, die Datenbank, berechnete Felder und ODT-Vorlagen und liefert einen Bericht. Es ersetzt weder die Sicherung noch den Test auf einer Kopie.

Wenn eine Migration fehlschlägt

Das Image stellt dann die Datenbank automatisch wieder her, der Container bleibt aber auf den Dateien der neuen Version. Dolibarr hängt danach auf der Installationsseite fest. Tragen Sie die vorherige Versionsnummer wieder in docker-compose.yml ein, starten Sie neu und lesen Sie die Datei migration_error.html im Dokumentenordner, um die Ursache zu finden.

Zwei weitere Fallen des Images

• conf.php bleibt nicht erhalten. Die Datei liegt im Container, nicht in einem Volume, und wird bei jeder Neuerstellung des Containers aus den Umgebungsvariablen neu geschrieben, also bei jedem Versionswechsel. Jede von Hand ergänzte Zeile verschwindet. Setzen Sie Ihre Einstellungen über Umgebungsvariablen oder binden Sie eine eigene Datei ein.
• Der Instanzschlüssel ist nicht zufällig. Laut Dokumentation des Images wird DOLI_INSTANCE_UNIQUE_ID beim Erstellen des Containers zufällig gesetzt. Im Code wird bei leerer Variable der feste Wert myinstanceuniquekey geschrieben, für alle derselbe. Legen Sie bei einer neuen Installation ab dem ersten Start einen eigenen Wert fest. Bei einer bestehenden Instanz ändern Sie ihn nicht: Mit diesem Schlüssel werden einige gespeicherte Einstellungen verschlüsselt, die sonst unlesbar würden.

Wenn Sie eine neue Instanz einrichten, betreffen Sie zwei weitere Mängel des Images (Passwörter als MD5 gespeichert, geplante Jobs, die nie laufen): siehe Dolibarr mit Docker Compose installieren.

Mit PostgreSQL führt das Image überhaupt kein automatisches Update durch: Nutzen Sie den Web-Assistenten unter der Adresse Ihres Dolibarr mit /install/ dahinter, auch hier Version für Version.

Wenn Ihre Datenbank schon Versionen übersprungen hat

Führen Sie die Migrationen nicht von Hand auf der echten Instanz erneut aus. Der sichere Weg: von der Sicherung vor dem Update ausgehen und das Update Version für Version wiederholen. Ohne Sicherung lässt sich die Datenbank vervollständigen, aber das ist Arbeit an einer Kopie, Tabelle für Tabelle, mit Prüfung der Daten.

Die Diagnose für 90 € zeigt, wo Ihre Datenbank steht. Das Paket Abgesichertes Update probt das gesamte Update an einer Kopie Ihrer Instanz, genau unter Docker, bevor die echte angefasst wird.

Siehe auch

• Dolibarr über die Kommandozeile aktualisieren
• Dolibarr sichern und wiederherstellen