Backup · Restore · Disaster Recovery
Backup, Disaster Recovery und Wiederherstellung als Service
Sie erfahren nicht erst im Ernstfall, ob Ihre Daten zurückkommen. SKAFFON entwirft und betreibt Backup, Offsite-Kopien, Restore-Tests und DR-Runbooks für Kubernetes, Datenbanken, Proxmox und Objektspeicher.
- Restore-Test mit Testprotokoll
- Offsite-Kopie im anderen Fehlerbereich
- Betrieb und Support 24/7
01Ausgangslage
Kommen Daten und Systeme nach einem schweren Ausfall zurück, und wie schnell?
Backup und Wiederherstellung betreffen bei uns Ihre Plattformen: Kubernetes-Cluster, Datenbanken, virtuelle Maschinen auf Proxmox und Objektspeicher. Zum Service gehören das Backup-Design, Offsite-Kopien, regelmäßige Restore-Tests und DR-Runbooks, nach denen im Ernstfall tatsächlich wiederhergestellt wird. Betrieb und Support laufen 24/7; Reaktionszeiten und Zielwerte werden vertraglich festgelegt.
Der Service richtet sich an IT-Leitung und Plattformverantwortliche. Er liefert die technische Wiederherstellungsfähigkeit, die eine Strategie zur Betriebskontinuität voraussetzt, ersetzt diese Strategie aber nicht.
02Sicherungskette
Ein Backup ist erst belegt, wenn der Restore gelingt
Produktion, Sicherung, Kopie im getrennten Fehlerbereich und Wiederherstellung in einer Testumgebung bilden eine Kette. Die Befunde aus dem Test fließen in Runbook und Backup-Design zurück.
03RPO und RTO
Zwei Kennzahlen bestimmen die Architektur, und eine Replik ist kein Backup
RPO (Recovery Point Objective): Wie viel Datenverlust ist tragbar, gemessen in Zeit? Ein RPO von einer Stunde heißt, die Daten dürfen bis zu einer Stunde alt sein. RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung dauern, bis der Dienst wieder läuft?
Beide Werte hängen von Backup-Rhythmus, Replikation, Datenmenge, Bandbreite und Automatisierungsgrad ab. Die Zielwerte vereinbaren wir deshalb je System und belegen sie durch einen Wiederherstellungstest. Ein RTO, der nie gemessen wurde, ist eine Annahme.
- Eine Replik spiegelt auch Fehler: gelöschte Datensätze, fehlerhafte Migrationen, verschlüsselte Daten.
- Backup mit Aufbewahrung, getrennt von der Produktion, schützt davor.
04Backup-Matrix
Welches Werkzeug sichert welchen Workload, und woran Restores scheitern
Die Matrix zeigt, was wir für welche Art von System einsetzen. Die Spalte „Falle“ nennt, woran Wiederherstellungen in der Praxis scheitern.
| Workload | Werkzeug | Was gesichert wird | Wiederherstellung | Falle |
|---|---|---|---|---|
| Kubernetes (Ressourcen, Volumes) | Velero | Cluster-Ressourcen in Objektspeicher; Volume-Daten per Snapshot (nativ oder CSI) oder per File-System-Backup | Restore in dasselbe oder ein neues Cluster | Velero verschlüsselt nicht selbst; File-System-Backup liest vom laufenden Dateisystem (weniger konsistent als Snapshots), läuft mit erhöhten Rechten und gilt laut Dokumentation als Beta (Velero: File System Backup) |
| Kubernetes (Control Plane) | etcd-Snapshot (Talos), GitOps-Repository | etcd-Zustand, Maschinenkonfiguration; Soll-Zustand in Git | Wiederherstellung der Control Plane aus Snapshot (Talos: Disaster Recovery) | Snapshots nur im selben Cluster-Fehlerbereich |
| PostgreSQL auf VMs | pgBackRest | Vollständige, differenzielle und inkrementelle Backups plus WAL-Archiv | Point-in-Time-Recovery, auch Klon zum Test (pgBackRest) | Repository-Verschlüsselung: Versionen vor 2.59.3 konnten schwache Schlüsselteile erzeugen, siehe unten |
| PostgreSQL auf Kubernetes (CloudNativePG) | Barman-Cloud-Plugin oder Volume-Snapshots | Basis-Backups und WAL-Archiv in Objektspeicher | Wiederherstellung in neuen Cluster; PITR | Die native Barman-Anbindung ist laut Projekt ab 1.26 veraltet und wird ab 1.32.0 entfernt (CloudNativePG: Backup) |
| MySQL | Logische Dumps, Binärlog; physische Sicherung (je nach Edition) | Daten und Binärlog | Point-in-Time-Wiederherstellung über Binärlog (MySQL: Backup and Recovery) | Logische Dumps sind bei großen Beständen langsam |
| MongoDB | Dateisystem-Snapshots oder Dumps; weitere Verfahren je Edition | Daten | Wiederherstellung aus Snapshot (MongoDB: Backup Methods) | Konsistenz bei laufender Datenbank, bei verschlüsselten Speicher-Engines Schlüssel beachten |
| Proxmox-VMs | Proxmox Backup Server | Deduplizierte, inkrementelle VM-Sicherungen, optional clientseitig verschlüsselt, Remote-Sync | Wiederherstellung auf Systemebene oder einzelner Dateien (PBS: Introduction) | Offsite-Kopie und Restore-Test nicht vergessen |
| Proxmox-VMs (vorhandene Veeam-Umgebung) | Veeam | Sicherung der VMs über das Proxmox-Plugin | Je nach Veeam-Version | Kompatibilität mit Ihrer Proxmox-Version vorab gegen die Veeam-Dokumentation prüfen |
| Ceph (Block/Objekt) | RBD-Mirroring, getrennte Sicherung | Asynchrone Kopie auf zweites Cluster | Failover auf das Zielcluster (Ceph: RBD Mirroring) | Ein Mirror ist kein Backup; Löschfehler werden gespiegelt |
Für alle Datenbank-Engines gilt: Für die Betriebskontinuität taugen physische Sicherungen mit Log-Archiv; logische Dumps ergänzen sie, ersetzen sie aber nicht. Mehr zu den Datenbankdiensten: Managed Datenbanken.
05Werkzeugdetails
Fünf Einzelheiten, die über eine Wiederherstellung entscheiden
-
Velero: Aufbewahrung und Restore-Modus
Velero legt standardmäßig eine Aufbewahrungszeit (TTL) von 30 Tagen fest, die man anpassen kann, und empfiehlt für die Wiederherstellung, den Backup-Speicher vorübergehend auf „nur lesend“ zu stellen (Velero: Disaster Recovery).
-
pgBackRest: mehrere Repositories
pgBackRest unterstützt mehrere Repositories, etwa lokal für schnelle Restores und entfernt für längere Aufbewahrung, sowie Backups vom Standby (pgBackRest).
-
pgBackRest: Verschlüsselung vor 2.59.3
Versionen vor 2.59.3 prüften Fehler beim Erzeugen von Zufallsdaten nicht; bei betroffenen Repositories ersetzt ein Update keine bereits erzeugten schwachen Schlüsselteile (pgBackRest: News). Wir prüfen bestehende Repositories darauf, bevor wir sie übernehmen.
-
Proxmox Backup Server: S3 als Backend
Der Proxmox Backup Server kann S3-kompatiblen Objektspeicher als Backend nutzen, was je nach Anbieter Kosten für Speicher, Anfragen und Datenabfluss verursacht (PBS: Storage).
-
Schutzfunktionen des Speichers
Welche Schutzfunktionen der Offsite-Speicher bietet, zum Beispiel unveränderliche Objekte, hängt vom gewählten Speicher ab; wir prüfen das gegen dessen Dokumentation.
06Ernstfall
Gerüst eines DR-Runbooks, je Ausfallszenario geschrieben
Ein Runbook entsteht je Szenario, zum Beispiel Verlust eines Knotens, Verlust eines Clusters, Verlust eines Standorts, versehentliches Löschen oder Schadsoftware. Jedes folgt diesem Gerüst.
- 01
Geltungsbereich und Reihenfolge
Betroffene Systeme und ihre Abhängigkeitsreihenfolge.
- 02
Auslöser und Entscheider
Wer erklärt den Ernstfall, und woran wird er erkannt.
- 03
Kommunikation
Intern, gegenüber Kunden und gegenüber Behörden.
- 04
Voraussetzungen
Zugänge, Schlüssel, Ziel-Infrastruktur und Backup-Speicherort.
- 05
Wiederherstellungsschritte
Befehle oder Pipelines, mit einem Prüfpunkt nach jedem Schritt.
- 06
Datenstand bestimmen
Gewünschter Zeitpunkt und die Konsequenzen für Folgesysteme.
- 07
Abnahme
Abnahmekriterien und fachliche Abnahme durch Sie.
- 08
Rückkehr zum Normalbetrieb
Rückführung in den Regelbetrieb und Nachbereitung.
07Restore-Testprotokoll
So läuft ein Restore-Test, und was im Protokoll steht
Der Ablauf, jeweils mit Ergebnis im Testprotokoll:
- Testumgebung getrennt von der Produktion bereitstellen.
- Aktuelles Backup und, wo möglich, einen älteren Stand einspielen; bei Datenbanken zusätzlich auf einen Zeitpunkt zurückspulen.
- Anwendungsseitig prüfen: Daten vorhanden, Anwendung startet, Stichproben stimmen.
- Dauer messen und festhalten, Abweichungen vom vereinbarten RTO benennen.
- Befunde beheben, Runbook anpassen.
- Testprotokoll im Monatsbericht dokumentieren.
Ihre Daten und Anwendungen bleiben in Ihrer Verantwortung. Wir verantworten die Wege, auf denen sie zurückkommen.
SKAFFON betreibt Sicherungs- und Wiederherstellungswege: Zeitpläne, Aufbewahrung, Offsite-Kopie, Tests und Runbooks. Über Ziele, Datenstand und den Zeitpunkt der Wiederherstellung im Ernstfall entscheiden Sie.
08Leistungsumfang
Sieben Bausteine vom Entwurf bis zur DR-Übung
-
Backup-Design
Welche Systeme, welche Daten, welche Aufbewahrung, welches RPO/RTO; Abgleich mit Ihren Vorgaben.
-
Einrichtung und Betrieb
Aufbau der Werkzeuge nach Matrix, Zeitpläne, Aufbewahrungsregeln, Überwachung der Läufe.
-
Offsite-Kopien
Eine Kopie an anderem Ort und in anderem Fehlerbereich als die Produktion; Schutz der Sicherungen gegen Veränderung und Löschung gehört zum Entwurf.
-
Restore-Tests
Regelmäßige Wiederherstellung in einer getrennten Umgebung, mit Testprotokoll.
-
DR-Runbooks
Schritt-für-Schritt-Abläufe für definierte Ausfallszenarien, mit Reihenfolge der Wiederherstellung und Entscheidungspunkten.
-
DR-Übungen
Gemeinsame Übung mit Ihrem Team, einschließlich Kommunikation und Freigaben.
-
Berichte
Backup-Status, Testergebnisse, Abweichungen, Empfehlungen.
09Verantwortung
Wer im Backup-Betrieb was führt: RACI
R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung, vertraglich anpassbar.
| Tätigkeit | SKAFFON | Kunde |
|---|---|---|
| Wiederherstellungsziele (RPO/RTO) je System festlegen | C | R/A |
| Backup-Design und Werkzeugauswahl | R | A |
| Backup einrichten, Zeitpläne und Aufbewahrung betreiben | R/A | I |
| Überwachung der Backup-Läufe, Störungen beheben | R/A | I |
| Offsite-Kopie betreiben | R/A | C |
| Schutz der Sicherungen (Zugriff, Verschlüsselung, Schlüsselverwahrung) | R | A |
| Restore-Tests durchführen und protokollieren | R/A | C |
| DR-Runbooks erstellen und pflegen | R/A | C |
| Wiederherstellung im Ernstfall durchführen | R | A (Entscheidung, Zeitpunkt, Datenstand) |
| Fachliche Abnahme der wiederhergestellten Anwendung | C | R/A |
| Anwendungskonsistenz (Quiesce, Transaktionen) | C | R/A |
| Meldung gegenüber Aufsicht, Kunden, Versicherern | I | R/A |
| Kapazitätsplanung Backup-Speicher, Berichte | R | A |
10Laufender Betrieb
Was zwischen den Restore-Tests passiert
-
Störungen und Prioritäten
Störungen werden nach Priorität eingestuft, etwa eine fehlgeschlagene Backup-Serie, ein nicht erreichbarer Backup-Speicher oder eine laufende Wiederherstellung. Prioritätsstufen P1 bis P4 und Reaktionszeiten stehen im Servicelevel-Rahmen; die Eskalationskette legt der Vertrag fest. Kontaktwege prüfen wir im Onboarding mit einer Probealarmierung.
-
Incident und Wiederherstellungsfall
Incident: Alarm, Priorisierung, Eingrenzung, Behebung oder Workaround (zum Beispiel manuell angestoßenes Backup), Information an Sie, Abschluss mit Ihrer Bestätigung; bei Ausfall einer Sicherung Ursachenanalyse und nachgeholter Lauf. Der Wiederherstellungsfall läuft als eigener Prozess nach Runbook, mit Entscheidung durch Sie.
-
Change und Patch
Änderungen an Zeitplänen, Aufbewahrung und Zielen laufen als Code im Review, mit Freigabe durch Sie und Verifikation per Testlauf. Updates der Backup-Werkzeuge werden nach Test eingespielt; sicherheitsrelevante Herstellermeldungen bewerten wir und stimmen Maßnahmen mit Ihnen ab.
-
Monitoring und Monatsbericht
Überwacht werden Laufstatus, Dauer, Datenmenge, Alter des letzten erfolgreichen Backups, Füllstand des Backup-Speichers, WAL-Archivierung und die Ergebnisse der Restore-Tests. Der Monatsbericht fasst Läufe, Abweichungen, Testergebnisse und Empfehlungen zusammen.
11Onboarding
Von der Bestandsaufnahme zum Regelbetrieb
- 01
Bestandsaufnahme
Vorhandene Sicherungen und deren Wiederherstellbarkeit.
- 02
Klassifizierung
Einstufung der Systeme nach Kritikalität.
- 03
Zielwerte
RPO und RTO je System festlegen.
- 04
Aufbau
Werkzeuge, Zeitpläne, Aufbewahrung, Offsite-Kopie.
- 05
Erster Restore-Test
Wiederherstellung in getrennter Umgebung mit Protokoll.
- 06
Regelbetrieb
Übergang in den laufenden Betrieb mit Monatsbericht.
12Zusagen und Angebot
Was wir bei Wiederanlaufzeiten zusagen
Was zugesagt werden kann, hängt von Datenmenge, Bandbreite zum Backup-Speicher, Zielumgebung und Automatisierung ab. Kennzahlen, Messmethode und Folgen bei Abweichung werden vertraglich vereinbart; die Systematik beschreibt der Servicelevel-Rahmen.
Wir beginnen mit einer Bestandsaufnahme und legen daraus Umfang, RACI und Berichtsrhythmus fest. Der Aufwand richtet sich nach den nebenstehenden Einflussfaktoren; aus ihnen ergeben sich Umfang und Preis des Angebots.
13Passung
Für welche Backup-Aufgaben der Service gebaut ist
Das deckt der Service ab
- Backup und Wiederherstellung für Kubernetes, Datenbanken, Proxmox-VMs und Objektspeicher.
- Restore-Tests mit Testprotokoll und eine Zielumgebung, die im Design festgelegt wird.
- Gemeinsame DR-Übungen mit Ihrem Team.
Das gehört nicht dazu
- Sicherung von Arbeitsplatzrechnern oder Microsoft-365-Postfächern; der Service betrifft Plattformen und Infrastruktur.
- Vertraglich zugesicherte Wiederanlaufzeit ohne Test und ohne Zielumgebung.
- Betrieb ohne Zugriff auf die Systeme oder ohne Restore-Tests.
- Rechtsberatung oder Unterstützung bei Meldepflichten; die liegen bei Ihnen.
14
Häufige Fragen
Reicht ein Snapshot als Backup?
Nein, wenn er im selben Speichersystem liegt wie die Produktion. Ein Snapshot schützt vor Fehlbedienung, nicht vor dem Verlust des Speichers.
Wie oft sollen Restore-Tests laufen?
Das hängt von Kritikalität und Änderungsrate ab; wir vereinbaren den Rhythmus je System und halten jeden Test im Protokoll fest.
Können Sie auch in eine zweite Umgebung wiederherstellen?
Ja; die Zielumgebung (anderer Standort, andere Region, anderer Anbieter) wird im Design festgelegt und im Test belegt.
Beschreiben Sie Ihre Systeme und Ihre Grenzen für Datenverlust und Wiederanlauf
Wir beginnen mit einer Bestandsaufnahme und legen daraus Umfang und Zielwerte fest.