Ein Backup ist eine Kopie von Daten, Konfigurationen oder Systemzuständen, die zu einem definierten Zeitpunkt erstellt und an einem vom Original getrennten Ort gespeichert wird – mit dem Ziel, im Falle von Datenverlust, Datenbeschädigung, versehentlichem Löschen oder einem Cyberangriff den früheren Zustand wiederherstellen zu können. Backup ist der Schutz vor Datenverlust, während Redundanz und Failover den Schutz vor Systemausfall bieten.
Redundanz ersetzt kein Backup: Ein fehlerhafte Datenbanktransaktion, die Datensätze korrumpiert, wird sofort auf alle Replicas gespiegelt – alle Kopien sind beschädigt. Ein Ransomware-Angriff verschlüsselt alle erreichbaren Daten einschließlich Live-Replicas. Backups, die zeitlich und örtlich getrennt aufbewahrt werden, sind der einzige Schutz gegen diese Szenarien.
Backup-Typen
Voll-Backup
Komplette Kopie aller Daten. Zeitaufwändig, aber einfachste Wiederherstellung. Typisch: wöchentlich.
Inkrementell
Nur seit letztem Backup geänderte Daten. Schnell, aber komplexere Wiederherstellung (Kette). Täglich.
Differenziell
Alle seit letztem Voll-Backup geänderten Daten. Kompromiss: schneller als Voll, einfacher als inkrementell.
Snapshot
Point-in-Time-Abbild des Systemzustands – oft in Sekunden erstellt. Datenbank- oder VM-Snapshots.
Kontinuierlich
Jede Änderung wird sofort gesichert (CDC/WAL). Minimaler Datenverlust bei Wiederherstellung (RPO ≈ 0).
Offsite/Cloud
Backup auf externem Speicher oder Cloud-Storage. Schützt vor lokalem Totalverlust (Brand, Hochwasser).
Die 3-2-1-Backup-Regel
Die bewährte 3-2-1-Regel: 3 Kopien der Daten (Original + 2 Backups). Auf 2 verschiedenen Medientypen (z. B. Festplatte + Cloud). An 1 externem Standort (nicht im selben Gebäude). Diese Regel stellt sicher, dass kein einzelnes Ereignis – Hardwareausfall, Feuer, Diebstahl – alle Datenkopien gleichzeitig vernichten kann. Für Automatisierungsplattformen bedeutet das: Datenbank-Backup täglich automatisch in Cloud-Storage (S3, Azure Blob), Workflow-Konfigurationen in Git versioniert, alle Zugangsdaten in einem gesicherten Secret-Manager.
Praxisbeispiel
Ein Automationsdienstleister richtet ein vollautomatisches Backup-System für seine n8n-Infrastruktur ein. Täglich 02:00 Uhr: AWS RDS erstellt automatisch einen Datenbank-Snapshot, der 30 Tage aufbewahrt wird. Täglich 02:30 Uhr: Ein Backup-Skript exportiert alle n8n-Workflow-Definitionen als JSON und committet sie in ein privates Git-Repository. Wöchentlich: Vollständiger pg_dump der Datenbank wird verschlüsselt in einem S3-Bucket in einer anderen AWS-Region gespeichert. Restore-Test quartalsweise: Wiederherstellung auf einem isolierten Testsystem geprobt – letzte Restore-Zeit: 23 Minuten. Das Backup-System wurde noch nie im Ernstfall gebraucht. Es wurde zweimal im Probefall gebraucht: einmal für ein versehentlich gelöschtes Workflow-Set, einmal für eine korrupte Datenbankmigrierung.
