14 typische Backup-Fehler – und wie du sie vermeidest
Von RAID als vermeintlichem Backup bis zum Schlüssel auf dem ausgefallenen Server: die Fehler, die in der Praxis wirklich zu Datenverlust führen.
5 Min. LesezeitReini
Datenverlust entsteht selten dadurch, dass jemand gar nicht an Backups gedacht hat. Er entsteht dadurch, dass an einer bestimmten Stelle eine Annahme getroffen wurde, die sich im Ernstfall als falsch herausstellt.
Diese Liste sammelt die Stellen, an denen das regelmäßig passiert. Wer sie durchgeht, findet in der eigenen Umgebung erfahrungsgemäß mindestens zwei Treffer.
1. RAID für ein Backup halten
Der Fehler: „Die Daten liegen gespiegelt, da kann nichts passieren.“
Warum das nicht stimmt: RAID schützt gegen den Ausfall einzelner Datenträger. Gegen versehentliches Löschen, Ransomware, Dateisystemfehler, Diebstahl, Brand oder einen Controller, der fehlerhafte Daten schreibt, schützt es nicht – all das wird zuverlässig redundant gespeichert.
Richtig: RAID ist Verfügbarkeit, Backup ist Wiederherstellbarkeit. Beides brauchen, keins durch das andere ersetzen. Siehe 3-2-1-Backup-Strategie.
2. Synchronisation für ein Backup halten
Der Fehler: Ein nächtlicher rsync-Job auf ein NAS, ohne Versionierung.
Warum das nicht stimmt: Synchronisation überträgt Änderungen – auch Löschungen und Verschlüsselungen. Was heute Nacht kaputtging, ist morgen früh auf beiden Seiten kaputt.
Richtig: Ein Werkzeug einsetzen, das Versionen aufbewahrt. Siehe restic, Borg oder PBS?.
3. Alle Kopien am selben Ort
Der Fehler: Server und Backup-Platte stehen nebeneinander.
Warum das nicht stimmt: Ein Wasserschaden, ein Brand, ein Einbruch oder ein Überspannungsschaden trifft beide gleichzeitig. Auch der Keller unter dem Serverraum zählt nicht als getrennter Ort.
Richtig: Eine Kopie tatsächlich außer Haus. Siehe Offsite-Backup.
4. Das Backup-Ziel ist vom Produktivsystem löschbar
Der Fehler: Ein SMB-Share, permanent eingehängt, mit Schreib- und Löschrechten.
Warum das nicht stimmt: Ein eingehängtes Laufwerk ist für Schadsoftware ein Laufwerk wie jedes andere – und meist das erste Ziel. Wird das System kompromittiert, sind die Sicherungen mit betroffen.
Richtig: Rechtetrennung. Der Sicherungszugang darf schreiben, nicht löschen. Siehe Ransomware-sichere Backups.
5. Nie einen Restore getestet
Der Fehler: Der Backup-Job ist seit zwei Jahren grün. Zurückgespielt wurde nie etwas.
Warum das nicht stimmt: Ein erfolgreicher Sicherungslauf beweist, dass Daten weggeschrieben wurden. Nicht, dass sie vollständig, konsistent, lesbar und entschlüsselbar sind.
Richtig: Regelmäßig testen, gestaffelt nach Aufwand. Siehe Restore testen.
6. Der Schlüssel liegt auf dem gesicherten System
Der Fehler: Verschlüsselung aktiviert, Schlüssel im Passwortmanager auf demselben Server.
Warum das nicht stimmt: Genau der Server fällt aus. Verschlüsselte Daten ohne Schlüssel sind gleichwertig zu keinen Daten.
Richtig: Drei Kopien des Schlüssels an unabhängigen Orten, mindestens eine davon außerhalb der eigenen Infrastruktur. Siehe Backup-Verschlüsselung.
7. Der stille Ausfall
Der Fehler: Benachrichtigung nur bei Fehlern.
Warum das nicht stimmt: Wenn der Job gar nicht mehr läuft – deaktivierter Timer, Maschine aus, verlorener Cron-Eintrag – passiert nichts. Keine Meldung, kein Fehler, kein Backup.
Richtig: Erfolg aktiv melden, Ausbleiben überwachen. Siehe Backup-Monitoring.
8. Aufbewahrung zu kurz
Der Fehler: Sieben tägliche Stände, sonst nichts.
Warum das nicht stimmt: Probleme, die spät auffallen – schleichende Beschädigung, eine falsche Konfiguration, eine Kompromittierung – sind dann in allen vorhandenen Ständen enthalten. Bei Ransomware liegen zwischen Eindringen und Verschlüsselung oft Wochen.
Richtig: Gestaffelte Aufbewahrung über Tage, Wochen und Monate. Siehe Backup-Aufbewahrung planen.
9. Aufräumen ohne Freigeben
Der Fehler: Alte Stände werden gelöscht, der Speicher bleibt trotzdem voll.
Warum das passiert: Alle deduplizierenden Werkzeuge trennen das Entfernen von
Verweisen vom Freigeben des Speichers – forget und prune bei restic, prune und
compact bei Borg, Prune-Job und Garbage Collection bei PBS.
Richtig: Beide Schritte einplanen und überwachen. Ein volles Ziel ist eine der häufigsten Ursachen für stille Ausfälle.
10. Neue Systeme fehlen in der Sicherung
Der Fehler: Der Backup-Job wurde vor drei Jahren eingerichtet. Seither sind vier VMs dazugekommen.
Warum das nicht auffällt: Es schlägt nichts fehl. Was nicht erfasst wird, erzeugt keinen Fehler – es existiert im Backup schlicht nicht.
Richtig: In Proxmox den Auswahlmodus „alle“ verwenden, statt VMs einzeln zu benennen. Zusätzlich monatlich abgleichen: Ist jedes System, das gesichert werden soll, in der Liste?
11. Datenbanken nur als VM-Snapshot
Der Fehler: Die Datenbank-VM wird gesichert, ein Dump existiert nicht.
Warum das nicht stimmt: Ein Snapshot friert den Zustand der virtuellen Platte ein – auch mitten in einer Transaktion. Die Datenbank startet danach womöglich und meldet beschädigte Tabellen.
Richtig: Guest Agent installieren und Dateisystem-Freeze aktivieren, zusätzlich einen regelmäßigen Dump anlegen und diesen mitsichern. Beides, nicht eines davon.
12. Anwendungsdaten außerhalb der gesicherten Pfade
Der Fehler: Gesichert wird /home und /etc. Die Docker-Volumes liegen unter
/var/lib/docker/volumes.
Warum das nicht auffällt: Bis zum ersten Restore-Versuch gar nicht.
Richtig: Nicht nach Pfaden denken, sondern nach Diensten: Wo liegen die Daten dieses Dienstes? Ein Stufe-1-Restore-Test findet solche Lücken zuverlässig.
13. Cloud-Dienste als gesichert betrachten
Der Fehler: „Die Daten liegen beim Anbieter, der sichert das.“
Warum das nicht stimmt: Anbieter sichern gegen ihren eigenen Ausfall – nicht gegen dein versehentliches Löschen, nicht gegen ein kompromittiertes Konto und schon gar nicht gegen eine Kontosperre. Die Wiederherstellungsfristen der Anbieter sind zudem meist kurz.
Richtig: Auch von fremdgehosteten Diensten eine eigene Kopie ziehen.
14. Das Wissen fehlt, nicht die Daten
Der Fehler: Die Daten sind wiederherstellbar – aber niemand weiß mehr, wie das System konfiguriert war, in welcher Reihenfolge die Dienste starten müssen und wo die Zugangsdaten liegen.
Warum das gravierend ist: Der technisch erfolgreiche Restore hilft nicht, wenn der Wiederaufbau daran scheitert.
Richtig: Dokumentation und Konfigurationsdateien gehören ins Backup – an eine Stelle, die ohne das ausgefallene System erreichbar ist. Und die Reihenfolge der Wiederherstellung gehört aufgeschrieben, bevor man sie braucht. Ein Test der Stufe 4 findet genau diese Lücken: Restore testen.
Kurzcheck
Wenn du wenig Zeit hast, beantworte diese fünf Fragen. Sie decken die schwerwiegendsten Fehler der Liste ab:
- Kann ein einzelnes Ereignis alle meine Kopien vernichten?
- Kann das gesicherte System seine eigenen Sicherungen löschen?
- Wann habe ich zuletzt tatsächlich etwas zurückgespielt?
- Wo liegt mein Verschlüsselungsschlüssel – und komme ich ohne den ausgefallenen Server daran?
- Würde ich es merken, wenn die Sicherung seit vier Wochen nicht mehr läuft?
Jedes unbequeme Ergebnis ist ein konkreter nächster Schritt.