Das eigene Backup-System bauen – Teil 1: Strategie vor den Skripten

 (it-notes.dragas.net)
3 Punkte von GN⁺ 2025-07-21 | 1 Kommentare | Auf WhatsApp teilen
  • Die Bedeutung von Backups wird oft unterschätzt.
  • Viele verlassen sich bequem auf die Cloud-Abhängigkeit und erkennen ihre Verantwortung für den Schutz von Daten nicht.
  • Wer keinen Backup-Plan erstellt und sich nur auf einfaches Kopieren verlässt, geht ein hohes Risiko ein.
  • Sowohl Backups ganzer Datenträger als auch von einzelnen Dateien haben jeweils Vor- und Nachteile.
  • Für zuverlässige Backups sind die Nutzung von Snapshots und externem Speicher entscheidende Elemente.

Die Bedeutung von Backups und die Realität

  • Backups sind ein Bereich, den viele Menschen nicht ernst genug nehmen.
  • Durch falsche Methoden oder konzeptionelle Irrtümer (z. B. RAID ist kein Backup) gehen unzählige Daten verloren.
  • Daten sind ein wichtiges Gut und müssen unbedingt auf verschiedene Weise bewahrt werden.

Missverständnisse über Cloud und Backups

  • Viele überlassen der Cloud all ihre Daten, ohne zu fragen, wie diese tatsächlich geschützt werden.
  • Auch große Cloud-Anbieter arbeiten mit einem Shared-Responsibility-Modell.
    • Sie sichern die Infrastruktur, aber die Verantwortung für den Schutz der Daten liegt beim Nutzer.
  • Auch in Umgebungen wie Cloud, privaten Servern oder Kubernetes tritt das Risiko fehlender Backups häufig auf.

Erfahrungen des Autors mit Datenwiederherstellung

  • Es gab zahlreiche Fälle von Datenverlust durch Rechenzentrumsbrände, überflutete Serverräume, Erdbeben, Ransomware, böswillige Angriffe und Fehler von Administratoren.
  • Bei mit dem Internet verbundenen Servern (E-Commerce, Mail usw.) sind sowohl Datenintegrität als auch Servicekontinuität wichtig.
  • Ein Backup ist nicht bloß eine Kopie. Insbesondere das Kopieren laufender Datenbankdateien erhöht das Risiko, dass eine Wiederherstellung unmöglich wird.

Unverzichtbare Fragen für die Backup-Strategie

  • „Wie viel Risiko will man in Kauf nehmen?“, „Welche Daten müssen geschützt werden?“, „Wie viel Downtime ist bei Datenverlust akzeptabel?“, „Wie viel Speicherplatz steht zur Verfügung?“
  • Ein Backup auf derselben Maschine ist bei einem Ausfall dieser Maschine nutzlos. Ein Backup auf externem Speicher ist sicherer.
  • Auch praktische Faktoren wie Netzwerkbandbreite, Wiederherstellungsgeschwindigkeit und Speicherplatz müssen berücksichtigt werden.

Gesamter Datenträger vs. dateibasiertes Backup

Backup des gesamten Datenträgers

  • Vorteile
    • Vollständige Wiederherstellung ist möglich. Das System lässt sich schnell in einen früheren Zustand zurückversetzen.
    • In Kombination mit Virtualisierungssystemen besonders nützlich. Proxmox und ähnliche Lösungen unterstützen solche vollständigen Backups einfach.
    • Einige Lösungen unterstützen auch die Wiederherstellung einzelner Dateien aus vollständigen Backups.
  • Nachteile
    • Bei physischen Servern ist Downtime erforderlich.
    • Hoher Speicherverbrauch, da auch unnötige Daten mitgesichert werden.
    • Je nach Eigenschaften des Dateisystems kann es langsam sein oder Kompatibilitätsprobleme geben.

Backup einzelner Dateien

  • Vorteile
    • Möglich mit Standard-Utilities des Systems (tar, cp, rsync usw.).
    • Durch Backup nur der Änderungen lassen sich Speicherplatz und Übertragungsvolumen sparen.
    • Flexibilität bei Einzelwiederherstellung, Migration, Komprimierung und Deduplizierung.
    • Betrieb ohne Unterbrechung des Systems möglich.
  • Nachteile
    • Einfaches Kopieren benötigt viel Speicherplatz.
    • Ohne Snapshots kann ein Backup eines laufenden Dateisystems zu Inkonsistenzen und Fehlern führen.

Backups mit Snapshots

  • Wenn das zu sichernde Dateisystem in Betrieb ist, können sich Daten zwischen „Beginn“ und „Ende“ des Backups ändern, wodurch die Datenkonsistenz verloren geht.
  • Bei offenen Datenbanken wie MySQL oder dem Browserverlauf kann eine Wiederherstellung durch bloßes Kopieren der Dateien unmöglich sein.
  • Um konsistente Backups zu garantieren, sollte zuerst die Snapshot-Funktion des Dateisystems genutzt werden.
  • Gängige Methoden
    • Native Dateisystem-Snapshots (Systeme mit Unterstützung für BTRFS, ZFS)
    • LVM-Snapshots: mögliche Platzverschwendung und potenzielle Systemunterbrechung beim Löschen von Snapshots
    • DattoBD: gelegentliche Stabilitätsprobleme, aber in Kombination mit UrBackup nutzbar

Backup-Ansätze: Push vs. Pull

  • Push: Das zu sichernde System verbindet sich mit dem Server und sendet die Daten.
  • Pull: Ein zentraler Backup-Server verbindet sich mit den einzelnen Servern und führt die Backups aus.
  • Aus Sicherheitsgründen ist ein Pull-Ansatz sicherer, bei dem der Backup-Server externe Zugriffe blockiert und nur bei Bedarf auf Clients zugreift.
    • Um das Löschen von Backup-Daten bei einem Einbruch oder einem Ransomware-Vorfall zu verhindern, werden auch Snapshots des Backup-Servers selbst separat über längere Zeit aufbewahrt.

Wichtige Merkmale eines empfohlenen Backup-Systems

  • Sofortige Wiederherstellung und hohe Geschwindigkeit
  • Speicherung auf externem Speicher (lokale Snapshots bleiben nur für sofortiges Rollback erhalten)
  • Die Nutzung kommerzieller Cloud-Dienste wie Google Drive oder Dropbox wird nicht empfohlen. Daten sollte man selbst besitzen.
  • Effiziente Nutzung des Speicherplatzes durch Komprimierung, Deduplizierung usw.
  • Zusätzliche Komponenten, die für den Betrieb nötig sind, sollten auf ein Minimum reduziert werden.

Geplante Fortsetzung der Serie

  • Geplant ist die Vorstellung verschiedener Backup-Szenarien sowie der tatsächlich genutzten Server, wichtiger Einstellungen und diverser Software- und Techniklösungen.
  • Im nächsten Teil wird behandelt, wie ein Backup-Server auf Basis von FreeBSD aufgebaut wird.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-21
Hacker-News-Kommentare

  • Bei Maschinen, bei denen Backups zwingend per „Push“ erfolgen müssen, sollte man den Zugriff auf den jeweils eigenen Bereich beschränken. Noch wichtiger ist, dass der Backup-Server aus Sicherheitsgründen für eine gewisse Zeit eigene Dateisystem-Snapshots vorhält. So bleiben selbst im Worst Case noch Snapshots auf dem Server erhalten, wenn ein Workload kompromittiert wird, Zugriff auf den Backup-Server bekommt und die Backups für eine Lösegeldforderung löscht. Ich bevorzuge es, Clients nur neue Backups schreiben zu lassen und Löschen komplett zu verbieten; Löschungen laufen dann über ein separates Verfahren, etwa manuell oder per cron. Bei rsync/ssh lässt sich das mit der allowed-command-Funktion in .ssh/authorized_keys umsetzen.

    • Ich nutze beides. Man sollte Backups zwar an zwei Orten aufbewahren, aber genau diese Dual-Backup-Struktur war ohnehin mein Ziel. Die Backup-Quellen pushen an einen Zwischenstandort, und das primäre Backup-Repository pullt von dort. Der Zwischenstandort hält Snapshots, hat aber nur wenig Kapazität. Das primäre Storage und die Quellen authentifizieren sich überhaupt nicht gegenseitig; beide können sich nur gegenüber dem Zwischenstandort authentifizieren, ohne Rückrichtung. Wenn also ein oder zwei dieser drei Orte kompromittiert werden, sind die übrigen mit hoher Wahrscheinlichkeit noch sicher. Zertifikats-Backups behandle ich komplett separat, damit sie nie vollständig auf internetverbundenen Servern liegen. Wirklich wichtige Daten sichere ich zusätzlich noch offline. Die Trennung der Struktur macht echte Backup-Validierung zwar umständlich, aber das Backup-Storage prüft regelmäßig Checksummen und sendet die Ergebnisse an den Zwischenhost, wo sie mit den vom Ursprungshost erzeugten Hashes verglichen werden, um Korruptionsereignisse zu erkennen. So entsteht eine Art „Soft-Offline“-Backup, bei dem die Quelle die Backup-Snapshots selbst nicht direkt beschädigen kann.

    • Eine weitere Möglichkeit ist ein separater Container oder ein dedizierter Backup-Benutzer. Mit systemd-nspawn etwa kann man eine leichte chroot jail aufsetzen, in der man sogar die Ausführung von rm verhindern kann. Man erstellt einfach mit pacman/pacstrap ein chroot und verwaltet es mit systemd-nspawn/machinectl. Dieser Ansatz ist flexibel, weil man ähnlich wie sonst unter systemd Zugriffskontrolle, Pfadbeschränkungen, Speicher-/CPU-Limits, Zugriff nur aus bestimmten IP-Bereichen, feingranulare Boot-Bedingungen und vieles mehr konfigurieren kann. Auch BTRFS-Subvolumes lassen sich nutzen, und falls nötig kann man das ganze System mit systemd-vmspawn vollständig isolieren. Mit importctl ist auch die Replikationsautomatisierung sehr bequem.

    • Ich bevorzuge einen Pull-Ansatz, bei dem der Backup-Server keinerlei Berechtigungen auf dem zu sichernden Server hat. Selbst wenn auf dem Live-Server Root kompromittiert wird, hat das keine Auswirkungen auf das Backup-System.

    • Ich verwende für Backups rclone copy und nutze nur API-Schlüssel ohne Berechtigung zum Löschen von Objekten. Mit einer Synchronisierung wie rclone sync könnte man versehentlich alles löschen, daher ist dieser Ansatz sicherer.

    • Ich wünschte, syncoid hätte auch eine Option, bei der „der Client nur Snapshots/Backups kopiert und Löschungen direkt vom Backup-Server verwaltet werden“. Im Moment muss man Löschrechte vergeben, was ich schade finde.

  • Erstaunlich viele Menschen nehmen Backups nicht ernst, egal ob in großen oder kleinen Unternehmen. Ein von mir beratenes Unternehmen mit 1 Milliarde Euro Jahresumsatz hatte nicht einmal eigene Backups und verließ sich nur auf unregelmäßige Disk-Kopien des Rechenzentrumsanbieters. Wiederherstellungstests hatten sie nie selbst durchgeführt. Vor Kurzem wurde durch einen Benutzerfehler die Produktionsdatenbank vollständig gelöscht, und das neueste Backup war vier Tage alt, sodass alle Transaktionen dazwischen rekonstruiert werden mussten. Und obwohl so ein Vorfall passiert war, war niemand schockiert; alles lief einfach weiter wie immer.

    • Offenbar hält man das für akzeptabel, solange es das Geschäft nicht wirklich kritisch trifft.

    • Häufig sieht man auch, dass Backup-Anforderungen unnötig kompliziert gemacht werden.

    • Vielleicht steckt auch ein rechtliches Problem dahinter. Wegen Klagen oder gesetzlicher Aufbewahrungspflichten können Backups selbst zu einem Risikofaktor werden.

    • Das ist eine Nebenwirkung von Disaster-Recovery-Richtlinien, die ein SOC2-Audit bestanden haben. In einer Firma, in der ich gearbeitet habe, wurden die Disaster-Recovery-Richtlinien aller Teams geprüft, alle SOC2-abgenommen. Das Ergebnis war letztlich, dass man bei einem echten Großvorfall die Firma eher schließen und nach Hause gehen würde, weil das schneller wäre als eine normale Wiederherstellung.

    • Falls der komplette Verlust von vier Tagen Produktions-DB-Daten wirklich stimmt, würde ich gern wissen, ob die Kunden nicht wütend waren. Bei einem Unternehmen dieser Größe klingt das nach einem massiven Einschlag, deshalb würde mich interessieren, wie man das praktisch gelöst hat.

  • Danke fürs Teilen. Ich entwickle seit zehn Jahren Software für Backup und Disaster Recovery, und ein Spruch, der immer wieder fällt, lautet: „Einem Freund würde ich nie raten, seine Backup-/Disaster-Recovery-Lösung selbst zu bauen.“ Beim Aufbau von BCDR lauern einfach zu viele Fallstricke, die man leicht übersieht. Ein paar Kernpunkte dazu: Ein Backup ist nicht gleich „Disaster Recovery“. Im Ernstfall muss innerhalb von Minuten bis Stunden wiederhergestellt werden, damit das Vertrauen ins Geschäft erhalten bleibt. Entscheidend sind RTO und RPO. Reine Dateireplikation per rsync copy ist kein Point-in-Time-Backup, weil sich das Dateisystem laufend verändert. Für ein echtes Point-in-Time-Backup braucht man ein „crash-consistent“ oder „application-consistent“ Backup; Letzteres bedeutet, dass wichtige Anwendungen ihren Zustand auf die Platte schreiben und während des Backups angehalten werden. Funktionen wie Microsoft VSS decken genau diesen Bereich ab. Man sollte rsync copy oder crash-konsistenten Backups niemals blind vertrauen. Für Storage gilt immer Murphys Gesetz, deshalb braucht man zwingend Backups an mehreren Orten, also die 3-2-1-Strategie. Aus eigener Erfahrung geht früher oder später jede Art von Datenträger kaputt. NVMe SSD > SSD > HDD ist zwar tendenziell robuster, aber Ausnahmen gibt es nicht. Ich hätte noch mehr zu sagen, aber es ist spät, daher belasse ich es dabei.

    • Die 3-2-1-Analogie ist eher ein älteres Modell. Heute sind Datenspeicherorte praktisch unbegrenzt, daher sind lokale Snapshots, Remote-Replikation und doppelte oder dreifache Backups mit unterschiedlichen Methoden noch wichtiger. Ich nutze standardmäßig ZFS-Snapshots und zusätzlich Borg; mit dieser Kombination ist man für fast jede Katastrophe gut aufgestellt.

    • Dieser Spruch erinnerte mich an etwas Ähnliches, das ich einmal bei einem Alice-in-Chains-Konzert gehört habe. BCDR-Lösungen sind ein Symbol für Vertrauen zwischen Unternehmen. Solche Systeme schützen Daten im Wert von zig bis hunderten Billionen, und kein CTO würde Firmen-Backups jemals einem Open-Source-Ansatz anvertrauen. Die IT-Ausgaben von Unternehmen steigen in der Regel schrittweise entsprechend dem Wert der Assets und einer Strategie gegen Vendor Lock-in. Aus professioneller Sicht sind bei Ransomware-Schutz Unveränderlichkeit und WORM-Backups entscheidend, und ich habe viele Fälle gesehen, in denen Nichteinhaltung von Vorschriften in staatlicher IT Probleme verursachte. BCDR-Anbieter nutzen Ransomware zwar als Verkaufsargument, aber echte Immutability zeigt sich erst bei Datenreplikation über mehrere Orte hinweg. Genau dort spielt die 3-2-1-Strategie ihre Stärke aus. Ich würde gern mehr Meinungen zu weiteren Backup-Prinzipien hören.

    • Wer ein NAS benutzt, sollte auf beiden Seiten besser keine Festplatten desselben Herstellers und desselben Modells verwenden.

    • Der Aussage „Backups an mehreren Orten sind Pflicht (3-2-1)“ stimme ich voll zu. Für die meisten Privatpersonen ist die „1“ (Offsite) aber praktisch kaum machbar, und am Ende gibt es ohne Backup-Service kaum noch einen Grund, das selbst zu betreiben. Ich kenne niemanden, der außerhalb meiner Stadt rund um die Uhr einen Rechner für mich laufen und administrieren lassen würde.

    • Was den Teil „Man sollte rsync copy oder sogar crash-konsistenten Backups niemals vertrauen“ angeht: Im Ergebnis heißt das doch, dass sich alle Systeme/Dienste mit Infrastruktur-Tools neu aufbauen lassen und man nur Datenbanken sowie Datei-/Objektspeicher aktiv sichern muss. Komplizierte Komplett-Backups ganzer VMs bringen dann eigentlich wenig.

  • Schöner Artikel, aber an einer Stelle fehlt mir etwas: Ein wirklich gutes Backup-System braucht klare Anforderungen an Wiederherstellungsgeschwindigkeit und -verfahren. Ich habe mehrfach erlebt, dass man sich mit dem Gedanken „Die Backups laufen ja“ in Sicherheit wiegte, um dann im Ernstfall festzustellen, dass nur ein Teil wiederherstellbar ist oder die Wiederherstellung mehrere Tage dauert und enormen Schaden verursacht. Das Tool restic ermöglicht deduplizierte Snapshot-Backups auf Dateiebene und ist nützlich, wenn man kein Snapshot-Dateisystem wie ZFS hat. Und bei „Push“-Backups kann Ransomware im Zweifel auch die Backups löschen, weshalb ein „Pull“-Ansatz sinnvoller ist. Wenn es Push sein muss, dann am besten auf Read-only-Medien wie Blu-ray oder zumindest mit auto-snapshot/ZFS, damit Point-in-Time-Wiederherstellung möglich ist.

    • Auch wenn Ransomware Push-Backups löschen kann, ist das kein Problem, wenn die Serverrechte sauber eingeschränkt sind. Borg und Restic können per ssh Append-only garantieren, und lokal rotiere ich als letzte Verteidigungslinie Offline-Backup-Laufwerke. Eine konkrete Vorgehensweise findet sich hier.

    • Ich frage mich, ob Restics Append-only-Modus ausreicht, wenn periodisches Pruning ausschließlich serverseitig erfolgt und man daher keinen Pull-Ansatz braucht. Soweit ich weiß, ist das die offizielle Restic-Empfehlung zum Schutz vor Ransomware.

    • „Wiederherstellungsgeschwindigkeit“ hängt wirklich stark von den Anforderungen ab. Wenn die Wiederherstellung meiner Familienfotos sechs Monate dauert, wäre das für mich in Ordnung.

    • Statt Read-only-Medien kann auch ein Push-Server mit eingeschränkten Rechten eine Alternative sein. Man kann zum Beispiel per ssh nur scp erlauben, auf eine chroot-Umgebung begrenzen und täglich in rotierende Ordner sichern. Dann kann selbst Ransomware keine alten Daten löschen. Meine Backups verwalte ich ebenfalls über einen ssh-Server, der nur chroot + scp erlaubt, zusätzlich zu Read-only-Medien.

  • Ich brauche eigentlich kein separates Backup-System, sondern eher eine standardisierte Methode, um 25 Jahre Fotos von vier Familienmitgliedern effizient zusammenzuführen — vom Smartphone, aus Kameras, Downloads, Scans und so weiter. Bisher habe ich dafür noch nichts wirklich Zufriedenstellendes gefunden.

    • Ich betreibe Immich auf meinem NAS und sichere die Medien sowie den Immich-DB-Dump täglich nach AWS S3 Deep Archive. Immich bietet genug von dem, was Google Photos kann, und wenn man Desktop-Fotos oder Scans auf dem NAS ablegt, importiert Immich sie automatisch. Für HN-Nutzer ist das Setup nicht besonders schwierig.

    • Als Witz würde ich erst mal fragen, ob „25 Jahre Fotos“ eine nordamerikanische Dateneinheit ist — tatsächlich brauchst du aber definitiv ein Backup-System. Ich betreibe syncthing als Mesh auf gnu/linux/windows/android, mache regelmäßige Snapshots des Archivs auf zwei Debian-VMs und nutze borgbackup für ein zweites Backup. Mein RPO liegt bei 24 Stunden, könnte aber bei Bedarf kleiner sein. Auf Apple-Geräten passt dieses Setup allerdings nicht gut, weil syncthing im Hintergrund blockiert wird. Bei mir sind es etwa 500 GB Fotos plus zig bis hunderte GB an sonstigen Dokumenten, aber durch diff-basierte Backups ist das effizient.

    • Downloads und Scans sind, wenn sie nicht wirklich wichtig sind, ohnehin Wegwerf-Daten. Smartphones/Kameras synchronisiere ich über Nextcloud und lasse Backups nur im eigenen Heimnetz laufen. Danach gibt es tägliche Backups auf das NAS plus Health Checks. Der letzte Schritt ist ein vertrauenswürdiges Cloud-Backup oder ein Laufwerk in einem anderen Haus. Damit ist dann auch das zweite Backup abgedeckt.

    • Selbstgehostete Lösungen wie PhotoPrism oder Immich sind nützlich für Deduplizierung, Suche und Tagging von Fotos. Für Cloud-Backups kann man Backblaze B2 + Cryptomator nutzen, also verschlüsselten Storage mit einem DIY-Upload-Skript. Das liegt bei etwa 1 Dollar pro TB und Monat.

    • Ich nutze syncthing; offiziell wird Android zwar nicht unterstützt, aber mit einem Fork läuft es gut. Zusätzlich würde ich für Foto-Backups ente.io oder selbstgehostetes Immich empfehlen. Dokumente verwaltet man besser separat, zum Beispiel mit paperless ngx.

  • Dirvish ist ein leichtgewichtiges rsync-Wrapper-Tool, das man sich unbedingt einmal ansehen sollte. Es bietet großartige Funktionen wie Rotation, Inkremente, Aufbewahrung sowie Vor- und Nachverarbeitungsskripte. Seit über 20 Jahren rettet es mir den Daten-Hintern. Es passt auch sehr gut zu den Punkten aus dem Artikel. offizielle Dirvish-Seite, offizielle rsync-Seite

    • Mich würde interessieren, was Dirvish im Vergleich zu rsync einfacher oder besser macht.

  • Ich habe mit einem ziemlich faulen Ansatz trotzdem Hardware-Ausfälle und Diebstahlprobleme abgedeckt: temporärer Speicher im Desktop, externe Festplatte zu Hause und externe Festplatte Offsite, alles Samsung T7 Shield. Mit robocopy /MIR spiegele ich täglich temporär oder nach der Arbeit, einmal pro Woche auf die externe Platte und einmal im Monat tausche ich die Offsite-Platte aus.

    • Externe Festplatten sollten unbedingt aus unterschiedlichen Chargen stammen oder besser noch unterschiedliche Modelle sein. Beim gleichen Modell aus derselben Charge ist die Wahrscheinlichkeit hoch, dass sie ungefähr gleichzeitig ausfallen — besonders wenn bei der Wiederherstellung plötzlich hohe Last anliegt.

  • Das Timing passt gut, deshalb teile ich mal meine archlinux-Konfiguration und Backup-Strategie. Auch meine Konfigurations-/Backup-Automatisierungsskripte und die Borg-Automatisierungsschicht sind öffentlich.

    • Ich automatisiere mit Python + Borg Snapshot-Backups von 51 SAN-Blockgeräten, 71 Dateisystemen und den Sync nach S3. Die Wiederherstellung habe ich Offsite real getestet, bis hin zum erfolgreichen VM-Boot. Die Automatisierung ist noch komplex und unfertig, daher ist die Wiederherstellung langsam, aber ich habe das sehr günstig aufgebaut. Borg ist wirklich mächtig. So etwas kann im Prinzip jeder versuchen, und am Ende ist es sehr kosteneffizient.

  • Meine wertvollen Daten umfassen weniger als 100 MiB. Ich sichere daher nur ausgewählte Pfade als tar + Komprimierung + Verschlüsselung zweimal pro Woche und halte einige Monate in Rotation vor. Ich bewahre sie drinnen und draußen auf und brauche praktisch keine Prüfungen oder Wartung. Mit ein paar Zeilen sh lässt sich das problemlos automatisieren.

    • Wenn ich morgen plötzlich sterben würde, müsste ich mich fragen, welche Daten für Familie und Nachkommen wirklich wert wären, wiederhergestellt zu werden. Vielleicht reichen statt Hunderttausender Dateien auch nur ein paar zentrale Fotos, Videos und Texte.

    • Dieser Kommentar hat mich tatsächlich dazu gebracht, noch einmal darüber nachzudenken, was meine wirklich wertvollen Daten sind. Meine Fotos kommen selbst komprimiert auf mindestens einige GB, Kontakte oder weniger Wichtiges sind klein, und den Rest könnte ich meist verlieren. Meine Recovery-Keys sollte ich sicherer aufbewahren, aber ausgerechnet die wichtigsten Accounts haben keine Recovery-Keys. Allein die Fotos liegen fast bei 2 TB — das Leid eines Hobbyfotografen.

  • Der schwierigste Punkt bei Backup-Konsistenz ist, dass es praktisch unmöglich ist, Anwendungsdaten ohne Service-Downtime konsistent zu sichern. Selbst mit Disk-Snapshots wird man immer den Moment erwischen können, in dem irgendein Dienst mitten in einem Schreibvorgang ist, und dann ist die Chance hoch, dass man bei der Wiederherstellung in einen beschädigten Zustand springt. DB-Dumps entschärfen das zwar erheblich, müssen aber oft außerhalb des Dienstes gemacht werden und können dann ebenfalls mitten in laufenden Queries stattfinden. Falls dazu jemand Best Practices hat, würde ich sie gern hören.

    • Datenbanken sind in diesem Punkt normalerweise ziemlich robust, sodass Disk-Snapshots jederzeit für Backup-Zwecke ausreichen sollten. Sorgen machen würde ich mir eher über Spezialfälle wie Cache ohne Batterie, aber solche Konstruktionen sind heute in Cloud-Umgebungen meist kein großes Thema mehr.

    • Die Strategie hängt auch davon ab, ob es neben der Datenbank noch weiteren Anwendungszustand gibt, der erfasst werden muss, etwa Caches. pg_dump/mysqldump ermöglichen tatsächlich sichere Snapshots einer Live-Datenbank, sind aber teils langsam und erzeugen große Dumps. Um das zu umgehen, habe ich bei großen PostgreSQL-Datenbanken auch schon mit einer dedizierten schreibgeschützten Read-only-Replica gearbeitet, die Replikation angehalten, das Backup durchgeführt und danach die Replikation wieder aufgenommen.