Zum Inhalt

Backup und Restore

1. Ziel und Einordnung

Dieses Dokument beschreibt das Backup- und Restore-Konzept der ESW-Plattform. Es dient als technische Grundlage für Betrieb, Weiterentwicklung und Qualitätssicherung.

Das Konzept stellt sicher, dass:

  • Daten strukturiert und vollständig gesichert werden
  • Backups unabhängig vom Ursprungssystem nutzbar sind
  • Restore-Prozesse nachvollziehbar und testbar sind
  • Ausfallzeiten minimiert werden

Das Dokument richtet sich an:

  • Entwicklerinnen und Entwickler
  • Betriebsverantwortliche (DevOps / Administration)
  • technisch versierte Projektbeteiligte

2. Grundprinzipien

Das Backup- und Restore-Konzept folgt vier zentralen Prinzipien:

2.1 Mehrschichtige Sicherung

Jeder Dienst wird auf mehreren Ebenen gesichert:

  • Applikationsdaten (z. B. native Backups)
  • Konfigurationsdaten
  • Metadaten zur Laufzeitumgebung
  • optionale Zusatzartefakte

Ziel ist es, sowohl Datenverlust als auch Konfigurationsverlust zu vermeiden.

2.2 Integrität und Prüfbarkeit

Jedes Backup wird auf zwei Ebenen geprüft:

  • Prüfsumme des gesamten Archivs
  • Prüfsummen aller enthaltenen Dateien

Damit wird sichergestellt, dass:

  • Übertragungsfehler erkannt werden
  • Backups unverändert bleiben
  • Restore-Prozesse reproduzierbar sind

2.3 Selbstbeschreibende Backups

Jedes Backup enthält alle notwendigen Informationen zur Einordnung:

  • Versionsinformationen
  • Systeminformationen
  • strukturierte Metadaten
  • Restore-Hinweise

Ein Backup kann dadurch auch ohne Zugriff auf das Ursprungssystem analysiert werden.

2.4 Deterministischer Restore

Der Restore folgt einem festen, wiederholbaren Ablauf:

  1. Validierung des Backups
  2. Bereitstellung der Konfiguration
  3. Einspielen der Daten
  4. Initialisierung der Dienste
  5. Validierung des Ergebnisses

3. Aufbau eines Backups

Backups werden als komprimierte Archive mit definierter Struktur erzeugt.

3.1 Beispielstruktur

backup.tar.gz
├── manifest/
│   ├── SHA256SUMS
│   ├── manifest.env
│   └── README-RESTORE.txt
├── metadata/
│   ├── system-info.txt
│   ├── container-info.json
│   └── environment.txt
├── application-backup/
│   └── <dienstspezifische Daten>
├── config/
│   └── <Konfigurationsdaten>
└── optional/
    └── <optionale Zusatzdaten>

3.2 Eigenschaften

  • portable Struktur
  • klare Trennung der Datenbereiche
  • keine Abhängigkeit von festen Host-Pfaden
  • Erweiterbarkeit für weitere Dienste

4. Integritätskonzept

4.1 Externe Prüfsumme

Für jedes Backup wird eine externe Prüfsumme erzeugt:

sha256sum backup.tar.gz > backup.tar.gz.sha256

Diese dient zur schnellen Validierung des gesamten Archivs.

4.2 Internes Manifest

Zusätzlich enthält jedes Backup ein internes Manifest:

sha256sum * > manifest/SHA256SUMS

Dieses erlaubt die Prüfung jeder einzelnen Datei im Archiv.

4.3 Prüfstrategie

Beim Restore erfolgt die Validierung in folgender Reihenfolge:

  1. Prüfung des Archivs
  2. Entpacken in temporäres Arbeitsverzeichnis
  3. Prüfung aller enthaltenen Dateien

5. Backup-Ablauf (konzeptionell)

Der Backup-Prozess folgt einem standardisierten Ablauf:

# 1. Dienstspezifisches Backup erzeugen
run_application_backup

# 2. Konfiguration sichern
copy_configuration

# 3. Metadaten erfassen
collect_metadata

# 4. Struktur aufbauen
assemble_backup_structure

# 5. Archiv erzeugen
create_archive

# 6. Prüfsummen erstellen
generate_checksums

5.1 Metadaten

Erfasst werden unter anderem:

  • Software-Versionen
  • Laufzeitumgebung
  • Container-Informationen
  • Systemzustand

6. Restore-Konzept

Der Restore ist bewusst strikt strukturiert.

6.1 Phasen

6.1.1 Vorprüfung

  • Validierung der Prüfsummen
  • Strukturprüfung
  • Versionsabgleich

6.1.2 Konfiguration

  • Bereitstellung der Konfigurationsdaten
  • Sicherstellung konsistenter Einstellungen

6.1.3 Datenwiederherstellung

  • Einspielen der Applikationsdaten
  • ggf. Neuinitialisierung von Datenbanken

6.1.4 Initialisierung

  • Start der Dienste
  • interne Reinitialisierung

6.1.5 Validierung

  • Statusprüfung der Dienste
  • einfache Funktionsprüfung

7. Betriebsmodi

Alle Restore-Prozesse unterstützen zwei Modi:

7.1 DRY-RUN (Standard)

  • simuliert den vollständigen Restore
  • zeigt alle geplanten Schritte
  • verändert das System nicht

Ziel: sichere Vorabprüfung

7.2 APPLY

  • führt den Restore tatsächlich aus
  • darf nur nach erfolgreichem DRY-RUN verwendet werden

8. Sicherheitsaspekte

8.1 Umgang mit sensiblen Daten

  • sicherheitsrelevante Informationen werden getrennt behandelt
  • Backups enthalten nur notwendige Daten
  • sensible Inhalte werden nicht unnötig ausgegeben

8.2 Zugriff und Berechtigungen

  • Restore erfordert administrative Rechte
  • destruktive Operationen erfolgen bewusst und nachvollziehbar

8.3 Transparenz

  • alle Schritte sind protokolliert
  • Abläufe sind nachvollziehbar dokumentiert

9. Erweiterbarkeit

Das Konzept ist modular aufgebaut:

  • neue Dienste können integriert werden
  • zusätzliche Metadaten können ergänzt werden
  • Backup-Strategien sind anpassbar

10. Typische Anwendungsfälle

  • Wiederherstellung nach Systemausfall
  • Migration auf neue Infrastruktur
  • Analyse von Systemzuständen
  • Test von Restore-Prozessen

11. Bewertung

11.1 Stärken

  • hohe Transparenz
  • reproduzierbare Backups
  • klare Struktur
  • robuste Integritätsprüfung

11.2 Grenzen

  • Versionskompatibilität muss beachtet werden
  • vollständige Restore-Tests sind erforderlich
  • Metadaten können Hinweise auf Systemstrukturen enthalten

12. Fazit

Das Backup- und Restore-Konzept stellt sicher, dass:

  • Daten konsistent und nachvollziehbar gesichert werden
  • Backups unabhängig verwendbar sind
  • Restore-Prozesse kontrolliert ablaufen
  • ein stabiler und sicherer Betrieb unterstützt wird

13. Weiterführende Dokumente

  • Deployment und Betrieb
  • Monitoring
  • Sicherheitskonzept
  • dienstspezifische Restore-Anleitungen