Entscheidung: Welche Backup-Strategie?

Eine Backup-Strategie wird durch Abwägen von drei Faktoren gewählt: wie viel Datenverlust du tolerieren kannst (RPO), deine Datengröße und wie schnell du wiederherstellen musst (RTO). Keine Methode passt für jedes Szenario. Ausgehend vom RPO-Ziel führt dich dieser Baum zwischen logischen Dumps, physischen Backups + PITR und Snapshots und erinnert daran, dass 3-2-1 und Verifizierung nicht verhandelbar sind.

Was ist dein Ziel für Datenverlust (RPO)?

Beginne mit der entscheidendsten Bedingung: Wie viele Minuten/Stunden an Daten kannst du dir im Katastrophenfall leisten zu verlieren? Ist nahezu null Datenverlust gefordert, ist kontinuierliche Log-Archivierung (PITR) Pflicht; ist eine tägliche/wöchentliche Backup-Toleranz akzeptabel, reichen einfachere Methoden. Das RPO gibt den Rahmen der Strategie vor.

• Nahezu null — ich muss zu jedem beliebigen Zeitpunkt zurückkehren können
• Tägliche/periodische Backups (einige Stunden Verlust) sind akzeptabel
• Erinnere mich zuerst an die allgemeine Best Practice (3-2-1 / Verifizierung)

Welche Anforderungen gibt es an Datengröße und Portabilität?

Reichen periodische Backups, ist die nächste Frage Umfang und Zweck: Ist die Datenbank klein/mittelgroß und soll das Backup in eine andere Umgebung/Version portierbar sein, oder sind die Daten groß und dein Hauptanliegen ist, innerhalb von Minuten wieder zu laufen? Das entscheidet zwischen logischem Dump und Snapshot.

• Klein/mittel, portabel und versionsübergreifend kompatibel
• Große Daten, Wiederherstellung muss sehr schnell sein (niedrige RTO)

Empfehlung: logischer Dump

Exportiert Daten auf logischer Ebene (Schemadefinitionen + Zeilen); die Ausgabe ist entweder SQL/Text (pg_dump im Plain-Format, mysqldump) oder ein werkzeugspezifischer Binär-Dump (pg_dump -Fc, Oracle Data Pump). Eine flexible und portable Methode für kleine und mittlere Datenbanken, Migrationen, Versionsupgrades und die Wiederherstellung ausgewählter Tabellen/Objekte.

Empfehlung: physisches Backup + WAL/Archivlogs (PITR)

Du erstellst regelmäßig physische Basis-Backups und archivierst die Transaktionslogs (WAL/Redo/binlog) kontinuierlich. So kannst du Point-in-Time-Recovery zu jedem Zeitpunkt durchführen und den Datenverlust auf nahezu null senken.

Empfehlung: Snapshot

Erstellt einen Snapshot der Daten auf Blockebene in der Storage- oder Virtualisierungsschicht. Backup und Restore sind selbst bei sehr großen Datenbanken sehr schnell; es hängt aber von der Infrastruktur ab und erfordert sorgfältigen Einsatz.

Empfehlung: 3-2-1-Regel + Offsite + verpflichtende Verifizierung

Welche Methode du auch wählst, diese Prinzipien gehören über die Strategie. Die bloße Existenz eines Backups reicht nicht; es muss auf verschiedenen Medien, an einem anderen Ort liegen und regelmäßig getestet werden. Das ist ein Rahmen, der alle obigen Optionen ergänzt.