Clone
1
Reference MIGRATION_WORKFLOW.de
Patrick Gniza edited this page 2026-08-17 10:48:39 +02:00

Deutsch | English

Migrationsworkflow

Dieses Dokument beschreibt den vorgesehenen Workflow zur Migration einer vorhandenen Romexis-Installation in den Docker-basierten Romexis-Server-Stack.

┌──────────────────────────────┐ │ Existing Romexis Server │ └──────────────┬───────────────┘ │ │ Romexis Migration Client │ ▼ SFTP / REST API │ ▼ ┌──────────────────────────────┐ │ Romexis Migration Service │ │ │ │ • Migration Jobs │ │ • Upload Validation │ │ • Restore Workflow │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Romexis Docker Container │ │ SQL Server │ │ Images │ │ Ergodata │ └──────────────────────────────┘



Aktualisierter detaillierter Workflow

created
  -> database_uploaded
  -> database_restored
  -> upload_complete
  -> validated
  -> restored
  -> completed

Endzustände:

completed
cancelled
failed

Manueller Browser-Workflow

  1. Migrationsjob in der Web-UI erstellen.
  2. Datenbanksicherung im Browser hochladen.
  3. Der Dienst erstellt automatisch manifest.json.
  4. Datenbankwiederherstellung auslösen.
  5. Dateiverzeichnisse über SFTP hochladen.
  6. Abschluss des Uploads bestätigen.
  7. Upload validieren.
  8. Wiederherstellung ausführen.
  9. Migration abschließen und SFTP-Zugriff entfernen.

Windows-Client-Workflow

  1. Romexis-Installation erkennen.
  2. SQL-Server-Konfiguration erkennen.
  3. Datenverzeichnisse erkennen.
  4. Migrationsjob erstellen oder verwenden.
  5. Datenbanksicherung erstellen.
  6. Daten über rclone/SFTP hochladen.
  7. API-Endpunkte aufrufen, um den Migrationsworkflow voranzubringen.
  8. Logs und Wiederherstellungsstatus anzeigen.

Neustart nach der Wiederherstellung

Der Migrationsdienst und der Romexis-Container kommunizieren über:

/data/romexis_images/.romexis_restart_state

Der Migrationsdienst schreibt eine ausstehende Neustartanforderung. Der Romexis-Entrypoint stoppt und startet den Romexis-Prozess neu, schreibt den endgültigen Status und der Migrationsdienst entfernt die Zustandsdatei.

Phase 1: Vorbereitung auf dem Quellsystem

Das Quellsystem ist üblicherweise ein vorhandener Windows-basierter Romexis-Server.

Erforderliche Daten:

  • SQL-Server-Datenbanksicherung (.bak)
  • Romexis-Bildverzeichnis
  • Romexis-Ergo-Datenverzeichnis
  • optionales Cache-Verzeichnis

Das Cache-Verzeichnis kann normalerweise ausgelassen werden, da es neu erzeugt werden kann.


Phase 2: Migrationsjob erstellen

Ein Migrationsjob wird in der Web-UI erstellt.

Der Dienst erzeugt:

  • Migrations-ID
  • SFTP-Benutzername
  • SFTP-Passwort
  • Upload-Pfad

Phase 3: Daten hochladen

Empfohlene Werkzeuge:

  • rclone über SFTP
  • WinSCP
  • FileZilla
  • OpenSSH SFTP

Beispiel mit rclone:

rclone copy ./migration-data sftp:upload \
  --transfers 8 \
  --checkers 16 \
  --progress

Phase 4: Upload validieren

Der Migrationsdienst validiert:

  • Manifest ist vorhanden
  • SQL-Sicherung ist vorhanden
  • Bildverzeichnis ist vorhanden
  • Ergo-Verzeichnis ist vorhanden

Spätere Versionen sollten ergänzen:

  • Prüfsummenvalidierung
  • Vergleich der Dateianzahl
  • Validierung der erwarteten Größe

Phase 5: Wiederherstellung

Der Wiederherstellungsprozess führt aus oder koordiniert:

  1. Romexis-Server-Container stoppen
  2. SQL-Server-Datenbanksicherung wiederherstellen
  3. Datenverzeichnisse in die Ziel-Volumes kopieren
  4. Eigentümer und Berechtigungen korrigieren
  5. Romexis-Server-Container starten
  6. abschließende Validierung ausführen

Der aktuelle Workflow verwendet explizite Zustandsübergänge und hält die Neustartkoordination über die gemeinsame Zustandsdatei getrennt.