office-alexander-logistics/backup/README.md

204 lines
No EOL
9.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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/](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](https://github.com/imixs/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:
```yaml
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](https://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.