Jede Odoo-Datenbank wird früher oder später zur zentralen Datenquelle eines Unternehmens: Rechnungen, Lagerbestände, Daten für die Lohnabrechnung, Kundenhistorie und unterschriebene Dokumente liegen alle darin. Geht sie verloren oder wird eine unvollständige Kopie wiederhergestellt, kann der Betrieb tagelang stillstehen. Dennoch entdecken viele Unternehmen die Lücken in ihrem Backup-Konzept erst an dem Tag, an dem sie es brauchen.
Dieser Artikel erläutert die Grundlagen der Datenbankverwaltung, der Backups und der Notfallwiederherstellung für Odoo 19 Enterprise, mit Hinweisen darauf, wo sich selbst gehostete Community-Installationen unterscheiden. Er richtet sich an Unternehmer, Finanzverantwortliche und IT-Leiter, die ein klares Bild brauchen, ohne jede technische Seite zu lesen.
Ein Hinweis zu den Quellen: Dieser Leitfaden folgt der offiziellen Odoo-Dokumentation für Version 19. Hosting-Plattformen und ihre Optionen entwickeln sich weiter. Prüfen Sie daher jeden Schritt in einer Testdatenbank und anhand der aktuellen offiziellen Dokumentation, bevor Sie sich in der Produktion darauf verlassen.
Was ein vollständiges Odoo-Backup enthält
Eine Odoo-Datenbank ist nicht nur eine PostgreSQL-Datenbank. Anhänge wie hochgeladene Dokumente, Bilder und andere Binärinhalte werden als Dateien im sogenannten Filestore gespeichert, und Odoo regelt den Zugriff darauf. Ein Backup, das nur den Datenbank-Dump enthält, stellt Ihre Datensätze wieder her, aber die Anhänge fehlen.
Die Dokumentation von Odoo.sh beschreibt ihre Backups so, dass sie den Datenbank-Dump, den Filestore (Anhänge und Binärfelder), Logs und Sessions umfassen. Das ist ein nützlicher Maßstab dafür, wie ein vollständiges Backup bei jeder Hosting-Art aussieht.
- Datenbank-Dump: alle Datensätze, Konfigurationen, Benutzer, Buchungen und Einstellungen.
- Filestore: Anhänge und Binärfelder, etwa gescannte Lieferantenrechnungen, Produktbilder und unterschriebene PDFs.
- Eigener Code: Auf Odoo.sh und On-Premise liegen Ihre eigenen Module in Ihrem Code-Repository, das einen eigenen Schutz benötigt.
- Konfiguration: On-Premise sollten auch die Odoo-Konfigurationsdatei und die Servereinrichtung dokumentiert und sicher aufbewahrt werden.
Wenn Sie ein Backup prüfen, stellen Sie immer sicher, dass sowohl der Dump als auch der Filestore vorhanden sind. Ein fehlender Filestore ist einer der häufigsten Gründe dafür, dass eine wiederhergestellte Datenbank zunächst in Ordnung aussieht und dann defekte Bilder und fehlende Dokumente zeigt.
Backups nach Hosting-Art
Wer für Backups verantwortlich ist, hängt davon ab, wo Ihre Datenbank läuft. Odoo Online und Odoo.sh werden von Odoo gehostet und umfassen automatische Backups, während bei einem On-Premise-Server Ihr eigenes Team die volle Verantwortung trägt. Die Community-Edition wird in der Regel selbst gehostet, daher gelten für sie die unten beschriebenen On-Premise-Pflichten.
Odoo Online: der Datenbankmanager
Für Odoo Online gibt die offizielle Dokumentation an, dass Datenbanken gemäß dem Odoo Cloud Hosting SLA täglich gesichert werden. Sie müssen nichts planen, damit die Plattform-Backups erfolgen.
Der Datenbankmanager, auf den Sie nach Anmeldung als Datenbankadministrator zugreifen, bietet unter „Verwalten“ die wichtigsten Aktionen für Backup- und Testarbeiten.
- „Backup herunterladen“ erzeugt eine ZIP-Datei der Datenbank, die Sie in Ihrem eigenen Archiv aufbewahren können.
- Ist „Backup herunterladen“ deaktiviert, ist die Datenbank für den Manager zu groß, und Sie sollten sich für eine andere Download-Methode an den Odoo-Support wenden.
- „Duplizieren“ erstellt eine Kopie der Datenbank; die Option „Für Testzwecke“ ist standardmäßig aktiviert und deaktiviert externe Aktionen wie E-Mails, Zahlungen und Lieferaufträge.
- „Löschen“ entfernt die Datenbank sofort für alle Benutzer und lässt sich nicht rückgängig machen – laden Sie daher vorher ein Backup herunter.
Laut Dokumentation laufen Duplikate auf Odoo Online nach 15 Tagen ab, und jede Datenbank kann bis zu fünf Duplikate haben. Betrachten Sie Duplikate als kurzlebige Testumgebungen, nicht als Backup-Strategie.
Odoo.sh: automatische und manuelle Backups
Auf Odoo.sh wird die Produktionsdatenbank jeden Tag automatisch gesichert. Laut Dokumentation werden sieben tägliche, vier wöchentliche und drei monatliche Backups aufbewahrt, wobei die monatlichen Kopien auf dedizierten Backup-Servern liegen. Um diese monatlichen Backups wiederherzustellen oder herunterzuladen, müssen Sie den Odoo-Support kontaktieren.
Staging- und Entwicklungs-Branches werden nicht automatisch gesichert. Für Produktion und Staging können manuelle Backups erstellt werden, um einen bestimmten Stand festzuhalten, zum Beispiel vor einer riskanten Konfigurationsänderung. Sie bleiben drei Tage verfügbar, und die Dokumentation nennt ein Limit von fünf manuellen Backups pro Tag. Entwicklungsdatenbanken lassen sich nicht manuell sichern.
Odoo.sh erstellt außerdem ein automatisches, als Update-Backup gekennzeichnetes Backup, wenn ein gemergter Commit Modulversionen oder verknüpfte Python-Abhängigkeiten ändert. Ändert ein Merge diese nicht, wird kein Backup ausgelöst; erstellen Sie daher vor wesentlichen Änderungen an der Produktion ein manuelles Backup.
- Nutzen Sie den Reiter „Backups“ des Produktions-Branches, um Backups zu prüfen, herunterzuladen oder wiederherzustellen.
- Stellen Sie ein Produktions-Backup in einem Staging-Branch wieder her, wenn Sie mit echten Daten testen möchten.
- Nutzen Sie die Funktion „Datenbank importieren“, um Archive aus dem Standard-Datenbankmanager, dem Datenbankmanager von Odoo Online, dem Reiter „Backups“ oder der Option „DB-Dump herunterladen“ eines Builds einzuspielen.
On-Premise: Ihr Team verantwortet alles
Auf Ihrem eigenen Server wird nichts gesichert, solange Sie es nicht einrichten. Die offiziellen Deployment-Hinweise sind eindeutig: Richten Sie tägliche Backups Ihrer Datenbanken und Filestore-Daten ein und kopieren Sie sie auf einen entfernten Archivserver, auf den vom Server selbst aus nicht zugegriffen werden kann.
Dieselben Hinweise warnen, dass der webbasierte Datenbankmanager als Entwicklungs- und Demowerkzeug gedacht und nicht für den Produktionseinsatz ausgelegt ist. Es wird dringend empfohlen, ihn auf allen aus dem Internet erreichbaren Systemen zu deaktivieren; Produktionsaufgaben wie automatisierte Backups sollten vom Systemadministrator übernommen werden.
- Schützen Sie die Bildschirme zur Datenbankverwaltung mit einem starken, zufällig erzeugten Master-Passwort in der Konfigurationsdatei, niemals mit dem Standardwert.
- Deaktivieren Sie die Datenbankauflistung auf aus dem Internet erreichbaren Servern und verwenden Sie einen Datenbankfilter, damit jeder Hostname der richtigen Datenbank zugeordnet wird.
- Betreiben Sie den PostgreSQL-Benutzer von Odoo ohne Superuser-Rechte, wie es die Deployment-Dokumentation vorschreibt.
- Sichern Sie Datenbank und Filestore gemeinsam, damit beide zueinander konsistent bleiben.
Vor größeren Änderungen wie dem Wechsel von Community zu Enterprise nennt die offizielle Dokumentation das Backup der Community-Datenbank als ersten Schritt. Behalten Sie diese Gewohnheit vor jedem Upgrade, jeder Modulinstallation und jedem Datenimport bei.
Datenbanken sicher duplizieren: Neutralisierung
Tests an einer Kopie der Produktion sind der sicherste Weg, neue Abläufe, Importe oder Upgrades auszuprobieren – doch eine unbedachte Kopie kann echte E-Mails an Kunden senden oder echte Zahlungen auslösen. Odoo löst das mit neutralisierten Datenbanken, die die Dokumentation als Nicht-Produktionsdatenbanken definiert, in denen mehrere Parameter deaktiviert sind.
Testdatenbanken sind immer neutralisiert, einschließlich Backup-Kopien, Duplikaten sowie Staging- und Entwicklungsdatenbanken auf Odoo.sh. Die Liste der deaktivierten Elemente in der Dokumentation ist ausdrücklich nicht abschließend und umfasst Folgendes.
- Geplante Aktionen, etwa die automatische Abonnementabrechnung und Massenmailings.
- Ausgehende E-Mails, die auf Odoo.sh-Staging von einem Mail-Catcher abgefangen statt versendet werden.
- Banksynchronisierung, Zahlungsanbieter und Liefermethoden.
- IAP-Token sowie die Sichtbarkeit der Website für Suchmaschinen.
Ein rotes Banner oben auf dem Bildschirm kennzeichnet eine neutralisierte Datenbank, sodass Benutzer sofort erkennen, dass sie nicht in der Produktion arbeiten. Schulen Sie Ihr Team, vor jeder Eingabe auf dieses Banner zu achten, und heben Sie die Neutralisierung einer Kopie nie auf, wenn Sie die Folgen nicht vollständig verstehen.
Aufbewahrung, externe Kopien, RPO und RTO
Plattform-Backups sind ein starkes Sicherheitsnetz, doch eine solide Richtlinie sieht auch unabhängige Kopien unter Ihrer eigenen Kontrolle vor. Laden Sie bei gehosteten Datenbanken regelmäßig ein vollständiges Backup herunter und bewahren Sie es an einem separaten, zugriffsgeschützten Ort auf. Bei On-Premise-Servern sind externe Kopien unverzichtbar, nicht optional.
Zwei einfache Kennzahlen helfen bei der Entscheidung, wie viel Schutz Sie brauchen. Das Recovery Point Objective (RPO) gibt an, wie viele aktuelle Daten Sie verlieren können; ein tägliches Backup bedeutet, dass Sie bis zu einen Arbeitstag verlieren können. Das Recovery Time Objective (RTO) gibt an, wie lange das Unternehmen ohne das System auskommen kann, während es wiederhergestellt wird.
Stimmen Sie diese Ziele mit der Geschäftsleitung ab und prüfen Sie dann, ob Ihre aktuelle Einrichtung sie erfüllt. Ist der Verlust der Verkaufsaufträge eines ganzen Tages inakzeptabel, reichen tägliche Backups allein nicht aus, und Sie sollten häufigere Snapshots oder andere Maßnahmen mit Ihrem Hosting-Anbieter oder IT-Team besprechen.
Wiederherstellungstests und eine praktische Checkliste
Ein Backup ist erst bewiesen, wenn es wiederhergestellt wurde. Planen Sie in regelmäßigen Abständen einen Wiederherstellungstest, stellen Sie in eine neutralisierte Testumgebung wieder her und bestätigen Sie, dass sich Benutzer anmelden können, aktuelle Datensätze vorhanden sind und sich Anhänge korrekt öffnen lassen. Messen Sie die Dauer des Vorgangs, damit Sie Ihr tatsächliches RTO kennen.
- Klären Sie, welche Hosting-Art Sie nutzen und wer für Backups verantwortlich ist.
- Prüfen Sie, ob Backups sowohl den Datenbank-Dump als auch den Filestore enthalten.
- Bewahren Sie eine unabhängige heruntergeladene Kopie an einem separaten, gesicherten Ort auf.
- Erstellen Sie vor Upgrades, großen Importen oder wesentlichen Konfigurationsänderungen ein manuelles Backup.
- Nutzen Sie für alle Tests neutralisierte Duplikate oder Staging-Branches.
- Stellen Sie regelmäßig ein Backup in einer Testumgebung wieder her und dokumentieren Sie die Ergebnisse.
- Dokumentieren Sie Ihre RPO- und RTO-Ziele und überprüfen Sie sie jedes Jahr.
- Deaktivieren Sie On-Premise den öffentlichen Datenbankmanager und schützen Sie das Master-Passwort.
Wie 1CBMS Sie unterstützen kann
1CBMS konzipiert und überprüft Backup- und Wiederherstellungsroutinen für Odoo-19-Projekte in Ägypten und im Irak, auf Odoo Online, Odoo.sh und On-Premise-Servern. Wir können Ihre aktuelle Einrichtung prüfen, gemeinsam mit Ihrer Geschäftsleitung realistische RPO- und RTO-Ziele festlegen, neutralisierte Testumgebungen einrichten und mit Ihrem Team einen dokumentierten Wiederherstellungstest durchführen, damit die Wiederherstellung ein eingeübtes Verfahren ist und kein Notfall.