Verwendete Software und Versionen
Diese Erklärung bezieht sich auf:
- Konzepte: Distributions-übergreifende Backup-Prinzipien
- Speichermedien: HDD, SSD, NAS, Cloud-Speicher
- Verschlüsselung: gpg 2.2+, age 1.0+ (Konzepte, keine vollständigen Tutorials)
- Kontext: Self-Hosting-Infrastrukturen, digitale Souveränität
Festplatten-Defekte vernichten Datenbanken in Sekunden. Ransomware verschlüsselt komplette Server inklusive lokaler Sicherungen. Feuer oder Wasserschäden zerstören Hardware und alle angeschlossenen Speichermedien gleichzeitig. Eine einzelne Sicherung auf derselben Festplatte wie die Originaldaten schützt vor keinem dieser Szenarien.
Die 3-2-1-Regel definiert minimale Backup-Anforderungen für ernsthafte Datensicherheit: Drei Sicherungskopien auf mindestens zwei verschiedenen Speichermedien-Typen, eine Kopie an geografisch getrenntem Standort. Diese Strategie überlebt Hardware-Ausfälle, lokale Katastrophen und die meisten Angriffs-Szenarien.
Die 3-2-1-Regel konkret umgesetzt
Drei Kopien bedeutet Primärdaten plus zwei Sicherungen
Eine Produktions-Datenbank läuft auf Server-SSD (Primärdaten). Die erste Sicherung landet auf derselben Maschine in separatem Verzeichnis - schnelle Wiederherstellung bei Software-Korruption oder versehentlichem Löschen. Die zweite Sicherung wird auf externe HDD oder NAS geschrieben - Schutz vor SSD-Ausfall. Die dritte Sicherung landet auf entferntem Server oder Cloud-Speicher - Überleben bei Feuer, Diebstahl oder Ransomware.
Beispiel-Verzeichnisstruktur:
/var/lib/postgresql/data/ Primärdatenbank auf SSD
/backup/local/daily/ Erste Kopie: Lokale SSD
/mnt/nas/backups/postgresql/ Zweite Kopie: NAS oder externe HDD
user@remote:/backups/server1/ Dritte Kopie: Externer Remote-Server
Diese Struktur erlaubt abgestuftes Wiederherstellen: Lokale Sicherung für 5-Minuten-Wiederherstellung, NAS-Sicherung für Hardware-Austausch-Szenarien, externe Sicherung für totale Standort-Zerstörung.
Zwei Medien-Typen verhindern zusammenhängende Ausfälle
SSDs und HDDs versagen aus unterschiedlichen Gründen. SSD-Flash-Zellen erschöpfen sich nach Schreibzyklen - vorhersagbarer Ausfall nach 3-5 Jahren intensiver Nutzung. HDDs erleiden mechanische Defekte durch Kopf-Crashes oder Motor-Ausfälle - unvorhersagbarer Ausfall unabhängig von der Nutzungsintensität. Ein SSD-Ausfall korreliert nicht mit HDD-Gesundheit.
NAS-Systeme mit RAID eliminieren einzelne Festplatten-Ausfälle, schützen aber nicht vor Controller-Defekten, Dateisystem-Korruption oder Ransomware-Verschlüsselung. Cloud-Speicher überlebt lokale Hardware-Probleme komplett, verlangt aber Vertrauen in Drittanbieter und konstante Internet-Verbindung.
Eine externe Kopie überlebt lokale Katastrophen
Feuer, Überschwemmungen und Einbrüche betreffen alle Geräte am selben physischen Standort. Ein Server-Rack mit Primär-SSD, Backup-HDD und NAS verliert alle Daten gleichzeitig bei Brand oder Wasserschaden. Geografische Trennung durch entfernte Server oder Cloud-Speicher garantiert Daten-Überleben auch bei komplettem Standort-Verlust.
Mindest-Distanz für effektive externe Sicherungen: Unterschiedliche Gebäude, idealerweise verschiedene Städte. Home-Server-Backups auf Büro-Server erfüllen diese Anforderung. VPS-Anbieter in anderen Rechenzentren oder Cloud-Speicher in anderen Regionen bieten maximale physische Trennung.
Speichermedien-Charakteristika und Auswahl
SSD-Performance für schnelle Wiederherstellung
SSDs erreichen 500-3500 MB/s sequenzielles Lesen je nach Schnittstelle (SATA vs NVMe). Eine 100-GB-PostgreSQL-Datenbank lässt sich von NVMe-SSD in 30-60 Sekunden vollständig einlesen. Diese Geschwindigkeit macht SSDs optimal für primäre Sicherungen die schnelles Wiederherstellen ermöglichen sollen.
SSD-Kosten pro Gigabyte: 0,08-0,15 EUR für Consumer-Grade, 0,20-0,40 EUR für Enterprise mit höherer Belastbarkeit. Backup-Arbeitslasten mit seltenen Schreibvorgängen funktionieren problemlos auf Consumer-SSDs. Schreibbelastbarkeit von 600 TBW (Terabytes Written) genügt für 10+ Jahre tägliche 100-GB-Sicherungen.
HDD-Kapazität für Langzeit-Archive
HDDs bieten 12-20 TB Kapazität zu 0,015-0,025 EUR pro Gigabyte - Faktor 4-8 günstiger als SSDs. Sequenzielles Lesen erreicht 100-200 MB/s ausreichend für Wiederherstellung die nicht minuten-kritisch ist. Eine 100-GB-Wiederherstellung von HDD dauert 8-15 Minuten statt unter einer Minute von SSD.
Mechanische Festplatten ertragen 300-600 Betriebsstunden pro Jahr ohne Zuverlässigkeits-Probleme. Kontinuierlich laufende NAS-HDDs erreichen 5-8 Jahre mittlere Betriebszeit bis zum Ausfall. Externe HDDs die nur für Sicherungen eingeschaltet werden überleben 10+ Jahre durch minimale mechanische Belastung.
NAS-Systeme für zentrale Backup-Verwaltung
Network Attached Storage sammelt Sicherungen von mehreren Servern an einem zentralen Speicherort. RAID-Konfigurationen (RAID1, RAID5, RAID6) verteilen Daten über mehrere Festplatten für Ausfall-Toleranz. RAID5 überlebt einen simultanen HDD-Ausfall, RAID6 überlebt zwei.
NAS-Netzwerk-Performance: 1 GbE erreicht 110-120 MB/s, 10 GbE erreicht 1100-1200 MB/s. Backup-Transfer von 100 GB benötigt 15 Minuten über 1 GbE, 90 Sekunden über 10 GbE. Multi-Gigabit-Switches (2,5 GbE, 5 GbE) bieten Mittelweg für Home-Lab-Budgets.
Cloud-Speicher für geografische Redundanz
S3-kompatible Speicher (AWS, Backblaze B2, Wasabi) bieten nutzungsbasierte Bezahlung ohne Hardware-Investment. Backblaze B2 kostet 0,005 USD pro GB Speicher plus 0,01 USD pro GB Download. 500 GB Backup-Archive kosten 2,50 USD monatlich, komplette Wiederherstellung 5 USD zusätzlich.
Upload-Bandbreite limitiert Cloud-Backup-Praktikabilität: 100 Mbit/s Upload benötigt 2,5 Stunden für 100-GB-Initialsicherung, dann nur Deltas. Deutsche DSL-Anschlüsse bieten typisch 10-50 Mbit/s Upload - 5-12 Stunden für 100 GB. Dedizierte Server-Uplinks mit 1 Gbit/s schaffen identische Sicherungen in 15 Minuten.
Aufbewahrungsrichtlinien für Balance zwischen Speicher und Wiederherstellungs-Optionen
Täglich-Wöchentlich-Monatlich-Schema
Tägliche Sicherungen für die letzten 7 Tage ermöglichen Wiederherstellung von Problemen die innerhalb einer Woche entdeckt werden. Wöchentliche Sicherungen für die letzten 4 Wochen fangen monatliche Datenbank-Korruptionen ab. Monatliche Sicherungen für 12 Monate erlauben Jahres-Vergleiche und Compliance-Anforderungen.
Aufbewarungs-Bereinigung:
/backup/daily - Dateien älter 7 Tage löschen
/backup/weekly - Dateien älter 28 Tage löschen
/backup/monthly - Dateien älter 365 Tage löschen
Diese Richtlinie balanciert Speicherplatz-Verbrauch gegen Wiederherstellungs-Flexibilität. 100-GB-Datenbank mit täglichen Vollsicherungen: 7 Daily (700 GB) + 4 Weekly (400 GB) + 12 Monthly (1200 GB) = 2,3 TB Gesamtspeicher für komplette Jahres-Historie.
Teilsicherungen vs Vollsicherungen
Vollsicherungen kopieren komplette Datenbanken bei jeder Ausführung - einfachste Wiederherstellung aber maximaler Speicher-Verbrauch. Teilsicherungen sichern nur Änderungen seit letzter Vollsicherung - Speicher-Effizienz aber komplexere Wiederherstellung mit Basis-Backup plus alle Teilsicherungen.
PostgreSQL Transaktionsprotokoll-Archivierung speichert Änderungsprotokolle kontinuierlich statt periodischer Vollsicherungen. Eine wöchentliche Vollsicherung plus tägliches Transaktionsprotokoll-Archiv erlaubt zeitpunktgenaue Wiederherstellung mit minimalen Speicher-Kosten. MariaDB Binary-Logs bieten identische Funktionalität für MySQL-kompatible Datenbanken.
Verschlüsselung schützt externe Sicherungen
Unverschlüsselte Sicherungen auf entfernten Servern oder Cloud-Speichern exponieren sensible Daten. Server-Betreiber, Cloud-Provider-Mitarbeiter oder Angreifer mit Speicherzugriff lesen Datenbank-Inhalte direkt. Verschlüsselte Sicherungen bleiben unlesbar ohne Entschlüsselungsschlüssel auch bei komplettem Speicherzugriff.
gpg (GNU Privacy Guard) verschlüsselt Dateien mit Public-Key-Kryptographie oder symmetrischen Passphrasen. age (actuated good encryption) bietet modernere Alternative mit einfacherer Syntax. Beide Tools erzeugen verschlüsselte Datenströme für Backup-Pipeline-Integration.
Verschlüsselungs-Beispiele:
Datenbank-Dump → Kompression → gpg-Verschlüsselung → backup.sql.gz.gpg
Datenbank-Dump → Kompression → age-Verschlüsselung → backup.sql.gz.age
Schlüsselverwaltung bestimmt Sicherheitslevel: Symmetrische Passphrasen sind einfach aber erfordern sichere Passphrase-Speicherung. Public-Key-Verschlüsselung trennt Verschlüsselungsschlüssel (auf Backup-Server) von Entschlüsselungsschlüssel (nur auf Wiederherstellungs-Workstation) für bessere operative Sicherheit.
Kompression reduziert Speicher und Transfer-Zeit
Text-basierte Backup-Formate (SQL-Dumps, CSV-Exports) komprimieren typisch 80-95%. Eine 10-GB-PostgreSQL-Datenbank wird zu 500-2000 MB .gz-Datei je nach Daten-Charakteristika. Binäre Formate (PostgreSQL Custom-Format, MariaDB Physical-Backups) komprimieren 30-70% durch bereits kompakte Datenstrukturen.
gzip (Standard-Kompression) erreicht 5-20 MB/s Single-Threaded. xz (bessere Kompression) erreicht 1-5 MB/s. zstd (moderner Kompromiss) erreicht 100-500 MB/s Multi-Threaded mit vergleichbaren Kompression-Ratios wie gzip. CPU-Overhead vs Transfer-Zeit-Einsparungen bestimmen optimalen Kompressor.
Bereits komprimierte Daten (Videos, Bilder, komprimierte Datenbank-Formate) profitieren minimal von zusätzlicher Kompression. Verschlüsselte Daten komprimieren nicht - Verschlüsselung produziert gleichverteilte Byte-Streams ohne komprimierbare Muster. Kompression muss vor Verschlüsselung erfolgen für effektive Speicher-Einsparungen.
Katastrophen-Wiederherstellungs-Szenarien regelmäßig testen
Ungetestete Sicherungen sind wertlos - Wiederherstellungs-Prozesse können fehlschlagen durch falsche Berechtigungen, fehlende Abhängigkeiten oder inkompatible Versionen. Regelmäßige Wiederherstellungs-Tests verifizieren Backup-Integrität und dokumentieren funktionierende Wiederherstellungs-Workflows.
Minimum-Test-Frequenz: Quartalsweise komplette Katastrophen-Wiederherstellungs-Simulation auf separater Hardware. Teste Wiederherstellung von allen drei Backup-Orten (lokal, NAS, extern) um diverse Fehler-Modi abzudecken. Dokumentiere Wiederherstellungs-Dauer für realistische Wiederherstellungszeit-Ziel-Planung.
Teil-Wiederherstellungen testen spezifische Wiederherstellungs-Szenarien: Einzelne Tabelle aus PostgreSQL-Dump wiederherstellen, spezifischer Zeitpunkt aus Transaktionsprotokoll-Archiv rekonstruieren, korrupte Datenbank-Seite aus physischer Sicherung ersetzen. Diese Tests identifizieren Lücken in der Backup-Abdeckung bevor echte Katastrophen passieren.
Automatisierung und Testing: Der nächste Artikel behandelt zeitbasierte Ausführung, Rotations-Mechanismen und Verifikations-Workflows.
