Zu einem anderen Hoster umziehen

Dein Odoo läuft auf deinem eigenen Server und seine Backups liegen in deinem eigenen Speicher. Du kannst es also jederzeit mitnehmen. Diese Anleitung beschreibt den Umzug zu einem Hoster, den calmo.cloud nicht verwaltet: was du mitnimmst, wie du es bei einem großen Dateispeicher herausbekommst und was du aufräumst, sobald die Datenbank an ihrem neuen Ort läuft.

Wenn du nur den Server behalten und calmo.cloud nicht mehr nutzen willst, lies Was passiert, wenn du gehst.

Was du mitnimmst #

Das Archiv ist das Standard-Backup-Format von Odoo: ein .zip mit dump.sql, filestore/ und manifest.json. Odoos Datenbank-Manager und odoo db load stellen es auf jedem Host wieder her.

Bevor du beginnst #

Der neue Host braucht:

• Dieselbe Odoo-Version, als Odoo Enterprise. calmo.cloud betreibt Enterprise, in deiner Datenbank sind also Enterprise-Module installiert. Den Enterprise-Code bekommst du über dein Odoo-Abonnement, nicht über das Backup.
• PostgreSQL in mindestens der Version deines calmo.cloud-Servers. Die manifest.json im Archiv nennt sie als pg_version.
• Die Python-Pakete, die deine Addons brauchen. Auf calmo.cloud werden sie aus den external_dependencies im Manifest jedes Addons installiert.

Notiere dir, was der neue Host treffen soll. Die Seite des Dienstes zeigt die Commits unter Odoo source und die Python version, und in den Einstellungen des Dienstes steht deine zusätzliche Odoo-Konfiguration (siehe Dienste verwalten). Die manifest.json listet jedes installierte Modul mit seiner Version.

Schritt 1: Entscheiden, wie der Addon-Code mitkommt #

Jedes Custom-Addon auf calmo.cloud wird aus einem GitHub-Repository deployt, das dir gehört. Das gilt auch für Apps aus dem Odoo App Store oder aus einem ZIP: Sie wurden in dein privates Repository committet. Der Code gehört dir also schon, und es reicht, die Repositories zu klonen. Der Addons-Tab zeigt, aus welchem Repository und Commit jedes deployte Addon stammt.

Wenn du lieber genau das mitnimmst, was deployt ist, und zwar in einem Stück, lass das Backup den Code tragen: Schalte Include addon code ein, wenn du in Schritt 2 das Backup erstellst. Das Archiv enthält dann einen Ordner addons/ mit einem Ordner pro deploytem Addon. Odoo ignoriert diesen Ordner beim Wiederherstellen, das Archiv bleibt also ein normales Backup.

Schritt 2: Das letzte Backup erstellen #

1. Bitte deine Nutzer, nicht mehr in Odoo zu arbeiten, damit sich nach dem Backup nichts mehr ändert.
2. Prüfe die Backup Settings des Dienstes: Ist Back up the database only eingeschaltet, enthält das Backup keinen Dateispeicher. Schalte es für ein vollständiges Archiv aus, außer du kopierst den Dateispeicher selbst (siehe Ein sehr großer Dateispeicher).
3. Öffne den Backups-Tab, klicke auf Create Backup und schalte Include addon code ein, wenn die Addons ins Archiv sollen.

Das Archiv wird vom Server direkt an dein Backup-Ziel gestreamt. Auf der Festplatte des Servers wird nichts zwischengespeichert, der Server braucht dafür also keinen freien Platz, egal wie groß der Dateispeicher ist. Die Spalte Contents zeigt, was das fertige Backup enthält.

Schritt 3: Das Archiv herunterladen #

Klicke im Backups-Tab beim Backup auf Download. Der Link zeigt direkt auf deinen Speicher und ist 60 Minuten gültig.

Lade ein großes Archiv mit einem Werkzeug herunter, das abgebrochene Downloads fortsetzen kann:

curl -L -C - -o backup.zip 'https://…der Download-Link…'

Ein Download, der beim Ablauf des Links noch läuft, wird normal fertig. Bricht die Verbindung danach ab, klicke erneut auf Download und führe denselben Befehl mit dem neuen Link aus: curl macht dort weiter, wo es aufgehört hat.

Ein sehr großer Dateispeicher #

Ein Backup kann bis zu drei Stunden laufen und mehrere hundert Gigabyte fassen. Ist dein Dateispeicher größer oder der Upload in deinen Speicher langsam, zieh den Dateispeicher getrennt um. Der Server gehört dir, du kannst die Dateien also direkt kopieren:

1. Schalte in den Backup Settings des Dienstes Back up the database only ein.

2. Kopiere den Dateispeicher vom Server auf den neuen Host, während Odoo noch genutzt wird. Dieser erste Durchlauf überträgt den Großteil der Daten:

   rsync -a --info=progress2 \
     root@203.0.113.10:/data/aura/services/odoo/<UUID des Dienstes>/volumes/odoo/data/filestore/<UUID des Dienstes>/ \
     /var/lib/odoo/filestore/<Datenbankname>/
   

3. Bitte deine Nutzer, nicht mehr zu arbeiten, und erstelle dann das Backup wie in Schritt 2. Es enthält jetzt die Datenbank (und den Addon-Code, wenn du das gewählt hast) und ist klein.

4. Wenn das Backup abgeschlossen ist, führe denselben rsync-Befehl noch einmal aus. Er überträgt nur, was sich seit dem ersten Durchlauf geändert hat.

Die UUID des Dienstes ist der Name seines Ordners unter /data/aura/services/odoo/ auf dem Server und der db_name in der manifest.json des Archivs. Der Zielpfad hängt vom neuen Host ab: Der Dateispeicher gehört nach filestore/<Datenbankname> im Datenverzeichnis von Odoo.

Schritt 4: Auf dem neuen Host wiederherstellen #

Wie du wiederherstellst, hängt vom neuen Host ab. Mit Odoos Kommandozeile:

unzip backup.zip 'addons/*' -d /opt/odoo/custom   # nur, wenn das Archiv Addon-Code enthält
odoo db load --move <Datenbankname> backup.zip

• Lege die Addons vor dem ersten Start in den Addons-Pfad des neuen Odoo und installiere ihre Python-Pakete. Eine wiederhergestellte Datenbank erwartet, dass jedes installierte Modul vorhanden ist.
• --move behält die UUID der Datenbank, mit der dein Odoo-Enterprise-Abonnement registriert ist. In Odoos Datenbank-Manager ist das die Auswahl This database was moved. Ohne sie behandelt Odoo die Datenbank als Kopie und gibt ihr eine neue UUID.
• Hast du den Dateispeicher selbst kopiert, muss er unter dem Namen der neuen Datenbank an seinem Platz liegen, bevor Odoo startet.

Andere Hoster nehmen dasselbe Archiv über ihren eigenen Import an, zum Beispiel über Odoos Datenbank-Manager unter /web/database/manager.

Schritt 5: Nach der Wiederherstellung aufräumen #

• Deinstalliere das Modul havsh. calmo.cloud installiert dieses kleine Begleitmodul in jeder Datenbank, damit die Modulliste im Panel aktuell bleibt. Sein Code ist Teil des calmo.cloud-Images und zieht nicht mit um. Bis es deinstalliert ist, schreibt Odoo bei jedem Start module havsh: not installable, skipped ins Log, was harmlos ist. Entferne unter Apps den Filter Apps, suche nach havsh und deinstalliere es, oder führe das in der odoo shell aus:

  env['ir.module.module'].search([('name', '=', 'havsh')]).button_immediate_uninstall()
  env.cr.commit()
  

• Setze web.base.url. calmo.cloud hat den Wert auf die Adresse des Dienstes gesetzt. Ändere ihn unter Settings → Technical → System Parameters auf die neue Adresse.

• Prüfe alles, was auf den alten Server zeigte: Postausgangs- und Posteingangsserver, geplante Aktionen, die externe Systeme aufrufen, Integrationen mit freigeschalteter fester IP-Adresse.

• Stelle deine Domain um. Richte ihren DNS-Eintrag auf den neuen Host. Die Plattform-Domain des Dienstes bleibt bei calmo.cloud, ersetze sie also überall, wo sie verwendet wurde.

• Ersetze, was calmo.cloud für dich erledigt hat: Geplante Backups, TLS-Zertifikate, Weiterleitungen, Monitoring und Uptime-Checks ziehen nicht mit der Datenbank um.

Schritt 6: Auf calmo.cloud abschließen #

Lass den Dienst auf calmo.cloud gestoppt, aber nicht gelöscht, bis die neue Instanz einige Tage ohne Probleme gelaufen ist.

Mit der API oder einem KI-Assistenten #

In einem Plan mit API lassen sich dieselben Schritte skripten: POST /api/service-odoo/{uuid}/create-backup nimmt include_addons an, und GET /api/service-odoo/{uuid}/backups/{backup}/download-url liefert den Download-Link. Ein KI-Assistent, der über den MCP-Server verbunden ist, nutzt dafür create_backup und get_backup_download_url. Siehe die API-Übersicht.

Wie geht es weiter? #