Kopien erstellen

Das Erstellen einer Kopie dupliziert einen bestehenden Odoo-Dienst — einschliesslich seiner Datenbank und aller hochgeladenen Dateien — in einen neuen, unabhängigen Dienst. Dies ist eine der leistungsstärksten Funktionen in calmo.cloud für sicheres Testen von Änderungen.

Warum eine Kopie erstellen? #

• Upgrades sicher testen — Probiere Odoo- oder Addon-Upgrades an einer Kopie aus, bevor du dein Live-System anfasst
• Fehler debuggen — Reproduziere Probleme mit einem Spiegel deiner Produktionsdaten
• Benutzer schulen — Gib Teammitgliedern eine realistische Umgebung zum Üben
• Kunden-Vorschauen — Zeige Kunden, wie Änderungen mit deren echten Daten aussehen werden

Kopie erstellen #

1. Quelldienst öffnen #

Navigiere zum Dienst, den du kopieren möchtest, und öffne seine Detailseite.

2. Auf Create Copy klicken #

Klicke oben auf der Seite des Dienstes auf Create Copy. Derselbe Button steht in der Zeile des Dienstes in der Liste und in seinem Tab Copies.

3. Kopie konfigurieren #

Wähle:

• Neutralize sensitive data — Bereinigt Passwörter, E-Mail-Adressen und andere sensible Daten in der Kopie (für Testumgebungen empfohlen)
• Obfuscate personal data — Verschlüsselt die personenbezogenen Daten in der Kopie, bevor sie startet, damit du mit KI-Werkzeugen daran arbeiten kannst. Siehe Personenbezogene Daten verschleiern weiter unten
• Server — Wähle den Server, auf dem die Kopie gehostet werden soll. Das kann derselbe Server wie der des Originals sein, auch wenn er gerade nicht für Odoo bereit ist, oder jeder andere Server deines Teams, der für Odoo bereit ist — zum Beispiel ein eigener Testserver. Vorausgewählt ist der Server für Kopien des Originals (siehe unten). Ist dieser gerade nicht für Odoo bereit, ist nichts vorausgewählt, und du wählst den Server selbst.
• Start a coding agent in this copy — Nur für Teams mit Coding-Agents. Macht aus dem Dialog den Start einer Agent-Sitzung, siehe Kopien für einen Coding-Agent weiter unten

Hat der gewählte Server weder Arbeitsspeicher noch Datenbankverbindungen für eine weitere Kopie übrig, warnt dich der Dialog. Du kannst die Kopie trotzdem erstellen, aber Odoo auf diesem Server kann beendet werden, wenn der Arbeitsspeicher ausgeht. Wähle also einen anderen Server oder lösche eine Kopie, die du nicht mehr brauchst.

4. Auf Fertigstellung warten #

calmo.cloud klont die Datenbank und kopiert alle Dateien. Du kannst den Fortschritt im Aktionen-Tab verfolgen. Eine Kopie auf demselben Server wird lokal gesichert und geladen; eine Kopie auf einem anderen Server wird über calmo.cloud von einem Server zum anderen gestreamt, siehe So gelangt eine Kopie auf einen anderen Server weiter unten. Das Original läuft währenddessen weiter.

Wichtige Hinweise #

• Die Kopie ist eine Momentaufnahme — sie spiegelt den Zustand des Originaldienstes zum Zeitpunkt der Erstellung wider
• Änderungen an der Kopie werden nicht zum Original zurücksynchronisiert
• Die Kopie erhält eine eigene URL, Zugangsdaten und einen eigenen Hostnamen
• Die Kopie übernimmt die Repositories des Originals samt ihren Branches, danach gehören sie aber ihr selbst: Ein Repository, das du der Kopie hinzufügst, oder ein Branch, den du in ihrem Tab Repositories änderst, gilt nur für die Kopie, und Änderungen an den Repositories des Originals erreichen die Kopie nicht. Pull-Request-Previews sind auf einer Kopie ausgeschaltet.
• Du kannst eine Kopie jederzeit löschen, ohne das Original zu beeinflussen
• Eine Kopie startet mit eigenen, kleinen Performance-Einstellungen (Threaded-Modus, keine zusätzlichen Worker), damit sie nicht an dem Platz zehrt, auf den das Live-System auf demselben Server bemessen wurde. Erhöhe sie unter Performance, wenn du mehr brauchst. Siehe Performance einstellen.
• Eine Kopie übernimmt die Backup-Einstellungen ihres Originals, einschliesslich der Frage, ob nur die Datenbank gesichert wird, soweit dein Plan sie enthält

Kopien für einen Coding-Agent #

Sind Coding-Agents für dein Team aktiviert und darfst du sie auf dem Dienst starten, kann Create Copy einen starten. Schalte Start a coding agent in this copy ein, und der Dialog wird zum Start einer Agent-Sitzung: Er fragt statt nach einem Server und den Teams, mit denen die Kopie geteilt wird, nach Aufgabe, Repository und Modell des Agenten, lässt Neutralize sensitive data eingeschaltet und führt dich zur Sitzung, während die Kopie erstellt wird. Obfuscate personal data bleibt deine Wahl.

Eine Agent-Kopie ist eine eigene Kopie mit eigener Datenbank und eigenem Filestore, und sie erscheint im Tab Copies des Dienstes mit dem Typ Agent copy. Sie entsteht auf dem Server für Kopien des Dienstes, zählt nicht zum Kopienlimit deines Plans und bleibt, bis du sie entfernst, wie unter Zurückgeben beschrieben. Entferne Agent-Kopien, mit denen du fertig bist: Sie belegen weiter Serverressourcen.

Der Schalter erscheint nicht, wenn du eine Kopie aus einem Backup erstellst.

E-Mails von Kopien #

Eine neutralisierte Kopie kann keine E-Mails an echte Personen senden, aber oft willst du sehen, was sie gesendet hätte: eine Rechnung, eine Erinnerung, ein Passwort-Reset. Der Mail Catcher hebt diese E-Mails für dich auf. Er läuft einmal pro Server und bedient jede Kopie, auch die Agent-Kopien von Coding-Agents, und jedes Preview-Deployment darauf.

Bei neutralisierten Kopien ist Catch outgoing emails eingeschaltet, und die Kopie bekommt einen Tab Mails, der jede von ihr gesendete E-Mail auflistet. Öffne eine, um Absender, Empfänger, die HTML- und Textversion und die Anhänge zu sehen, die du herunterladen kannst. Delete all leert das Postfach der Kopie. Der Tab ist für Personen sichtbar, die den Dienst bearbeiten dürfen, weil abgefangene E-Mails Links zum Zurücksetzen von Passwörtern in die Kopie enthalten können.

Server, die aus einer Provisionierungsvorlage eingerichtet wurden, bekommen den Mail Catcher automatisch. Auf jedem anderen Server schaltest du ihn einmal ein:

1. Öffne die Einstellungen des Servers, wähle den Tab Mail catcher und schalte ihn ein.
2. Schalte bei jeder bereits vorhandenen Kopie Catch outgoing emails ein und deploye die Kopie neu.

Danach erstellte neutralisierte Kopien fangen ihre E-Mails ohne weitere Schritte ab. Live-Dienste senden ihre E-Mails nie an den Mail Catcher. Eine Kopie, die ohne Neutralisieren erstellt wurde, behält ihre eigenen Mailserver, ihre E-Mails werden also nicht abgefangen.

Der Mail Catcher bewahrt bis zu 5.000 E-Mails pro Server für höchstens 30 Tage auf. Eine Kopie, die einen Massenversand auslöst, kann ältere E-Mails anderer Kopien auf demselben Server verdrängen. Der Mail Catcher ist ab dem Starter-Plan enthalten. Abgefangene E-Mails lassen sich auch über die API und durch KI-Assistenten lesen und löschen.

Personenbezogene Daten verschleiern #

Ein KI-Assistent oder Coding-Agent, der an einer Kopie arbeitet, schickt alles, was er liest, an seinen Modellanbieter. Eine verschleierte Kopie hält die Namen, Adressen und Unterhaltungen deiner Kontakte davon fern.

calmo.cloud nutzt dafür Odoos eigenes odoo obfuscate. Es verschlüsselt diese Werte direkt in der Datenbank mit einem zufälligen Passwort, das gleich danach verworfen wird. Niemand kann sie also zurückverwandeln, auch calmo.cloud nicht:

• Kontakte: Name, E-Mail, Telefon, Adresse, USt-IdNr., Handelsregisternummer, Website und Notizen
• Chatter und E-Mails: Betreff, Inhalt, Absender und Empfänger sowie die alten und neuen Werte verfolgter Felder
• CRM-Leads, Bankkonten, Mitarbeitende (dienstliche und private Kontaktdaten, Ausweisnummern), Bewerbungen, Veranstaltungsteilnehmende, Mailing-Kontakte und Helpdesk-Tickets, sofern diese Apps installiert sind
• die Logins von Portal-Benutzern. Interne Benutzer behalten ihre Logins, damit dein Team sich weiter anmelden kann

Produkte, Preise, Beträge, Datumsangaben und die Struktur deiner Daten bleiben, wie sie sind, die Kopie verhält sich also weiter wie dein System. Verschleierte Werte erscheinen als lange Zeichenketten, die mit odoo_cyph_ beginnen.

Du kannst eine Kopie beim Erstellen verschleiern oder später mit Obfuscate an einer bestehenden Kopie, einem Test- oder Demo-Dienst; der Dienst startet dafür neu. Das lässt sich nicht rückgängig machen, und Live-Dienste lassen sich nicht verschleiern.

Ein verschleierter Dienst bleibt verschleiert. Jedes Backup, das du in ihn wiederherstellst, wird verschleiert, bevor der Dienst wieder startet. Schlägt das fehl, wird die wiederhergestellte Datenbank gelöscht und der Dienst bleibt gestoppt, damit die Daten des Backups nie erreichbar werden. Kopien eines verschleierten Dienstes werden ebenfalls immer verschleiert.

Ein Server für Kopien #

Ein übliches Setup ist ein Produktionsserver und ein separater Testserver. Lege bei einem Dienst den Server für Kopien fest, damit alles, was von ihm abgeleitet wird, standardmässig dorthin geht: manuelle Kopien, Preview-Deployments für Pull Requests und die Agent-Kopien von Coding-Agents werden dann auf diesem Server erstellt statt neben dem Produktionssystem. Lass das Feld leer, damit Kopien auf dem eigenen Server des Dienstes bleiben.

Der Server für Kopien muss einer der Server deines Teams sein, der für Odoo bereit ist. Beim manuellen Erstellen einer Kopie kannst du im Dialog weiterhin jeden anderen Server wählen.

Kopien auf einem anderen Server sind ab dem Starter-Plan enthalten. In Free entsteht jede Kopie auf dem eigenen Server des Dienstes; ein Server für Kopien, der vor dem Wechsel zu Free gewählt wurde, bleibt gespeichert und wird erst wieder genutzt, wenn dein Plan ihn enthält. Siehe Preise und Abrechnung.

So gelangt eine Kopie auf einen anderen Server #

Wird die Kopie auf einem anderen Server als dem des Originals erstellt, bewegt calmo.cloud die Daten so, wie es alles andere auf deinen Servern erledigt: über die SSH-Verbindung, die es zu jedem der beiden Server ohnehin hat. Dafür wird auf keinem Server ein Schlüssel hinterlegt, deine Server müssen sich nicht gegenseitig erreichen, und der SSH-Schlüssel, mit dem calmo.cloud einen Server verwaltet, verlässt calmo.cloud nie.

1. Der Server des Originals packt die ausgerollten Addons und später den Datenbank-Dump in einen Datenstrom.
2. calmo.cloud leitet diesen Strom direkt an den Server der Kopie weiter, der ihn in das Verzeichnis der Kopie entpackt. Unterwegs wird nichts auf calmo.cloud gespeichert; die Daten laufen nur hindurch.
3. Der Server der Kopie lädt den Dump in sein eigenes PostgreSQL und startet die Kopie.
4. Der Dump wird vom Server des Originals gelöscht, sobald die Übertragung endet, ob erfolgreich oder nicht.
5. Es kommen ausschliesslich Dateien an: calmo.cloud entfernt dabei alles, was in einem Dienstverzeichnis nichts zu suchen hat, und ersetzt den Inhalt dieser Pfade, statt ihn zu vermischen.

Jede Übertragung ist eine Aktion auf dem Server der Kopie; du kannst sie im Tab Aktionen der Kopie verfolgen. Der Dump-Schritt läuft auf dem Quellserver und ist dort ebenfalls aufgeführt.

Eine nach der anderen. Eine Kopie entsteht aus einem frischen Dump des Dienstes, deshalb wird pro Dienst immer nur eine Kopie gleichzeitig erstellt: solange eine frühere noch ausgerollt wird, ist der Button Create Copy ausgegraut und die API antwortet mit 409. Ausgegraut ist er auch, wenn dein Plan keinen Platz für eine weitere Kopie hat. Vorschauen für Pull Requests und Agent-Kopien sind davon nicht betroffen, und Kopien verschiedener Dienste laufen weiterhin nebeneinander.

Für ein Team mit Coding-Agents bleibt der Button auf einem Dienst, von dem sich eine Agent-Kopie machen lässt, erreichbar, was auch immer eine normale Kopie verhindert. Der Dialog erstellt dann nur eine Agent-Kopie: Start a coding agent in this copy ist eingeschaltet und gesperrt, mit einem Hinweis, warum.

Was deine Server brauchen: nichts über das hinaus, was calmo.cloud ohnehin braucht, nämlich SSH-Zugang zu beiden Servern. Das Original läuft während der Übertragung weiter. Jeder Schritt einer Kopie – Dump, Übertragung, Laden – darf bis zu 50 Minuten dauern; ist ein System dafür zu gross, spiel stattdessen ein Backup auf dem anderen Server ein.

Kopien geteilter Dienste #

Ist der Dienst mit anderen Teams geteilt, fragt der Kopier-Dialog unter Share the copy with zusätzlich, welche Partnerteams die Kopie behält — ihre Rollen bleiben erhalten. Erstellt ein Partnerteam eine Kopie, läuft diese auf dem Server für Kopien des Hosting-Teams und ist nur mit diesem Partnerteam geteilt; ein Partnerteam wählt den Server nie selbst.