Überblick

Die Kontomigration überträgt ausgewählte Konten — mit ihren Benutzern, Rollen, Digitalen Zwillingen, Virtuellen Geräten, Konnektoren, Integrationsflows, Dashboards, Protokollen und gespeicherten Dateien — von einer niotix-Instanz auf eine andere. Die IDs bleiben dabei erhalten: Konten, Zugriffsbereiche, Benutzer und Rollen behalten auf dem Zielsystem dieselben Kennungen wie auf dem Quellsystem.

Ausgeführt wird die Migration mit dem Kommandozeilenwerkzeug tenant-migrate. Es arbeitet in zwei getrennten Hälften:

• export verbindet sich ausschließlich mit der Quelldatenbank und dem Dateispeicher der Quellinstanz und liest ausschließlich lesend. Ergebnis ist ein Snapshot — ein Verzeichnis mit einer JSONL-Datei je Datenbanktabelle, den gespeicherten Dateien und Metadaten.
• import verbindet sich ausschließlich mit der Zieldatenbank und dem Dateispeicher der Zielinstanz und spielt einen solchen Snapshot ein.

Mit pack wird der geprüfte Snapshot vor der Übergabe in ein passwortgeschütztes, AES-256-verschlüsseltes ZIP-Archiv verpackt; der Import liest dieses Archiv direkt.

Zwischen den beiden Hälften besteht keine Netzwerkverbindung. Die Übergabe erfolgt als Datei-Übergabe des Archivs. Damit lässt sich die Migration auch über Organisationsgrenzen hinweg durchführen: DIGIMONDO exportiert aus der Quellinstanz, der Betreiber der Zielinstanz importiert das übergebene Archiv.

Anwendungsfälle

• Wechsel des Betriebsmodells: Ein Konto samt Unterkonten wird von der von DIGIMONDO betriebenen Instanz auf eine eigenbetriebene oder anderweitig gehostete niotix-Instanz überführt.
• Übergabe an einen anderen Betreiber: Ein Kundenkonto wechselt den Plattformbetreiber; Benutzer, Rollen und Objektstrukturen sollen unverändert weiterbestehen.
• Zusammenführung von Instanzen: Konten mehrerer Instanzen werden auf einer Zielinstanz gebündelt — bei Bedarf in mehreren aufeinanderfolgenden Migrationsschritten.
• Herauslösen eines Teilbaums: Aus einer Kontenhierarchie wird ein Teilbaum migriert, einzelne Unterkonten werden dabei ausgenommen.

Was migriert wird

Der Umfang ist über eine Tabellenliste im Werkzeug fest definiert. Sie umfasst 74 Tabellenspezifikationen, die sich auf zwei getrennte Snapshot-Arten verteilen:

Inhaltlich abgedeckt sind:

Die Hierarchie-Hilfstabellen für Konten, Zugriffsbereiche und Digitale Zwillinge werden nicht übertragen, sondern beim Import aus den migrierten Datensätzen neu aufgebaut.

Bei Konnektoren wird der Laufzeitzustand beim Export bewusst zurückgesetzt: Die Zuordnung zu einem Ausführungsslot wird entfernt und der Zustand auf Warten gesetzt. Die Konnektoren verbinden sich auf der Zielinstanz also neu.

Gespeicherte Dateien

Mit einem Stammdaten-Snapshot werden auch die Dateien übertragen, auf die migrierte Datensätze verweisen — unter anderem:

• Bilder, Kartensymbole, Grundrissbilder und Anhänge von Digitalen Zwillingen,
• Logos, Favicon und Hintergrundbilder aus dem Design eines Kontos,
• Anhänge von Gateways und Gerätetemplates,
• Bilder und Anhänge von Gerätetreibern,
• Dateien an Tickets,
• Ergebnisdateien von Hintergrundaufgaben.

Verweise auf hochgeladene Dateien an nicht ausdrücklich vorgesehenen Stellen werden zusätzlich erkannt, mitgenommen und im Protokoll gemeldet.

Beide Hälften lesen bzw. schreiben genau einen S3-Bucket (bei Selbstbetrieb typischerweise MinIO), konfiguriert über dieselben GLOBAL_S3_*-Variablen wie die niotix-Instanz selbst (siehe Umgebungsvariablen). Je Datei werden der Inhalt und eine Metadatendatei übertragen; die Metadaten werden dabei auf unkritische Felder reduziert (Name, Typ, Größe, Datum, Zugriffsangaben).

Fehlt eine referenzierte Datei im Quell-Bucket, wird dies im Export gemeldet; die übrigen Dateien werden dennoch übertragen. Auf der Zielinstanz werden die Dateien erst nach Bestätigung der Datenbanktransaktion abgelegt.

Zeitreihendaten

Drei Tabellen mit zeitlich wachsenden Daten werden nicht mit dem Stammdaten-Snapshot, sondern mit einem eigenen Zeitreihen-Snapshot über export --timeseries übertragen:

Der Zeitreihen-Export verwendet dieselbe Kontenauswahl und denselben API-Schlüssel wie der Stammdaten-Export und wird zuletzt ausgeführt — erst wenn alle Stammdaten-Snapshots der betroffenen Konten auf der Zielinstanz importiert sind. Ein Snapshot enthält immer entweder Stammdaten oder Zeitreihen, nie beides. Ablauf und Besonderheiten: Zeitreihen-Export und -Import.

Nicht migrierte Daten

Bewusst nicht übertragen werden:

• Laufzeitzustand der Zielinstanz: Ausführungsslots und Registrierung der Konnektoren, Hintergrundjobs und die Tabellen der Zeitplanung. Diese Daten entstehen auf dem Zielsystem neu.
• Modulregistrierung: Die Module werden auf der Zielinstanz von den einzelnen Diensten selbst neu registriert.
• Aktivierte Integrationen eines Kontos: Die Integrationsschalter in der Modulverwaltung eines Kontos (z. B. IoT-Data-Hub-Influx-Datenbank, Dashboard-Instanz, States-InfluxDB-Datenquelle, IEC 60870-5-104) werden nicht übertragen. Jedes migrierte Konto kommt mit allen Integrationen deaktiviert an; sie sind auf der Zielinstanz erneut zu aktivieren. Die API-Schlüssel der States-InfluxDB-Datenquelle werden ebenfalls nicht übertragen.
• Kurzlebige Anmeldedaten: OAuth2- und OIDC-Tokens, Autorisierungscodes sowie die Protokollierung fehlgeschlagener Anmeldeversuche.
• Berechtigungs-Cache: Die aufgelösten Zugriffsbereiche der Benutzer werden bei der nächsten Anmeldung neu berechnet.
• Instanzweite Grundausstattung: Regeldefinitionen des Systems, Übersetzungen, Schemaverwaltung und Migrationsstände — diese bringt die Zielinstanz selbst mit.
• Messwerthistorie in der InfluxDB: wird mit einem eigenen Werkzeug migriert.
• Der Systembenutzer der Superadministration sowie Kontozuordnungen migrierter Benutzer, die auf Konten außerhalb der Auswahl verweisen.
• Mit --skip ausgelassene Tabellen (siehe Kommando export).

Voraussetzungen

Zielinstanz

• Eine bereits vollständig eingerichtete niotix-Instanz mit eigenem Wurzelkonto, eingespieltem Datenbankschema, abgeschlossenen Migrationen und der instanzweiten Regel-Grundausstattung.
• Genau ein Wurzelkonto. Findet der Import keines oder mehrere, bricht er ab.
• Dieselbe niotix-Version wie die Quellinstanz. Weicht der Migrationsstand des Schemas ab, meldet der Import dies und bricht bei unverträglichen Unterschieden ab.
• Ein erreichbarer S3-Bucket (z. B. MinIO) der Zielinstanz mit Zugangsdaten, sofern der Snapshot Dateien enthält.
• Ein Digital-Twin-Dienst in einer Version, die migrierte Dateien auflösen kann (siehe Gespeicherte Dateien).

Werkzeug und Laufzeitumgebung

• Node.js 22 für den direkten Aufruf aus dem Repository; Abhängigkeiten sind die PostgreSQL-Treiber, das AWS-SDK für den Dateispeicher und eine ZIP-Bibliothek.
• Für den Import beim Betreiber der Zielinstanz alternativ Docker Engine 20.10 oder neuer mit Compose-Plugin sowie Zugriff auf das Container-Image registry.gitlab.com/digimondo-code/niotix/tenant-migrate — entweder aus der Registry oder als übergebenes Image-Archiv.
• Der Image-Tag muss zur Werkzeugversion des Snapshots passen (aktuell 1.2.0). Die Compose-Konfiguration hat bewusst keinen Standard-Tag: Ohne gesetzten Tag verweigert Compose den Start.
• Ein interaktives Terminal für pack, unpack und den Import eines Archivs, da das Archivpasswort ausschließlich über eine verdeckte Eingabeaufforderung abgefragt wird (siehe Archivpasswort). Ein Aufruf aus Skripten, Cron-Jobs oder mit docker compose run -T ist nicht möglich.

Zugänge

• Für den Export ein API-Schlüssel der Quellinstanz mit der Berechtigung all.manage auf jedem ausgewählten Konto oder einem übergeordneten Zugriffsbereich — dieselbe Befugnis, die zum Löschen des Kontos nötig wäre. Details unter Berechtigungen.
• Ein Datenbankbenutzer mit Leserechten auf der Quelldatenbank sowie ein Datenbankbenutzer mit Schreibrechten auf der Zieldatenbank.
• Zugangsdaten zum Dateispeicher jeweils der eigenen Instanz: lesend auf der Quellseite, schreibend auf der Zielseite.
• Netzwerkzugang jeweils nur zur eigenen Datenbank und zum eigenen Dateispeicher. Eine Verbindung zwischen Quell- und Zielumgebung ist nicht erforderlich.

Organisatorisch

• Abgestimmte Konten-IDs einschließlich des festgelegten Ankerkontos.
• Ausreichend Plattenplatz: auf der Quellseite für Snapshot und Archiv, auf der Zielseite für das Archiv, die beim Import temporär entpackte Kopie und das Wachstum von Zieldatenbank und Bucket.
• Ein Archivpasswort, erzeugt mit einem Passwortmanager, sowie zwei getrennte Übertragungswege — einer für das Archiv, ein anderer für das Passwort. Ein Zeitreihen-Snapshot erhält ein eigenes Passwort.
• Ein benannter Ansprechpartner auf Seiten der Zielinstanz, der während des Wartungsfensters erreichbar ist. Vor dem Import ist eine Datenbanksicherung der Zielinstanz zu erstellen.

Ankerkonto

Das Ankerkonto ist das oberste der zu migrierenden Konten. Es ist das einzige Konto, das beim Import unter das Wurzelkonto der Zielinstanz gehängt wird; alle übrigen migrierten Konten behalten ihre Eltern-Kind-Beziehungen innerhalb der Auswahl.

Für den Anker gilt:

• Er muss Teil der migrierten Konten dieses Schritts sein.
• Er muss das oberste Konto der Auswahl sein — ist sein Elternkonto ebenfalls in der Auswahl, bricht der Export ab.
• Er darf nicht mit dem Wurzelkonto der Zielinstanz identisch sein.

Ebenen und Elternbeziehungen werden beim Import anhand des Zielsystems neu berechnet, nicht aus dem Snapshot übernommen.

Einfrieren der Quellkonten

Der Grund dafür liegt in der Arbeitsweise des Exports: Er liest die Tabellen nacheinander und ohne gemeinsamen Transaktions-Snapshot — bei einem fortgesetzten Export sogar über mehrere Prozesse hinweg. Schreibvorgänge, die zwischen dem Lesen zweier Tabellen stattfinden, landen also nur teilweise oder gar nicht im Snapshot.

Das Einfrieren der Quellkonten wird von der Software nicht erzwungen, und ein ausgelassenes Einfrieren fällt auch nicht auf: Es entsteht dennoch ein Snapshot, der die Prüfungen besteht und sich sauber importieren lässt — er ist dann aber in sich inkonsistent, etwa weil ein Gerät migriert wurde, die zugehörige Messreihe aber nicht. Das Einfrieren ist während einer mehrschrittigen Migration über alle Schritte hinweg aufrechtzuerhalten — einschließlich des abschließenden Zeitreihen-Schritts.

Zum Einfrieren gehören:

1. Die API-Schlüssel der betroffenen Konten sperren — mit Ausnahme des für die Migration verwendeten Schlüssels.
2. Datenaufnahme stoppen, also die Konnektoren der betroffenen Konten anhalten. Daten, die während der Migration ohnehin nicht übernommen würden, bleiben so beim Quellsystem stehen und lassen sich nach der Umschaltung gezielt nachziehen.
3. Zeitgesteuerte Aufgaben, Hintergrundverarbeitung und die Alarmauswertung deaktivieren.
4. Benutzer bis zur Umschaltung auf die Zielinstanz von der Quellinstanz fernhalten.

Lässt sich ein Datenfluss nicht anhalten, ist vor der Umschaltung zu klären, wie die in dieser Zeit angefallenen Daten nachgetragen werden — ein zweiter Export ersetzt den ersten nicht, sondern ist ein eigener Migrationsschritt.

Zugriff & Navigation

Die Kontomigration ist kein Bestandteil der niotix-Weboberfläche — es gibt keinen Menüpunkt und keine Ansicht dafür. Sie wird ausschließlich über die Kommandozeile ausgeführt:

• Auf der Quellseite aus dem niotix-Repository heraus über das npm-Skript migrate:tenant bzw. direkt über bin/tenant-migrate.js.
• Auf der Zielseite in der Regel über das bereitgestellte Container-Image, gesteuert per Docker Compose (siehe Beispiel: Import über Docker Compose).

Alle Protokollausgaben — und auch die Passwortabfrage — schreibt das Werkzeug auf stderr; stdout bleibt frei. Eine Protokolldatei legt das Werkzeug nicht selbst an — die Ausgabe ist bei Bedarf mit tee mitzuschreiben, damit die Passwortabfrage sichtbar bleibt.

Ablauf einer Migration

Eine vollständige Migration besteht aus folgenden Schritten:

1. Stammdaten exportieren (export) — bei großen Kontenbäumen in mehreren Schritten.
2. Verpacken (pack) und Archiv sowie Passwort auf getrennten Wegen übergeben.
3. Stammdaten importieren (import) — Schritt für Schritt, Eltern vor Kindern.
4. Zeitreihen exportieren (export --timeseries), verpacken und übergeben — erst, wenn alle Stammdaten-Snapshots importiert sind.
5. Zeitreihen importieren (import).
6. Zielinstanz verifizieren, Integrationen erneut aktivieren und umschalten.

Phasen des Exports

1. Start und Hinweise — gemeldet werden die zurückgestellte Tabelle (Modulregistrierung) und bei einem Stammdaten-Export die Zeitreihentabellen, die stattdessen mit export --timeseries zu exportieren sind; bei --skip außerdem die ausgelassenen Tabellen.
2. Prüfung des API-Schlüssels — Existenz, Typ, Aktivzustand und Gültigkeitsdatum.
3. Auflösung der Auswahl — Kontenmenge, zugehörige Zugriffsbereiche einschließlich der Zwillings-Unterbereiche, Benutzer- und Zwillings-IDs.
4. Rechteprüfung je Konto — für jedes ausgewählte Konto wird all.manage verlangt.
5. Vorabbericht zu den Gerätetreibern (nur Stammdaten) — noch bevor die erste Zeile geschrieben wird zeigt eine Übersicht, welche Gerätetreiber mitgehen, welche geerbt und welche nicht migrierbar sind.
6. Prüfung des Dateispeichers (nur Stammdaten) — der Quell-Bucket muss erreichbar sein, bevor das Snapshot-Verzeichnis angelegt wird.
7. Vorbereitung des Snapshot-Verzeichnisses — Prüfung auf Fortsetzung oder Bereinigung, Schreiben der Metadaten _meta.json inklusive Migrationsstand, Spaltenschema der Quelle und der höchsten IDs der Quelltabellen (Grundlage für den ID-Versatz).
8. Export der Tabellen — Tabelle für Tabelle, gekennzeichnet als [n/70]. Jede Tabelle wird zunächst als .jsonl.partial geschrieben und erst nach vollständigem Durchlauf umbenannt. Nach jeder Tabelle wird _summary.json aktualisiert.
9. Export der gespeicherten Dateien — referenzierte Dateien werden aus dem Bucket in das Unterverzeichnis files/ geladen und in _files.json mit Größe und Prüfsumme verzeichnet.
10. Abschlussprüfung — der fertige Snapshot einschließlich der Dateien wird von der Platte neu gelesen und geprüft; Ergebnis ist _audit.json.
11. Abschlussmeldung mit den Zeilenzahlen je Tabelle und der Anzahl übertragener bzw. fehlender Dateien.

Schlägt die Abschlussprüfung fehl, wird das Verzeichnis in <Verzeichnis>.REJECTED umbenannt und das Werkzeug beendet sich mit Code 3. Ein solcher Snapshot darf weder verpackt, übergeben noch importiert werden.

Verpacken für die Übergabe

pack verpackt einen geprüften Snapshot in ein ZIP-Archiv, in dem jeder Eintrag AES-256-verschlüsselt ist. Vor dem Verpacken prüft das Werkzeug, dass _meta.json vorliegt, keine unvollständigen .partial-Dateien vorhanden sind und _audit.json das Urteil pass trägt und zum Snapshot passt. Nach dem Schreiben wird das Archiv vollständig zurückgelesen und geprüft; anschließend wird das unverschlüsselte Snapshot-Verzeichnis gelöscht.

Jeder Eintrag trägt eine Authentifizierungsprüfsumme. Eine gesonderte Prüfsumme muss daher nicht mitgeschickt werden — ein beschädigtes oder verändertes Archiv wird beim Import erkannt.

Übertragungsweg, Übermittlung des Passworts und die Vernichtung aller Kopien nach erfolgreicher Migration bleiben organisatorische Schritte.

Phasen des Imports

Alle Prüfungen, die ohne Schreibzugriff möglich sind, laufen vor dem Transaktionsbeginn:

1. Archiv öffnen (nur bei ZIP-Archiv) — Passwort abfragen und das Archiv in ein temporäres Verzeichnis entpacken. Das temporäre Verzeichnis wird am Ende in jedem Fall entfernt.
2. _meta.json muss vorhanden und lesbar sein.
3. Prüfbericht _audit.json muss vorliegen, das Urteil pass tragen und zu Kontenmenge, API-Schlüssel und Dateiliste des Snapshots passen.
4. Werkzeugversion des Snapshots muss der Version des ausführenden Werkzeugs entsprechen.
5. Hinweis auf ausgelassene Tabellen, falls der Export mit --skip erfolgte.
6. Prüfung der Dateien — jede Datei im Snapshot gegen _files.json, Erreichbarkeit des Ziel-Buckets und Kollisionsprüfung im Bucket. Dies geschieht noch vor dem Aufbau der Datenbankverbindung.
7. Datenbankverbindung mit Zeitlimits: unbegrenzte Laufzeit für die eigene Arbeit, begrenzte Wartezeit auf fremde Sperren.
8. Migrationsstand von Quelle und Ziel wird verglichen — Abweichungen werden als Warnung gemeldet.
9. Schemavergleich Spalte für Spalte zwischen Snapshot und Zieldatenbank.
10. Wurzelkonto der Zielinstanz ermitteln und gegen das Ankerkonto prüfen.
11. Kollisionsvorprüfung — in Blöcken von 5.000 IDs wird geprüft, ob bereits fremde Datensätze auf den zu vergebenden IDs liegen oder ob eindeutige Werte (z. B. die E-Mail-Adresse eines Benutzers oder der Name eines Kontos) auf der Zielinstanz bereits unter einer anderen ID vergeben sind.
12. ID-Versatz — die ID-Zähler der Zielinstanz werden einmalig um 1.000.000.000 verschoben (siehe ID-Versatz auf der Zielinstanz).

Anschließend beginnt eine einzige Transaktion:

13. Einspielen der Tabellen in festgelegter Reihenfolge; berücksichtigt werden nur Tabellen, für die eine Datei vorliegt.
14. Vollständigkeitsprüfung — gelesene Zeilen gegen die im Export protokollierten Zeilenzahlen.
15. Neuaufbau der Hierarchie-Hilfstabellen, Nachziehen der Sequenzen und — bei --skip — Bericht, ob ein späteres Nachladen der ausgelassenen Zeilen möglich ist.
16. Bestätigung der Transaktion mit einer Übersicht gelesener und eingefügter Zeilen.

Nach der Bestätigung:

17. Ablegen der Dateien im Ziel-Bucket — zuerst der Inhalt, dann die Metadaten je Datei.

Zeitreihen-Export und -Import

Der Zeitreihen-Snapshot ist auf große Datenmengen ausgelegt und arbeitet deshalb anders als der Stammdaten-Snapshot:

Export (export --timeseries)

1. Planung — die Zeilen werden je Digitalem Zwilling bzw. je Regel gezählt und in Pakete von etwa 1.000.000 Zeilen aufgeteilt (MIGRATE_TIMESERIES_CHUNK_ROWS). Der Plan wird in _timeseries.json abgelegt; die Protokollzeile nennt die geplante Zeilenzahl und eignet sich zur Abschätzung von Platzbedarf und Laufzeit.
2. Export in nummerierte Teildateien <tabelle>.00001.jsonl, <tabelle>.00002.jsonl … — gekennzeichnet als [n/3], der Fortschritt wird in Prozent der geplanten Zeilen angezeigt.
3. Fortsetzung mit --resume auf Ebene der einzelnen Pakete.
4. Abschlussprüfung wie beim Stammdaten-Export.

Ein Zeitreihen-Export benötigt keinen Zugriff auf den Dateispeicher und keinen Vorabbericht zu Gerätetreibern. Geotrigger-Einträge zu Zwillingen außerhalb der Auswahl werden mit einer Warnung ausgelassen.

Import

• Zuerst wird geprüft, ob die zugehörigen Digitalen Zwillinge und Regeln auf der Zielinstanz vorhanden sind. Ist keiner davon vorhanden, bricht der Import ab, ohne etwas zu schreiben: Der Stammdaten-Snapshot ist zuerst zu importieren. Fehlen nur einzelne, werden deren Zeilen mit einer Warnung übersprungen.
• Eingespielt wird in einer Transaktion je Teildatei. Bricht der Import ab, bleiben die bereits bestätigten Teildateien erhalten; ein erneuter Aufruf desselben Imports setzt nach der letzten bestätigten Teildatei fort.
• Rückgabewert 5 tritt hier nicht auf, da kein Dateispeicher beteiligt ist.

Schnellstart für den Import

Für den Betreiber der Zielinstanz, der ein übergebenes Archiv einspielt:

1. Wartungsfenster vereinbaren und eine Sicherung der Zieldatenbank erstellen.

2. Das Archiv als snapshot/snapshot.zip neben der Compose-Datei ablegen. Entschlüsseln oder Entpacken ist nicht erforderlich.

3. In der Umgebungsdatei migrate.env die Verbindungsdaten der Zieldatenbank (MIGRATE_DST_URL) und des Dateispeichers (GLOBAL_S3_*) hinterlegen und TENANT_MIGRATE_TAG auf die Werkzeugversion des Snapshots setzen.

4. Import in einem interaktiven Terminal ausführen, das Archivpasswort eingeben und die Ausgabe mitschreiben:

   docker compose run --rm tenant-migrate 2>&1 | tee import.log; echo "exit=${PIPESTATUS[0]}"
   

5. Rückgabewert prüfen: 0 bedeutet, dass die Transaktion bestätigt und alle Dateien abgelegt wurden. 5 bedeutet, dass die Datenbank übernommen ist, aber Dateien fehlen — Zugriff auf den Bucket prüfen und denselben Import erneut ausführen. Jeder andere Wert bedeutet, dass die Daten der Zielinstanz unverändert sind.

6. Zielinstanz verifizieren (siehe Verifikation und Rückabwicklung).

7. Für den Zeitreihen-Snapshot die Schritte 2 bis 6 mit series.zip wiederholen (siehe Beispiel: Zeitreihen nachziehen).

8. Archive und Übertragungskopien sicher vernichten.

Kommandos und Optionen

Das Werkzeug kennt vier Kommandos: export, import, pack und unpack. Positionelle Argumente sind nicht zulässig, unbekannte Optionen führen zum Abbruch. Ein Aufruf ohne Argumente gibt die Kurzhilfe aus und endet mit Rückgabewert 1; --help bzw. -h gibt die Hilfe aus und endet mit 0.

Kommando export

Auslassen von Tabellen mit --skip: Ausgelassene Tabellen werden in _meta.json mit ihrer höchsten Quell-ID vermerkt. Der Import weist darauf hin, dass die Konten ohne diese Zeilen ankommen, und meldet am Ende, ob ein späteres Nachladen möglich ist. Zum Nachladen wird dieselbe Auswahl erneut ohne --skip exportiert und über die bestehende Migration importiert — und zwar bevor die Quellkonten gelöscht werden.

Fortsetzung mit --resume: Die Fortsetzung arbeitet beim Stammdaten-Export auf Tabellenebene, beim Zeitreihen-Export auf Paketebene: Bereits vollständig geschriebene Tabellen bzw. Pakete und Dateien werden nicht erneut abgefragt. Weichen die Rahmenbedingungen der Fortsetzung von denen des ursprünglichen Laufs ab — andere Konten, anderer API-Schlüssel, andere Quelldatenbank, veränderte Tabellenauswahl, geändertes --skip oder --timeseries —, verweigert das Werkzeug die Fortsetzung und benennt das abweichende Merkmal.

Ohne --resume leert der Export ein bereits vorhandenes Snapshot-Verzeichnis in --out. Enthält das Verzeichnis ein Unterverzeichnis files/, aber keine Metadaten eines Snapshots, verweigert das Werkzeug den Export, um keine fremden Daten zu löschen.

Kommando import

Das Ankerkonto, die Kontenauswahl und die Art des Snapshots (Stammdaten oder Zeitreihen) werden dem Snapshot entnommen — beim Import sind sie nicht erneut anzugeben.

Kommandos pack und unpack

unpack wird für den regulären Import nicht benötigt, da import das Archiv direkt liest. Es dient der Einsicht in den Inhalt eines Archivs.

Archivpasswort

Das Archivpasswort wird ausschließlich über eine verdeckte Eingabeaufforderung abgefragt — es gibt bewusst keine Option, keine Umgebungsvariable und keine Datei dafür, damit es weder in Prozesslisten noch in der Shell-Historie oder in Protokollen erscheint.

• Bei pack wird das Passwort zweimal abgefragt („Archive password:" und „Repeat archive password:").
• Es muss mindestens 12 Zeichen lang sein und einen Großbuchstaben, einen Kleinbuchstaben, eine Ziffer und ein Sonderzeichen enthalten. Empfohlen werden 20 oder mehr Zeichen aus einem Passwortmanager.
• Das Passwort ist auf einem anderen Weg als das Archiv zu übermitteln.

Konfiguration

Eine Konfigurationsdatei besitzt das Werkzeug nicht. Gesteuert wird es über Kommandozeilenoptionen und Umgebungsvariablen; alle übrigen Werte sind fest hinterlegt.

Umgebungsvariablen

Feste Werte im Werkzeug

Die Datenbankarbeit erfolgt nicht parallel: Export und Import arbeiten Tabelle für Tabelle über eine einzige Datenbankverbindung. Blockgrößen und Nebenläufigkeit sind — abgesehen von der Teildateigröße der Zeitreihen — nicht konfigurierbar. Wiederholversuche auf Datenbankebene kennt das Werkzeug nicht — die Wiederherstellung erfolgt über --resume beim Export bzw. über einen erneuten Aufruf desselben Imports.

Beispiele

Die folgenden Aufrufe verwenden die Umgebungsvariablen $SRC, $DST und $KEY für Verbindungsdaten und API-Schlüssel. Für den Dateispeicher sind jeweils die GLOBAL_S3_*-Variablen der eigenen Instanz gesetzt.

Beispiel: Konto mit allen Unterkonten

Auf der Quellseite exportieren und verpacken:

export MIGRATE_SRC_URL='postgres://benutzer:passwort@host:5432/niotix'
export MIGRATE_API_KEY='<UUID des all.manage-Schlüssels>'

tenant-migrate export --anchor=23 --mode=recursive --out=./snap/a
tenant-migrate pack --in=./snap/a          # erzeugt ./snap/a.zip, fragt das Passwort ab

Anschließend auf der Zielseite:

export MIGRATE_DST_URL='postgres://benutzer:passwort@host:5432/niotix'

tenant-migrate import --in=./a.zip          # fragt das Passwort ab

Beispiel: Teilbaum ohne einzelne Unterkonten

npm run migrate:tenant -- export --src-url=$SRC --api-key=$KEY \
  --anchor=23 --mode=recursive --exclude=99 --out=./snap/a

Konto 99 wird samt seinem Teilbaum ausgenommen.

Beispiel: Migration in mehreren Schritten

Große Kontenbäume lassen sich in mehreren Schritten migrieren. Der erste Schritt trägt das Ankerkonto, die folgenden hängen weitere Konten an die bereits migrierte Struktur:

npm run migrate:tenant -- export --src-url=$SRC --api-key=$KEY --anchor=23 --out=./snap/step1
npm run migrate:tenant -- pack   --in=./snap/step1
npm run migrate:tenant -- import --dst-url=$DST --in=./snap/step1.zip

npm run migrate:tenant -- export --src-url=$SRC --api-key=$KEY --accounts=24 --out=./snap/step2
npm run migrate:tenant -- pack   --in=./snap/step2
npm run migrate:tenant -- import --dst-url=$DST --in=./snap/step2.zip

Jeder Schritt setzt voraus, dass das Elternkonto bereits auf dem Zielsystem vorhanden ist — andernfalls bricht der Import mit dem Hinweis auf die Reihenfolge Eltern-vor-Kind ab. Das Einfrieren der Quellkonten gilt über alle Schritte hinweg.

Beispiel: Export ohne Aktivitätsprotokolle

Umfangreiche Systemprotokolle lassen sich zunächst auslassen, um das Wartungsfenster kurz zu halten:

npm run migrate:tenant -- export --src-url=$SRC --api-key=$KEY \
  --anchor=23 --mode=recursive --skip=activityLogs --out=./snap/a

Die Konten kommen ohne Systemprotokolle an. Zum Nachladen wird dieselbe Auswahl später ohne --skip exportiert und importiert — vor dem Löschen der Quellkonten.

Beispiel: Zeitreihen nachziehen

Nachdem alle Stammdaten-Snapshots importiert sind, werden die Zeitreihen mit derselben Auswahl exportiert:

npm run migrate:tenant -- export --timeseries --src-url=$SRC --api-key=$KEY \
  --anchor=23 --mode=recursive --out=./snap/series
npm run migrate:tenant -- pack --in=./snap/series      # eigenes Passwort vergeben

Auf der Zielseite über Compose, mit dem Archiv als snapshot/series.zip:

docker compose run --rm tenant-migrate import --in=/snapshot/series.zip

Beispiel: Import über Docker Compose

Die mitgelieferte Compose-Konfiguration führt standardmäßig das Kommando import --in=/snapshot/snapshot.zip aus und bindet das lokale Verzeichnis ./snapshot schreibgeschützt ein. Zu setzen sind der Image-Tag sowie in migrate.env die Verbindungsdaten der Zieldatenbank und des Dateispeichers:

# migrate.env
MIGRATE_DST_URL=postgres://benutzer:passwort@host:5432/niotix
GLOBAL_S3_KEY=…
GLOBAL_S3_SECRET=…
GLOBAL_S3_BUCKET=…
GLOBAL_S3_ENDPOINT=http://host:9000
GLOBAL_S3_FORCEPATHSTYLE=true
GLOBAL_S3_SIGVERSION=v4

export TENANT_MIGRATE_TAG=1.2.0

docker compose run --rm tenant-migrate 2>&1 | tee import.log; echo "exit=${PIPESTATUS[0]}"

Artefakte des Snapshots

Im Verzeichnis aus --out entstehen:

In _meta.json werden keine Benutzer-IDs hinterlegt, sondern nur deren Anzahl und eine Prüfsumme; die Verbindungsangabe zur Quelle wird gekürzt gespeichert.

Prüfungen und Schutzmechanismen

Im Export

• Rechteprüfung je Konto vor dem ersten Schreibvorgang: Fehlt all.manage für ein ausgewähltes Konto, bricht der Export ab und nennt die Konten, für die der Schlüssel zulässig wäre.
• Warnung bei Wurzelbereich: Trägt der API-Schlüssel all.manage auf dem Wurzelbereich der Instanz, kann er jedes Konto exportieren — das Werkzeug weist ausdrücklich darauf hin.
• Abschlussprüfung des geschriebenen Snapshots mit vier Verstoßarten: Datensätze außerhalb der Berechtigung, Datensätze außerhalb der Auswahl, Verweise ins Leere sowie Dateien und Datensätze, die keiner Regel der Tabellenliste zugeordnet werden können. Das Verzeichnis files/ wird dabei wie eine Tabelle geprüft.
• Vorabbericht zu Gerätetreibern: gemeldet werden fehlende Treiber, Treiber fremder Konten, die nicht mitgehen können, sowie geerbte, aber nicht öffentlich sichtbare Treiber, die auf dem Zielsystem an das Wurzelkonto gehängt werden und dort nur mit entsprechender Berechtigung auflösbar sind.
• Prüfung vor dem Verpacken: pack verpackt nur vollständige Snapshots mit bestandener Abschlussprüfung und prüft das fertige Archiv durch erneutes Lesen.

Im Import

• Archivprüfung: Ein falsches Passwort, ein beschädigtes Archiv oder unverschlüsselte bzw. unzulässige Einträge führen zum Abbruch, bevor etwas geschrieben wird.
• Prüfberichtssperre: Ohne _audit.json mit dem Urteil pass wird nicht importiert. Der Bericht muss zur Kontenmenge, zum API-Schlüssel und zur Dateiliste des Snapshots passen — ein von anderswo hineinkopierter Prüfbericht wird erkannt.
• Versionssperre zwischen Snapshot und Werkzeug.
• Schemavergleich: Fehlt eine Spalte des Snapshots auf dem Ziel, fehlt eine ganze Tabelle oder besitzt das Ziel eine neue Pflichtspalte ohne Standardwert, bricht der Import ab. Zusätzliche Zielspalten mit Standardwert sowie abweichende Spaltentypen führen nur zu einer Warnung.
• Kollisionsvorprüfung: Liegt auf einer zu vergebenden ID bereits ein anderer Datensatz oder ist ein eindeutiger Wert — etwa die E-Mail-Adresse eines Benutzers oder ein Kontoname — auf der Zielinstanz bereits unter einer anderen ID vergeben, bricht der Import unter Angabe von Tabelle, ID bzw. Wert ab.
• Prüfung der Dateien: Jede Datei wird gegen Größe und Prüfsumme aus _files.json geprüft. Liegt im Ziel-Bucket unter derselben Kennung bereits eine andere Datei, bricht der Import ab, bevor etwas geschrieben wird. Metadaten mit nicht zulässigen Feldern werden zurückgewiesen.
• Vollständigkeitsprüfung gegen _summary.json. Verglichen werden gelesene, nicht eingefügte Zeilen — damit ein zweiter Aufruf desselben Imports nicht als unvollständig gilt.
• Genau eine Hauptkontozuordnung je migriertem Benutzer wird erzwungen.

ID-Versatz auf der Zielinstanz

Da die Zielinstanz während und zwischen den Migrationsschritten in Betrieb sein kann, könnten neu angelegte Objekte IDs belegen, die ein späterer Migrationsschritt benötigt. Um das auszuschließen, verschiebt der Import vor Transaktionsbeginn die ID-Zähler der Zielinstanz einmalig auf einen Wert oberhalb von 1.000.000.000 — über die höchste vorhandene und die höchste im Quellsystem vergebene ID hinaus.

• Der Versatz erfolgt einmal je Zielinstanz; ein bereits versetzter Zähler bleibt unverändert.
• Er betrifft alle 40 berücksichtigten Zähler, auch solche von Tabellen, die im Snapshot nicht vorkommen.
• Kann eine ID-Spalte den Wert technisch nicht aufnehmen, wird der Versatz für diese Tabelle mit einer Warnung ausgelassen.
• Der Versatz ist nicht Teil der Transaktion und bleibt nach einem abgebrochenen Import bestehen. Das ist unschädlich: Ein erneuter Aufruf erkennt ihn.

Nach der Migration neu angelegte Konten, Digitale Zwillinge, Konnektoren usw. erhalten daher zehnstellige IDs, die auch in URLs der Weboberfläche erscheinen. Dies ist erwartetes Verhalten.

Verifikation und Rückabwicklung

Nach dem Import zu prüfen

1. Zeilenzahlen auf der Zielinstanz gegen _summary.json abgleichen.
2. Einordnung des Ankerkontos und die Hierarchieebenen der migrierten Konten kontrollieren.
3. Stichproben auf erhaltene IDs bei Konten, Benutzern, Rollen, Digitalen Zwillingen und Virtuellen Geräten.
4. Anmeldung eines realen Benutzers auf der Zielinstanz durchführen.
5. Auflösung der Gerätetreiber prüfen — insbesondere bei geerbten Treibern, die an das Wurzelkonto gehängt wurden.
6. Dashboards öffnen und auf vollständige Darstellung prüfen.
7. Gespeicherte Dateien prüfen — etwa Zwillingsbilder, Kontologos und Anhänge öffnen. Die Anzahl der Objekte im Ziel-Bucket muss um das Doppelte der übertragenen Dateien gewachsen sein (Inhalt und Metadaten).
8. Neuanlage testen — etwa ein neues Konto, einen Digitalen Zwilling oder einen Konnektor. Die neue ID muss oberhalb von 1.000.000.000 liegen; eine ID knapp über den migrierten IDs bedeutet, dass der ID-Versatz nicht gegriffen hat.
9. Verbindungsaufbau der Konnektoren auf der Zielinstanz kontrollieren.
10. Integrationen in der Modulverwaltung der migrierten Konten erneut aktivieren — sie kommen deaktiviert an.
11. Tickets öffnen und prüfen, dass Tickettyp und -priorität angezeigt werden.
12. Die Verknüpfungen der Zwillingszustands-Aggregate gegenprüfen: Ein Teil dieser Datensätze entsteht auf dem Zielsystem über einen Datenbank-Trigger neu und wird in der Import-Übersicht ausdrücklich zur manuellen Prüfung ausgewiesen.
13. Nach dem Zeitreihen-Import: Zustandsverlauf eines Digitalen Zwillings und Ausführungsprotokoll einer Regel öffnen; Zeilenzahlen gegen _summary.json abgleichen, abzüglich übersprungener Zwillinge bzw. Regeln.

Rückabwicklung

Ein Kommando zum Zurückrollen existiert nicht — der Schutz liegt in der Atomarität des Datenbankimports.

Berechtigungen

Auf der Quellinstanz autorisiert ein API-Schlüssel den Export. Er muss:

• als API-Schlüssel-Benutzer angelegt und aktiv sein,
• innerhalb seines Gültigkeitsdatums liegen und
• die Berechtigung all.manage auf dem Wurzelbereich jedes ausgewählten Kontos oder einem übergeordneten Zugriffsbereich tragen.

Damit entspricht die verlangte Befugnis genau der, die zum Löschen des Kontos über die API nötig wäre. Ein persönlicher Anmeldezugang kann einen Export nicht autorisieren. Ein etwaiges Abfragekontingent des Schlüssels wird bewusst nicht ausgewertet. Grundlagen zum Rechtemodell: Berechtigungen und Berechtigungskonzept.

Datenbankrechte

Dateispeicher

Fehlermeldungen & Troubleshooting

Die Meldungen des Werkzeugs sind englischsprachig. Der Rückgabewert ordnet die Fehlerklasse zu:

„Refusing to export: the supplied x-api-key does not hold all.manage on account(s) …" Ursache: Der API-Schlüssel besitzt nicht auf allen ausgewählten Konten die Berechtigung all.manage. Die Meldung nennt die Konten, für die der Schlüssel zulässig wäre. Lösung: Auswahl auf diese Konten einschränken oder einen Schlüssel mit ausreichender Berechtigung auf einem übergeordneten Zugriffsbereich verwenden.

„The –api-key value is not a UUID" / „No user exists on the source for the supplied –api-key" / „…belongs to a regular user, not an api-key user" Ursache: Es wurde keine gültige Schlüssel-Kennung übergeben oder es handelt sich um einen persönlichen Zugang. Lösung: Die Kennung des API-Schlüssel-Benutzers der Quellinstanz verwenden.

„Anchor tenant N is not among the migrated accounts" / „Anchor tenant N has parent M, which is also in this selection" Ursache: Das Ankerkonto gehört nicht zur Auswahl oder ist nicht deren oberstes Konto. Lösung: Anker gemäß Ankerkonto korrigieren.

„–exclude is only valid with –mode=recursive" Ursache: --exclude wurde ohne rekursiven Modus verwendet. Lösung: --mode=recursive ergänzen oder den Ausschluss entfernen.

„–skip names “…”, which the manifest does not mark optional" Ursache: Die genannte Tabelle darf nicht ausgelassen werden oder gehört zur jeweils anderen Snapshot-Art. Die Meldung nennt die zulässigen Tabellen. Lösung: Nur activityLogs (Stammdaten) bzw. dtwin-rule-executions und dtwin-rules-geotrigger-history (Zeitreihen) angeben.

„Refusing to –resume: this export does not match the snapshot in –out" Ursache: Die Rahmenbedingungen weichen vom ursprünglichen Lauf ab; die Meldung nennt das abweichende Merkmal. Lösung: Ursprüngliche Parameter verwenden, oder --resume weglassen und neu exportieren.

„Refusing to export into …: it holds a files/ directory but no _meta.json or _files.json" Ursache: Das Verzeichnis in --out enthält Daten, die nicht von diesem Werkzeug stammen. Lösung: Ein leeres oder neues Verzeichnis angeben.

„… needs access to the file store, but GLOBAL_S3_… is/are not set" Ursache: Die Zugangsdaten zum Dateispeicher fehlen. Lösung: Die GLOBAL_S3_*-Werte der niotix-Instanz übernehmen, gegen die die jeweilige Hälfte läuft.

Dateispeicher nicht erreichbar Ursache: Der Bucket ist unter den angegebenen Zugangsdaten nicht erreichbar — häufig, weil der Container Dienstnamen wie minio nicht auflösen kann. Lösung: Erreichbare Adresse eintragen oder den Container dem niotix-Netzwerk beitreten lassen (siehe Beispiel: Import über Docker Compose).

Im Export fehlende Dateien Ursache: Eine Datei, auf die ein Datensatz verweist, liegt nicht im Bucket der Quellinstanz — typischerweise, weil sie nach dem letzten Neustart der Quellinstanz noch nicht in den aktuellen Dateispeicher übernommen wurde. Lösung: Mit DIGIMONDO klären; nach einem Neustart der Quellinstanz den Export mit --resume fortsetzen.

„Snapshot audit FAILED — … quarantined to .REJECTED" Ursache: Die Abschlussprüfung hat Datensätze gefunden, zu deren Export der Schlüssel nicht befugt war, Datensätze außerhalb der Auswahl, Verweise ins Leere oder nicht zuordenbare Dateien. Lösung: _audit.json im zurückgewiesenen Verzeichnis auswerten und den Auslöser klären. Ein solcher Snapshot darf nicht verpackt, übergeben oder importiert werden.

pack meldet einen unvollständigen Snapshot Ursache: Im Verzeichnis liegen noch .partial-Dateien. Lösung: Den Export mit --resume abschließen und erneut verpacken.

„The archive password is typed at a prompt, and this command has no terminal to ask on" Ursache: Das Kommando wurde ohne interaktives Terminal ausgeführt, etwa aus einem Skript oder mit docker compose run -T. Lösung: Aus einer interaktiven Shell ausführen; in Docker mit docker compose run ohne -T bzw. docker run -it.

„The archive password must contain at least 12 characters, …" / „The two passwords do not match" Ursache: Das Passwort erfüllt die Mindestanforderungen nicht bzw. die Wiederholung weicht ab. Lösung: Ein ausreichend starkes Passwort aus einem Passwortmanager verwenden. Es wurde nichts geschrieben.

„Wrong password for …" Ursache: Das eingegebene Passwort passt nicht zum Archiv. Lösung: Passwort über den vereinbarten Kanal erneut abgleichen.

Beschädigtes oder zurückgewiesenes Archiv (Rückgabewert 3) Ursache: Das Archiv wurde bei der Übertragung beschädigt oder verändert. Lösung: Archiv erneut übertragen und den Import wiederholen.

„No _audit.json in " / „…records verdict … with N violation(s)" / „…the audit does not belong to this snapshot" Ursache: Der Snapshot wurde nie geprüft, hat die Prüfung nicht bestanden, oder Prüfbericht und Metadaten bzw. Dateiliste passen nicht zusammen. Lösung: Export erneut ausführen; einen nicht bestandenen Snapshot nicht importieren.

„Refusing to commit: the snapshot does not hold every row the export wrote" Ursache: Der Snapshot ist unvollständig. Lösung: Archiv erneut übertragen und den Import wiederholen.

„Refusing to import: snapshot was written by tenant-migrate X, this is 1.2.0" Ursache: Snapshot und Werkzeug stammen aus unterschiedlichen Versionen und können unterschiedliche Spalten erwarten. Lösung: Das Image mit dem passenden Tag verwenden. Die Umgehung über MIGRATE_ALLOW_VERSION_SKEW=1 ist nur nach Abstimmung mit DIGIMONDO vorgesehen.

„Refusing to import: the target schema cannot accept this snapshot" Ursache: Zielschema und Snapshot passen nicht zusammen — fehlende Spalte, fehlende Tabelle oder neue Pflichtspalte ohne Standardwert. Es wurde nichts geschrieben. Lösung: Die Zielinstanz auf denselben Migrationsstand wie die Quelle bringen und denselben Import erneut ausführen.

„Could not find a target root tenant" / „Found N candidate root tenants on target" Ursache: Auf der Zielinstanz existiert kein oder mehr als ein Wurzelkonto. Lösung: Zielinstanz korrekt bereitstellen; der Import benötigt genau ein Wurzelkonto.

„Refusing to import: N collision(s) on — a different record already occupies the id or holds the unique value" Ursache: Auf einer zu vergebenden ID liegt bereits ein anderer Datensatz („ID collision on …"), ein eindeutiger Wert wie eine E-Mail-Adresse oder ein Kontoname ist auf der Zielinstanz bereits vergeben („Unique collision on …"), oder im Ziel-Bucket liegt unter derselben Kennung eine andere Datei. Lösung: Ursache mit DIGIMONDO klären — etwa den doppelten Benutzer oder das gleichnamige Konto auf der Zielinstanz bereinigen. Es wurde nichts geschrieben.

„ id=N: parent M is not present on the target … Migrate the parent first" Ursache: Bei einer mehrschrittigen Migration fehlt das Elternkonto auf dem Zielsystem. Lösung: Zuerst den Schritt mit dem Elternkonto importieren.

„… none of the N … row(s) this snapshot holds data for is on the target" Ursache: Ein Zeitreihen-Snapshot wurde vor dem zugehörigen Stammdaten-Snapshot importiert. Lösung: Zuerst den Stammdaten-Snapshot importieren, dann denselben Zeitreihen-Import erneut ausführen. Es wurde nichts geschrieben.

„The DATABASE IMPORT IS COMMITTED — the accounts are on the target. Only these files are not." (Rückgabewert 5) Ursache: Nach der Bestätigung der Transaktion konnten nicht alle Dateien im Ziel-Bucket abgelegt werden. Lösung: Schreibzugriff auf den Bucket prüfen und denselben Import erneut ausführen; bereits vorhandene Zeilen und Dateien werden übersprungen.

„permission denied" beim Lesen von /snapshot Ursache: Der Container läuft unprivilegiert und darf das eingebundene Verzeichnis nicht lesen. Lösung: Leserechte für das Snapshot-Verzeichnis setzen, etwa mit chmod -R a+rX snapshot.

Compose startet nicht und verlangt einen Tag Ursache: TENANT_MIGRATE_TAG ist nicht gesetzt; einen Standardwert gibt es bewusst nicht. Lösung: Den zur Werkzeugversion des Snapshots passenden Tag setzen.

Kein Platz beim Entpacken des Archivs Ursache: Der Import entpackt das Archiv temporär in das Systemverzeichnis für temporäre Dateien des Containers, das auf dem Datenträger der Docker-Daten liegt. Lösung: TMPDIR auf ein eingebundenes Volume mit ausreichend Platz zeigen lassen.

Der Import läuft länger als das Wartungsfenster Ursache: Ein Teilimport der Stammdaten existiert nicht — die Transaktion läuft bis zum Ende oder wird zurückgerollt. Lösung: Fall eskalieren und mit DIGIMONDO ein Vorgehen abstimmen; die Daten der Zielinstanz bleiben bei einem Abbruch unverändert. Umfangreiche Systemprotokolle lassen sich mit --skip=activityLogs zunächst auslassen.

Leistung, Limits & Betrieb

Betriebshinweise:

• Sperrverhalten: Der Import wartet begrenzt auf konkurrierende Sperren. Der Neuaufbau der Hierarchie-Hilfstabellen ist auf die migrierten Datensätze beschränkt und sperrt gleichzeitige Lesezugriffe nicht aus.
• Betrieb der Zielinstanz: Dank des ID-Versatzes darf die Zielinstanz zwischen den Migrationsschritten genutzt werden, ohne dass neu angelegte Objekte mit später migrierten IDs kollidieren.
• Kein Probelauf: Zum Erproben ist der Export gegen eine Kopie der Quelldatenbank auszuführen.
• Kein Teilimport der Stammdaten: Ein Stammdaten-Import ist entweder vollständig bestätigt oder vollständig zurückgerollt. Das Wartungsfenster ist entsprechend zu bemessen.
• Keine Vorabprüfung des Plattenplatzes: Ein volles Dateisystem während des Exports oder beim Entpacken äußert sich lediglich als allgemeiner Abbruch beim Schreiben.
• Abschätzung der Zeitreihen: Die Planungszeile des Zeitreihen-Exports nennt die geplante Zeilenzahl und eignet sich zur Abschätzung von Platzbedarf und Laufzeit.

Verwandte Seiten

• Konten
• Berechtigungen
• Berechtigungskonzept
• Datenmodell und Definitionen
• Konnektoren
• Systemprotokolle