Verwendete Software und Versionen
Diese Erklärung bezieht sich auf:
- Konzepte: Distributions-übergreifende Automatisierungs-Prinzipien
- Bordmittel: sha256sum, df, ln, mv, Shell-Standards
- Kontext: Self-Hosting-Infrastrukturen, digitale Souveränität
Manuelle Sicherungen scheitern an menschlicher Unzuverlässigkeit. Ein vergessenes Backup vor kritischem System-Update kostet Stunden Wiederherstellungszeit. Wöchentliche Sicherungs-Routinen werden bei Urlaub oder Krankheit übersprungen. Automatisierte Backup-Systeme eliminieren diese Fehlerquellen durch konsistente, zeitgesteuerte Ausführung ohne menschliche Intervention.
Die 3-2-1-Regel aus Artikel 1 verlangt drei Sicherungskopien auf zwei Medien-Typen mit einer externen Kopie. Diese Anforderungen multiplizieren Automatisierungs-Komplexität: Drei separate Backup-Jobs mit unterschiedlichen Zielen, koordinierte Rotation für Speicherplatz-Management, Verifikation jeder Kopie auf Integrität. Robuste Automatisierung macht diese Komplexität handhabbar.
Zeitbasierte Ausführung für konsistente Sicherungen
Warum zeitbasierte Automatisierung kritisch ist
Backup-Systeme funktionieren nur durch absolute Zuverlässigkeit. Ein vergessenes wöchentliches Backup bedeutet keine Wiederherstellungs-Option für 7-14 Tage alte Daten. Zeitbasierte Scheduler führen Backup-Scripts zu definierten Zeitpunkten aus ohne auf menschliches Erinnern angewiesen zu sein.
Alle modernen Betriebssysteme bieten zeitbasierte Job-Scheduler als Basis-Funktionalität. Diese Scheduler unterstützen tägliche, stündliche, wöchentliche und monatliche Ausführungs-Zeitpunkte. Die genaue Konfiguration unterscheidet sich zwischen Systemen, aber das Kern-Konzept bleibt identisch: Script-Ausführung zu festgelegten Zeiten.
Ausführungs-Zeitpunkte koordinieren
Parallele Backup-Jobs konkurrieren um Datenbank-Locks, Festplatten-Durchsatz und Netzwerk-Bandbreite. Sequenzielle Backup-Ausführung vermeidet die Ressourcen-Konflikte durch eine zeitliche Staffelung. Das lokale Backup läuft um 03:00 Uhr, NAS-Transfer um 04:00 Uhr, externes Upload erst um 05:00 Uhr - jeder Job erhält dediziertes Zeitfenster ohne Überschneidung.
Ausführungs-Koordination:
03:00 Datenbank-Dump auf lokale SSD erstellen
03:30 Dateisystem-Backup auf lokale SSD erstellen
04:00 Lokale Backups zum NAS kopieren
05:00 NAS-Backups zum externen Server synchronisieren
06:00 Externe Backups auf Cloud-Speicher hochladen
Diese Staffelung garantiert dass NAS-Transfer erst beginnt nachdem die lokalen Backups abgeschlossen sind. Cloud-Upload startet nicht bevor die NAS-Kopie verifiziert wurde. Fehler in frühen Backup-Stufen propagieren nicht zu späteren Stufen.
Verpasste Ausführungen durch System-Ausfälle
Laptops und Desktop-Systeme laufen nicht kontinuierlich - Herunterfahren zur Nacht überspringt die geplante 03:00-Uhr-Backups. Server die für Wartung heruntergefahren werden verpassen ebenfalls geplante Sicherungen. Moderne Scheduler bieten Mechanismen um verpasste Jobs beim nächsten System-Start nachzuholen.
Das Nachhol-Konzept prüft bei System-Start ob geplante Jobs während Downtime verpasst wurden. Diese Jobs werden automatisch ausgeführt sobald System wieder läuft. Ein tägliches 03:00-Uhr-Backup das durch 22:00-Shutdown verpasst wurde läuft beim nächsten Boot nach - typischerweise 15-30 Minuten nach System-Start für einen stabielen Boot-Vorgang.
Backup-Rotation für Aufbewahrungsrichtlinien
Generations-basierte Rotation
Das Täglich-Wöchentlich-Monatlich-Schema aus Artikel 1 verlangt automatische Rotation: Tägliche Backups werden nach 7 Tagen gelöscht außer die Sonntagssicherung wird zur wöchentlichen befördert. Wöchentliche Backups werden nach 4 Wochen gelöscht außer die Monatsanfang-Sicherung wird zur monatlichen befördert. Monatliche Backups bleiben 12 Monate bestehen.
Rotations-Logik:
Tägliche Sicherung erstellen
Wenn Sonntag: Kopie nach weekly/ verschieben
Wenn erster Tag des Monats: Kopie nach monthly/ verschieben
Dateien älter 7 Tage aus daily/ löschen
Dateien älter 28 Tage aus weekly/ löschen
Dateien älter 365 Tage aus monthly/ löschen
Diese Mechanik erhält drei Generationen mit unterschiedlichen Aufbewahrungsfristen automatisch. Ein fehlgeschlagenes tägliches Backup verhindert nicht die Beförderung zur wöchentlichen Sicherung - der Sonntags-Job kopiert das letzte erfolgreiche Daily-Backup.
Hardlink-basierte Rotation für Speicher-Effizienz
Hardlinks erlauben mehrere Verzeichnis-Einträge die auf identische Datei-Daten zeigen. Das ln-Kommando erstellt Hardlinks auf allen Unix-artigen Systemen. Backup-Systeme nutzen Hardlinks um Speicher zu sparen: Unveränderte Dateien werden als Hardlink zur vorherigen Generation gespeichert statt komplett kopiert.
Eine 100-GB-Datenbank mit 5% täglichen Änderungen benötigt nur 5 GB zusätzlichen Speicher pro Tag statt 100 GB Vollsicherung. Sieben tägliche Backups belegen 130 GB (100 GB + 6×5 GB) statt 700 GB. Jedes Backup-Verzeichnis sieht aus wie vollständige Kopie aber teilt unveränderte Blöcke mit anderen Generationen.
Hardlink-Rotation-Konzept:
Neue Sicherung nach backup.new/ schreiben
Unveränderte Dateien als Hardlinks zu backup.0/ erstellen (ln)
Nach Abschluss: backup.6/ löschen
backup.5/ zu backup.6/ umbenennen (mv)
backup.4/ zu backup.5/ umbenennen
backup.3/ zu backup.4/ umbenennen
backup.2/ zu backup.3/ umbenennen
backup.1/ zu backup.2/ umbenennen
backup.0/ zu backup.1/ umbenennen
backup.new/ zu backup.0/ umbenennen
Diese Rotation erhält sieben unabhängige Backup-Verzeichnisse die einzeln löschbar sind ohne andere Generationen zu beeinträchtigen. Das Löschen von backup.6/ gibt nur den Speicher frei der exklusiv von dieser Generation belegt war.
Backup-Verifikation erkennt Korruption
Prüfsummen-basierte Integritäts-Checks
Kryptographische Prüfsummen erzeugen eindeutige Fingerprints von Dateien. sha256sum berechnet 256-Bit-Hashwerte aus Datei-Inhalten - identische Prüfsummen garantieren bit-identische Dateien, unterschiedliche Prüfsummen zeigen Korruption oder Manipulation. Das sha256sum-Kommando existiert auf allen modernen Unix-Systemen als Standard-Bordmittel.
Verifikations-Workflow:
Backup erstellen: backup-2025-08-10.sql.gz
Prüfsumme berechnen: sha256sum backup-2025-08-10.sql.gz > backup-2025-08-10.sql.gz.sha256
Vor Wiederherstellung: sha256sum --check backup-2025-08-10.sql.gz.sha256
Bei Mismatch: Backup ist korrupt, nächstes verfügbares Backup versuchen
Prüfsummen-Dateien werden neben Backups gespeichert für spätere Verifikation. Die automatische Verifikation läuft nach jedem Backup-Transfer - Netzwerk-Korruption oder unvollständige Transfers fallen sofort auf. Ein korruptes Backup wird erkannt bevor es alte funktionierende Sicherungen überschreibt.
Test-Wiederherstellungen validieren Recovery-Fähigkeit
Prüfsummen verifizieren Datei-Integrität aber nicht Wiederherstellbarkeit. Ein perfekt intaktes Backup kann aufgrund fehlender Abhängigkeiten, falscher Berechtigungen oder inkompatiblen Datenbank-Versionen nicht wiederherstellbar sein. Regelmäßige Test-Wiederherstellungen validieren den kompletten Recovery-Workflow vom Backup-Abruf bis zur funktionierenden Datenbank.
Test-Wiederherstellungs-Konzept:
Separates Test-System vorbereiten (andere Hardware oder VM)
Backup von Produktion abrufen
Prüfsumme verifizieren
Wiederherstellung durchführen
Basis-Funktionalität testen (Datenbank-Queries, Applikations-Tests)
Bei Erfolg: Backup als verifiziert markieren
Bei Fehler: Problem identifizieren, Backup-Prozess korrigieren
Minimum-Test-Frequenz: Quartalsweise vollständige Test-Wiederherstellung. Diese Tests identifizieren Backup-Coverage-Lücken bevor echte Katastrophen passieren. Die dokumentierte Test-Wiederherstellungs-Dauer liefert realistische Erwartungen für Produktions-Recovery-Zeiten.
Partial-Restore-Tests für spezifische Szenarien
Vollständige Datenbank-Wiederherstellungen testen Recovery nach Komplett-Ausfall. Viele reale Probleme erfordern aber Teil-Wiederherstellungen: Einzelne gelöschte Tabelle, versehentlich aktualisierte Records, korrupte einzelne Datei. Partial-Restore-Tests validieren dass Backup-Format diese selektiven Wiederherstellungen unterstützt.
SQL-Dumps erlauben einfache Tabellen-Extraktion durch grep und Text-Verarbeitung. Binäre Backup-Formate erfordern spezielle Tools für Teil-Wiederherstellungen. Die Backup-Format-Wahl beeinflusst Partial-Restore-Flexibilität - Text-basierte Formate bieten maximale Flexibilität, binäre Formate bieten Geschwindigkeit und Kompression.
Fehlerbehandlung für robuste Backup-Systeme
Exit-Codes signalisieren Job-Status
Beim Beenden liefern Unix-Programme numerische Exit-Codes. Der Wert 0 signalisiert Erfolg, alle anderen Werte zeigen Fehler an. Backup-Scripts müssen diese Konvention strikt befolgen für eine korrekte Fehler-Erkennung. Ein Script das trotz Backup-Fehler Exit-Code 0 zurückgibt verhindert eine automatische Problem-Erkennung.
Shell-Option set -e terminiert Scripts sofort bei ersten Fehler. Diese Option garantiert dass fehlgeschlagene Befehle nicht ignoriert werden. Kombiniert mit set -u (undefinierte Variablen sind Fehler) und set -o pipefail (Pipeline-Fehler weitergeben) entsteht robuste Fehlerbehandlung.
Fehlerbehandlungs-Pattern:
#!/bin/sh
set -e Skript bei Fehler sofort beenden
set -u Undefinierte Variablen als Fehler behandeln
set -o pipefail Pipeline-Fehler nicht verschlucken
Datenbank-Dump ausführen
Prüfsumme berechnen
Zum Ziel kopieren
Prüfsumme am Ziel verifizieren
Bei Fehler in irgendeinem Schritt: Exit-Code non-zero
Bei Erfolg aller Schritte: Exit-Code 0
Scheduler-Systeme nutzen Exit-Codes für automatisches Fehler-Management. Non-zero Exit-Codes triggern Retry-Mechanismen, Logging oder Benachrichtigungen je nach Scheduler-Konfiguration.
Retry-Mechanismen mit exponentiellem Backoff
Temporäre Netzwerk-Probleme oder kurzzeitige Datenbank-Locks rechtfertigen keine sofortige Eskalation. Automatische Retries mit wachsenden Wartezeiten lösen solche vorübergehenden Fehler ohne manuelle Intervention. Der erste Retry erfolgt nach 1 Minute, der zweite nach 2 Minuten, der dritte nach 4 Minuten. Nach drei erfolglosen Versuchen gilt das Backup als gescheitert.
Retry-Logik-Konzept:
retry_count=0
max_retries=3
retry_delay=60
Solange retry_count kleiner max_retries:
Backup-Operation versuchen
Bei Erfolg: Script mit Exit-Code 0 beenden
Bei Fehler:
retry_delay Sekunden warten (sleep)
retry_delay verdoppeln für nächsten Versuch
retry_count um 1 erhöhen
Nach max_retries ohne Erfolg: Script mit Exit-Code non-zero beenden
Exponentieller Backoff verhindert dass Retry-Storms überlastete Systeme weiter belasten. Ein überlasteter Datenbank-Server erholt sich zwischen Retry-Versuchen statt durch permanente Backup-Anfragen weiter degradiert zu werden. Die Wartezeiten erlauben temporären Problemen sich selbst zu lösen.
Atomare Operationen verhindern Partial-Updates
Fehlgeschlagene Backups dürfen nicht funktionierende vorherige Sicherungen überschreiben. Atomare Moves garantieren dass Ziel-Verzeichnisse nur valide Backups enthalten. Das mv-Kommando ist auf Dateisystem-Ebene atomar - entweder kompletter Erfolg oder keine Änderung.
Atomares Backup-Pattern:
Backup in temporäre Datei schreiben: backup.sql.gz.tmp
Prüfsumme der temporären Datei verifizieren
Bei Erfolg:
Altes Backup umbenennen: mv backup.sql.gz backup.sql.gz.old
Neues Backup aktivieren: mv backup.sql.gz.tmp backup.sql.gz
Altes Backup nach Aufbewahrungsrichtlinie löschen
Bei Fehler:
Temporäre Datei löschen: rm backup.sql.gz.tmp
Altes backup.sql.gz bleibt komplett unberührt
Diese Mechanik garantiert dass fehlgeschlagene Backups nie funktionierende Sicherungen zerstören. Das System fällt automatisch auf die letzte valide Sicherung zurück ohne manuelle Intervention. Zwischen mv-Operationen existieren kurze Zeitfenster mit beiden Dateien - keine Datenverlust-Gefahr.
Speicherplatz-Management vor Backup-Start
Backup-Systeme scheitern wenn Ziel-Partitionen volllaufen. Pre-Flight-Checks vor Backup-Start prüfen verfügbaren Speicherplatz gegen erwartete Backup-Größe. Das df-Kommando zeigt verfügbaren Platz auf allen Unix-Systemen. Das du-Kommando misst Verzeichnis-Größen für Kapazitäts-Schätzungen.
Speicherplatz-Check-Konzept:
df /backup Verfügbaren Platz ermitteln
du -s /var/lib/database Quell-Datenbank-Größe messen
Wenn verfügbar kleiner (Datenbank-Größe * 1.5):
Älteste Sicherung aus daily/ löschen
Verfügbaren Platz erneut prüfen
Bei weiterhin unzureichendem Platz:
Backup-Versuch abbrechen
Exit-Code non-zero returnen
Der Faktor 1.5 berücksichtigt Kompression und temporäre Dateien während einer Backup-Erstellung. Backup-Rotation muss die Speicherplatz-Freigabe vor den neuen Backups durchführen. FIFO-Rotation (First In First Out) löscht älteste Generationen automatisch wenn die Speicher-Limits erreicht werden.
Best Practices für Produktions-Backup-Automatisierung
Separate Backup-Benutzer mit minimalen Berechtigungen
Backup-Scripts laufen unter dediziertem Benutzer-Account mit read-only Zugriff auf zu sichernde Daten. Kompromittierte Backup-Scripts können keine Daten modifizieren oder löschen. Datenbank-Backup-Benutzer erhält nur Lese-Rechte auf notwendige Datenbanken - keine Schreib-, Update- oder Lösch-Operationen.
Berechtigungs-Prinzip:
backup-Benutzer kann:
Datenbank-Dumps erstellen (lesender Zugriff)
Dateien lesen in zu sichernden Verzeichnissen
Schreiben in dediziertes /backup Verzeichnis
backup-Benutzer kann NICHT:
Datenbank-Tabellen modifizieren
System-Konfigurationen ändern
Andere Benutzer-Verzeichnisse schreiben
Erhöhte Privilegien (sudo, root) nutzen
Diese Isolation begrenzt Schaden bei Backup-System-Kompromittierung. Ransomware die Backup-Prozesse übernimmt kann keine Produktions-Datenbanken verschlüsseln. Die Trennung zwischen Lese-Zugriff (Backup-Erstellung) und Schreib-Zugriff (Produktions-Daten) bildet kritische Sicherheits-Barriere.
Dokumentation und Runbooks für Notfall-Recovery
Backup-Automatisierung funktioniert zuverlässig bis zum Tag der Katastrophe. Unter Stress vergisst man kritische Wiederherstellungs-Schritte oder übersieht wichtige Details. Dokumentierte Runbooks mit Schritt-für-Schritt-Anleitung ermöglichen schnelles korrektes Handeln in Notfall-Situationen.
Runbook-Inhalte:
Backup-Speicherorte und Zugriffs-Informationen
Schritt-für-Schritt Wiederherstellungs-Prozedur
Erwartete Wiederherstellungszeit pro Backup-Ort
Verifikations-Checks nach Recovery
Kontakt-Informationen für Eskalation bei Problemen
Post-Recovery-Checklist für Vollständigkeits-Prüfung
Regelmäßige Runbook-Reviews aktualisieren veraltete Informationen. Quartalsweise Katastrophen-Wiederherstellungs-Übungen testen Runbook-Vollständigkeit und identifizieren fehlende Details. Diese Übungen simulieren echte Notfall-Bedingungen - Server-Ausfall, Datenverlust, Zeitdruck.
Monitoring und Protokollierung für Fehler-Erkennung
Automatische Backups laufen ohne menschliche Überwachung - fehlgeschlagene Sicherungen bleiben unbemerkt ohne ein aktives Monitoring. Exit-Codes signalisieren den Job-Status aber erfordern ein Monitoring-System das diese Codes auswertet und bei Problemen alarmiert.
Monitoring-Prinzipien:
Bei Erfolg: Timestamp des letzten erfolgreichen Backups aktualisieren
Bei Fehler: Exit-Code non-zero für Scheduler-System
Protokollierung: Alle Backup-Operationen mit Timestamps loggen
Alerting: Benachrichtigung wenn letztes Backup älter als X Stunden
Das Monitoring-System prüft regelmäßig Backup-Timestamps - Alarmierung wenn das letztes erfolgreiches Backup zu alt ist. Dieser Mechanismus erkennt sowohl fehlgeschlagene Backups als auch komplett ausgefallene Backup-Jobs die gar nicht mehr laufen. Tägliche Backups sollten maximal 36 Stunden alt sein für eine rechtzeitige Problem-Erkennung.
