Warum eine einzelne Sicherung nicht reicht
Die meisten Datenverluste passieren nicht durch spektakuläre Hardware-Defekte, sondern durch Kleinigkeiten: ein versehentliches rm -rf im falschen Verzeichnis, ein überschriebener Ordner, ein Datenbank-Dump, der nur die Hälfte enthält, oder eine Ransomware, die sich brav durch alle erreichbaren Laufwerke frisst. Wer nur eine einzige Kopie hat, hat im Ernstfall gar keine.
Die 3-2-1-Regel ist eine simple Faustregel, die genau diese Szenarien abdeckt. Sie ist kein Produkt und kein Tool, sondern eine Denkweise, die du mit ganz normalen Mitteln umsetzen kannst. Hier zeige ich dir, was dahintersteckt und wie eine konkrete Umsetzung aussieht.
Was die 3-2-1-Regel bedeutet
Die Regel besteht aus drei Zahlen, die jeweils ein eigenes Risiko adressieren:
- 3 Kopien deiner Daten: das Original plus zwei Backups. Fällt eine Kopie aus, hast du immer noch zwei. Das schützt vor dem klassischen Fall, dass ausgerechnet die eine Sicherung defekt ist, wenn du sie brauchst.
- 2 verschiedene Medien bzw. Speicherorte: Liegen beide Backups auf derselben Festplatte, hilft dir das bei einem Plattenausfall nichts. Verteile die Kopien auf unterschiedliche Hardware oder unterschiedliche Systeme.
- 1 Kopie ausgelagert (offsite): Mindestens eine Sicherung gehört physisch an einen anderen Ort. Brennt es im Büro, wird eingebrochen oder verschlüsselt eine Ransomware das lokale Netz, bleibt die ausgelagerte Kopie unangetastet.
Das Schöne: Drei Kopien auf zwei Medien mit einer Auslagerung ergeben sich oft fast von selbst, wenn man es einmal sauber aufsetzt.
Ein konkretes Beispiel: lokal plus FTP Storage
Nehmen wir an, du betreibst eine Webseite mit Datenbank und willst sie verlässlich sichern. Eine 3-2-1-konforme Aufteilung kann so aussehen:
- Kopie 1 — das Original: Deine Live-Daten auf dem Server bzw. im Webhosting.
- Kopie 2 — lokal: Ein nächtlicher Download auf deinen Rechner oder ein NAS zu Hause. Das ist dein schnell greifbares Backup für den Alltag.
- Kopie 3 — ausgelagert: Eine Sicherung auf einem separaten Speicher an einem anderen Standort, zum Beispiel einem FTP Storage. Damit erfüllst du gleichzeitig "zweites Medium" und "offsite".
Der Ablauf für die Webseite besteht aus zwei Teilen: Dateien und Datenbank. Die Dateien holst du dir per FTP oder über den Dateimanager, den Datenbank-Inhalt sicherst du als SQL-Dump. Im Dashboard kannst du einen MySQL-Dump herunterladen; auf einem Server mit Shell-Zugriff geht das direkt per Befehl:
mysqldump -u benutzer -p meine_db > backup_$(date +%F).sql
Diese Datei lädst du anschließend auf den ausgelagerten Speicher. Auf einem vServer mit Root-Zugriff bietet sich ein kleines Script an, das den Dump erstellt und per SFTP hochschiebt:
sftp benutzer@dein-storage << 'EOF'
put backup_2026-06-11.sql /backups/web/
EOF
Bei Gameservern gibt es bewusst keine automatischen Hoster-Backups — die Sicherung läuft spiel-intern (etwa über Backup-Mods bei Minecraft oder txAdmin bei FiveM) und per SFTP von dir selbst. Auch hier ist der separate Storage das ideale Auslagerungsziel: Du lädst die Welt- und Konfigurationsdateien herunter und legst sie zusätzlich extern ab.
Automatisieren statt erinnern
Ein Backup, an das du jeden Abend denken musst, ist kein Backup, sondern ein guter Vorsatz. Sorge dafür, dass die Sicherung von allein läuft. Im Webhosting kannst du dafür Cronjobs einrichten, die regelmäßig einen Dump erzeugen. Auf einem vServer übernimmt das ein Cron-Eintrag wie dieser, der das Backup-Script jede Nacht um drei Uhr startet:
0 3 * * * /root/backup.sh
Wichtig: Trenne die Zugangsdaten so, dass dein Live-System nicht uneingeschränkt in dein Backup schreiben kann. Wenn der Server, der gerade kompromittiert wurde, auch alle Sicherungen löschen darf, ist die Auslagerung nur halb so viel wert. Ein eigener, schreibgeschützter oder separat verwalteter Zugang zum Storage erhöht die Widerstandskraft gegen Ransomware deutlich.
Versionierung: mehrere Stände aufheben
Eine einzelne aktuelle Kopie hat eine Schwäche: Wenn ein Fehler unbemerkt bleibt, überschreibst du irgendwann dein gutes Backup mit dem kaputten Stand. Deshalb gehört zur 3-2-1-Regel in der Praxis fast immer Versionierung dazu — also mehrere Sicherungsstände über die Zeit.
Ein bewährtes Schema ist eine gestaffelte Aufbewahrung: die letzten sieben Tage täglich, dann vier Wochen wöchentlich, dann einige Monate monatlich. Dadurch kannst du auch auf einen Stand von vor zwei Wochen zurück, falls ein Problem erst spät auffällt. Der einfachste Weg dafür ist ein Datum im Dateinamen, wie im mysqldump-Beispiel oben mit $(date +%F). So entsteht für jeden Lauf eine eigene Datei, und alte Stände löschst du erst nach Ablauf der Aufbewahrungsfrist.
Der wichtigste Schritt: Restore testen
Ein Backup, das sich nicht wiederherstellen lässt, ist kein Backup. Genau das merkt man aber typischerweise erst im Ernstfall — also dann, wenn es zu spät ist. Plane deshalb von Anfang an ein, die Wiederherstellung regelmäßig auszuprobieren.
Ein realistischer Test sieht so aus: Lade eine Sicherung von deinem ausgelagerten Speicher herunter und spiele sie in einer separaten Umgebung ein — nicht über dein Produktivsystem. Eine Datenbank stellst du etwa so wieder her:
mysql -u benutzer -p test_restore < backup_2026-06-11.sql
Prüfe danach konkret: Sind alle Tabellen da? Stimmt die Anzahl der Datensätze ungefähr? Lassen sich die Dateien öffnen? Auf einem vServer mit der Funktion "Neu-installieren" kannst du gefahrlos ein frisches System aufsetzen und dort den Restore durchspielen, ohne deine echten Daten anzufassen. Wer das ein- bis zweimal im Jahr macht, kennt die Schritte im Notfall auswendig und weiss vor allem, dass die Sicherungen wirklich brauchbar sind.
Mit Nytrix umsetzen
Für die ausgelagerte Kopie eignet sich der FTP Storage von Nytrix gut: ab 2,99 EUR pro TB im Monat, frei wählbar zwischen 200 GB und 5 TB, erreichbar per FTP, FTPS und SFTP. Der Standort ist Nürnberg (DE) und damit getrennt von den Gameservern und dem Webhosting in Eygelshoven (NL) — die räumliche Trennung für deine Offsite-Kopie ist also gleich mitgeliefert.
Auf einem vServer mit vollem Root-Zugriff per SSH richtest du dir das Backup-Script selbst ein; alternativ gibt es Smart Backup als Option für 2,50 EUR einmalig. Im Webhosting über KeyHelp sicherst du per Datei-Download und SQL-Dump, gesteuert über Cronjobs. Datenbanken lassen sich als separate MySQL-Datenbank ab 0,50 EUR im Monat führen und per Dump im Dashboard sichern. Alles läuft prepaid, ohne Mindestlaufzeit und ohne Vertragsbindung — du legst Guthaben auf und buchst genau das, was du für deine 3-2-1-Strategie brauchst. Weitere Praxistipps findest du im Blog.