Imixs/office-alexander-logistics
3
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
office-alexander-logistics/backup/README.md

9.3 KiB
Raw Blame History

Eigenes Backup-System (Backup-Mirror)

Architektur, Einrichtung und Disaster-Recovery-Konzept

1. Idee und Architektur

1.1 Ausgangslage

Imixs-Office-Workflow wird von uns als eine transaktionale, hochverfügbare Geschäftsprozessmanagement-Suite betrieben. Die Basis ist ein Open Source Kernel, der frei zugänglich ist (https://github.com/imixs/). Unabhängig vom gewählten Betriebsmodell (SaaS, Public Cloud, Private Cloud, On Premise) sind und bleiben Sie Eigentümer Ihrer Geschäftsdaten. Über den Backup-Service haben Sie die Möglichkeit, jederzeit eigenständig auf eine vollständige Kopie Ihrer Daten zuzugreifen – unabhängig davon, wie und wo Ihre Instanz aktuell betrieben wird.

1.2 Architektur – Own your Data

Auch wenn wir den Betrieb Ihrer Instanz übernehmen, bedeutet das nicht, dass Sie von uns abhängig sind. Über den Backup-Mirror betreiben Sie bei sich einen eigenen, unabhängigen Backup-Dienst. Dieser Dienst wird von Ihnen selbst eingerichtet, verwaltet und überwacht und läuft vollständig autark – wir müssen ihn technisch weder kennen noch verwalten. Dadurch gilt:

Sie verfügen über eine eigenständige, vollständige Kopie Ihrer Geschäftsdaten – unabhängig von unserer Infrastruktur. Mit dieser Kopie kann Ihr System bei Bedarf komplett neu aufgebaut werden.

Das ist ein bewusst einfaches und robustes Prinzip: Es kommt nicht darauf an, wo Ihre Daten zusätzlich liegen, sondern wer die Kontrolle über diesen zusätzlichen Sicherungsort hat. Nur wenn diese Kontrolle bei Ihnen liegt, sind Sie wirklich unabhängig.

1.3 Wie es funktioniert

Technisch basiert das Konzept auf dem Open-Source-Projekt Imixs-Archive, konkret auf dem Baustein Imixs-Archive-Backup. Der Ablauf im Überblick:

  1. Bei jeder Änderung an einem Geschäftsvorgang erzeugt Ihre Workflow-Instanz automatisch einen unveränderlichen Snapshot (eine vollständige Kopie des Vorgangs inkl. aller angehängten Dokumente).
  2. Diese Snapshots werden über die REST-Schnittstelle Ihrer Workflow-Instanz bereitgestellt.
  3. Ein bei Ihnen installierter Backup-Dienst (siehe Abschnitt 2) ruft diese Snapshots eigenständig ab und speichert sie auf einem Speicherort Ihrer Wahl (z. B. eigener FTP-/Storage-Server).

Wichtig: Die Verbindung erfolgt von Ihrem System zu unserer Workflow-Instanz („Pull-Prinzip"). Sie benötigen dafür lediglich einen Netzwerkzugriff auf die REST-Schnittstelle Ihrer Instanz – wir müssen keinen Zugriff auf Ihre Infrastruktur haben und erhalten auch keinen.

2. Technische Einrichtung

Der Backup-Dienst kann als Docker-Container in unterschiedlichen Umgebungen betrieben werden:

  • Local: lokal über Docker oder Docker Compose,
  • Private Cloud: in einer Private Cloud (z.b. Kubernetes, OpenShift)
  • Public Cloud: in einer Public Cloud Umgebung (z.b. AWS, Microsoft Azure)

2.1 Voraussetzungen

  • Eine eigene Server- bzw. Container-Umgebung (Docker) auf Ihrer Seite
  • Ein eigener Speicherort für die Backup-Daten (z. B. FTP-Storage, NAS mit FTP-Anbindung)
  • Eine sogenannte Mirror-ID, die wir Ihnen bereitstellen

2.2 Mirror-ID anfragen

Die Mirror-ID ist eine organisatorische Kennung, mit der wir Ihre eigene Backup-Verbindung für Ihre Instanz freischalten. Sie ist kein Sicherheitsmerkmal im engeren Sinn, sondern eine Vereinbarung zwischen uns: „Kunde X betreibt ein eigenes Backup." Bitte fordern Sie diese ID formlos bei uns an.

2.3 Backup-Nutzer in Ihrer eigenen Instanz anlegen

Ein zentraler Punkt für die Autarkie des Systems: Sie legen den technischen Benutzer für den Backup-Zugriff selbst in Ihrer Imixs-Instanz an. Dieser Nutzer gehört ausschließlich Ihnen – wir kennen weder das Passwort noch verwalten wir dieses Konto. Vergeben Sie dem Nutzer ausreichende Leserechte, damit er alle relevanten Vorgänge und Dokumente sichern kann.

2.4 Docker-Compose Beispielkonfiguration

Das folgende Beispiel zeigt eine Docker Compose Konfiguraiton für den Betrieb des Backup-Dienstes:

version: "3.6"
services:
  backup:
    image: imixs/imixs-archive-backup:latest
    environment:
      TZ: "Europe/Berlin"
      WORKFLOW_SERVICE_ENDPOINT: "https://<ihre-instanz>.office-workflow.de/api/"
      WORKFLOW_SERVICE_USER: "<ihr-backup-nutzer>"
      WORKFLOW_SERVICE_PASSWORD: "<ihr-passwort>"
      WORKFLOW_SERVICE_AUTHMETHOD: "form"
      BACKUP_FTP_HOST: "<ihr-storage-host>"
      BACKUP_FTP_PATH: "<ihr-zielverzeichnis>"
      BACKUP_FTP_PORT: "21"
      BACKUP_FTP_USER: "<ihr-ftp-nutzer>"
      BACKUP_FTP_PASSWORD: "<ihr-ftp-passwort>"
      BACKUP_MIRROR_ID: "<ihre-mirror-id>"
    ports:
      - "8084:8080"
      - "9990:9990"

Erläuterung der wichtigsten Parameter:

Parameter Bedeutung
WORKFLOW_SERVICE_ENDPOINT Die REST-API-Adresse Ihrer bei uns gehosteten Workflow-Instanz
WORKFLOW_SERVICE_USER/PASSWORD Der von Ihnen selbst angelegte Backup-Nutzer
BACKUP_FTP_* Ihr eigener Speicherort für die Backup-Daten
BACKUP_MIRROR_ID Die von uns bereitgestellte Freischalt-ID

Nach dem Start prüft der Dienst regelmäßig auf neue zu sichernde Vorgänge und überträgt diese automatisch auf Ihren Speicherort.

2.5 Monitoring des eigenen Backup-Dienstes

Da der Dienst vollständig in Ihrer Verantwortung läuft, sollten Sie ihn aktiv überwachen. Ein einfacher Ping-Check zeigt zwar, dass der Container erreichbar ist – sagt aber nichts darüber aus, ob der Dienst tatsächlich funktionsfähig ist und Backups erfolgreich durchführt.

Der Imixs-Archive-Backup-Service stellt hierfür standardisierte MicroProfile-Endpunkte mit, die auf Port 9990 bereitgestellt werden:

Endpunkt Beschreibung
/health Liefert den Health-Status des Dienstes nach dem MicroProfile-Health-Standard – inklusive Readiness (ist der Dienst betriebsbereit, z. B. Verbindung zur Workflow-API und zum FTP-Storage vorhanden?) und Liveness (läuft der Prozess korrekt?)
/metrics Liefert Betriebskennzahlen im MicroProfile-Metrics-Format (Prometheus-kompatibel), z. B. Anzahl verarbeiteter Backups, Fehlerzähler, Laufzeiten

Damit lässt sich der Dienst professionell überwachen:

  • Health-Checks binden Sie direkt in gängige Monitoring-Systeme ein (z. B. Kubernetes Liveness-/Readiness-Probes, Uptime-Kuma, Nagios, Icinga) und erkennen so nicht nur einen abgestürzten Container, sondern auch einen Dienst, der zwar läuft, aber z. B. keine Verbindung mehr zu Ihrer Workflow-Instanz oder zum FTP-Ziel herstellen kann.
  • Metrics lassen sich direkt von Prometheus abgegriffen und in Grafana visualisiert werden – so erkennen Sie auf einen Blick, ob regelmäßig Backups durchgeführt werden, oder ob z. B. die Fehlerrate ansteigt.

Voraussetzung: Sie müssen Port 9990 in Ihrer Docker-Umgebung entsprechend freigeben bzw. mappen, damit Ihr Monitoring-System auf die Endpunkte zugreifen kann (siehe Port-Mapping im Beispiel aus Abschnitt 2.4).

Ein Backup, das unbemerkt seit Wochen nicht mehr funktioniert, bietet keinen Schutz. Die Überwachung über Health- und Metrics-Endpunkte ist daher ein integraler Bestandteil des Konzepts, nicht optional.

3. Notfall- und Wiederherstellungsfall (Disaster Recovery)

Im Falle eines Disaster-Recovery-Prozesses stellen Sie uns Ihr Backup zur Verfügung, damit Ihr System auf dessen Basis wiederhergestellt werden kann. Dieser Abschnitt beschreibt das Vorgehen nur in Stichpunkten. Die vollständige technische Dokumentation der Imixs-Workflow-Architektur ist Open Source und öffentlich einsehbar unter github.com/imixs.

Grundprinzip der Wiederherstellung:

  • Ihre gesicherten Snapshot-Daten liegen vollständig und unverändert in Ihrem eigenen Speicher (FTP/Storage) vor.
  • Diese Daten liegen in einem offenen, plattformunabhängigen XML-Format vor und sind nicht an unsere konkrete Infrastruktur gebunden.
  • Auf Basis dieser Daten kann eine neue Imixs-Workflow-Instanz (bei Ihnen oder bei einem anderen Dienstleister) aufgesetzt werden.
  • Über die Restore-Funktion der Imixs-Archive-Komponenten werden die Snapshots in die neue Instanz zurückgespielt – jeder Geschäftsvorgang wird dabei inklusive seiner Historie und aller Dokumente wiederhergestellt.

Wichtige Stichpunkte für den Ernstfall:

  • Backup-Daten sind vollständig bei Ihnen vorhanden → keine Abhängigkeit von uns
  • Wiederherstellung erfordert eine lauffähige Imixs-Workflow-Umgebung (Open Source, frei verfügbar)
  • Die technische Vorgehensweise zum Restore ist Teil der öffentlichen Imixs-Archive-Dokumentation
  • Wir unterstützen Sie im Ernstfall selbstverständlich gerne beim Wiederaufbau – diese Unterstützung ist jedoch keine Voraussetzung, da die Daten und das Wiederherstellungsverfahren vollständig unabhängig von uns nutzbar sind

4. Zusammenfassung

Mit dem Backup-Mirror bleiben Sie jederzeit Eigentümer Ihrer Geschäftsdaten – unabhängig davon, wie und wo Ihre Instanz betrieben wird. Sie richten den Dienst selbst ein, verwalten ihn eigenständig und behalten so die volle Kontrolle über Ihre zusätzliche Datenkopie. Genau diese Unabhängigkeit ist es, die Ihnen im Bedarfsfall den vollständigen Wiederaufbau Ihres Systems ermöglicht.

Bei Fragen zur Einrichtung oder zur Anforderung Ihrer Mirror-ID kontaktieren Sie uns gerne.