Die 3-2-1-Backup-Regel: So verlieren Sie Server-Daten nie wieder

Server stürzen ab. Festplatten gehen kaputt. Ein falscher Befehl wird eingegeben. Ransomware schlägt zu. Keines dieser Ereignisse hat Wahrscheinlichkeit null — die Frage ist nur wann. Die richtige Frage zu Ihrem Server lautet nicht “Brauche ich Backups?”, sondern “Mit welcher Strategie?” Dieser Beitrag behandelt die 3-2-1-Backup-Regel — den Goldstandard der Unternehmenswelt — und ihre Anwendung.

Was ist 3-2-1?

Die 3-2-1-Regel ist eine vom US-CERT empfohlene Backup-Strategie, die weltweit Millionen Organisationen als Grundreferenz dient. Die drei Zahlen stehen für:

• 3: Insgesamt 3 Kopien — Original + 2 Backups
• 2: Auf 2 verschiedenen Medientypen (z. B. SSD + HDD, oder Disk + Cloud Object Storage)
• 1: Mindestens 1 Kopie off-site (an anderem physischem Ort)

Logik einfach: An einem Ort konzentrierte Daten gehen mit einem einzigen Fehler verloren. 3-2-1 baut Resilienz gegen jedes Verlustszenario auf.

Warum so kritisch?

Bedrohung	Ohne 3-2-1	Mit 3-2-1
Plattenfehler	Alle Daten weg	Restore aus anderer Kopie
Ransomware	Verschlüsselt, Sie zahlen	Restore aus Off-site-Backup
Menschlicher Fehler (falsches DROP TABLE)	Daten gelöscht	Restore aus früherem Snapshot
Brand im Rechenzentrum	Alles vorbei	Restore aus Off-site-Standort
Hosting-Insolvenz	Service abgeschaltet	Lokale Kopie bleibt

Laut IBM-Bericht 2024 betragen die durchschnittlichen Kosten einer Datenpanne 4,88 Mio. $. Die meisten Unternehmen überstehen das nicht — 60 % der Unternehmen, die ohne Backups Daten verlieren, schließen innerhalb von 6 Monaten.

3-2-1 in der Praxis

Szenario: Ein E-Commerce-Shop auf WordPress + MySQL

Kopie 1 — Live-Server (Original)

• WordPress-Dateien + MySQL-DB auf NVMe-SSD
• Das ist kein Backup, sondern die laufende Kopie

Kopie 2 — Gleicher Server, separate Disk / RAID

• Disk-Level-Mirror mit RAID 1 oder RAID 10
• Sofort-Failover bei Plattenfehler
• Tägliche automatische Snapshots

Kopie 3 — Off-site (anderer Standort, anderes Medium)

• Cloud Object Storage (Backblaze B2, AWS S3, Wasabi)
• Oder Backup-Server in anderem Rechenzentrum
• Verschlüsselte Übertragung (rsync über SSH, restic oder borgbackup)
• Wöchentlich voll + täglich inkrementell

Backup-Automation — einfaches Cron-Beispiel

Minimales Backup-Skript für WordPress + MySQL:

#!/bin/bash
DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backup"
DB_NAME="wordpress"
DB_USER="root"
SITE_DIR="/var/www/html"
REMOTE="user@backup-server:/backups/wp/"

# 1. Datenbank-Dump
mysqldump -u $DB_USER --single-transaction $DB_NAME | gzip > $BACKUP_DIR/db-$DATE.sql.gz

# 2. Dateibackup (inkrementelles tar)
tar --listed-incremental=$BACKUP_DIR/snapshot.snar -czf $BACKUP_DIR/files-$DATE.tar.gz $SITE_DIR

# 3. Off-site-Sync (verschlüsseltes rsync)
rsync -az --delete $BACKUP_DIR/ $REMOTE

# 4. Backups älter als 30 Tage löschen
find $BACKUP_DIR -name "*.gz" -mtime +30 -delete

Über /etc/cron.d/backup jede Nacht um 03:00 Uhr starten:

0 3 * * * root /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Profi-Tools

In Produktivumgebungen schlagen Enterprise-Tools Ad-hoc-Skripte:

• Veeam Backup — Branchenstandard, von KavesNET genutzt
• restic — Open Source, Deduplication + Verschlüsselung integriert
• BorgBackup — inkrementell, verschlüsselt, dedupliziert
• Duplicati — benutzerfreundlich mit GUI

Der kritischste Schritt: Restore-Test

Ein Backup, das Sie nicht zurückspielen können, ist nichts wert. Dieser Schritt wird in 3-2-1 am häufigsten übersprungen.

• Backup einmal monatlich in Testumgebung restoren
• Restore-Zeit messen (RTO — Recovery Time Objective)
• Datenintegrität prüfen

Ein ungetestetes Backup ist ein Mythos. Die Anzahl derjenigen, die in der Produktion sagen “Wir hatten Backups, konnten aber nicht restoren” ist nicht kleiner als die ohne Backups.

KavesNETs Backup-Infrastruktur

KavesNET-Server enthalten standardmäßig kostenlos:

• RAID10 — sofortiger Schutz auf Disk-Ebene
• Tägliche automatische Backups via Veeam auf externe Backup-Server
• 7 Tage Aufbewahrung
• Restore mit einem Klick per Support-Ticket
• Backup-Server in separatem Netzwerk mit redundanten 10 Gbit/s-Links

Damit sind Punkte 2 und 3 von 3-2-1 bereits abgedeckt. Für S3-kompatible Off-site-Cloud-Backups schreiben Sie uns.

Häufige Backup-Fehler

1. Backup auf derselben Disk — Disk weg, Backup auch
2. Nur manuelle Backups — wird vergessen, das letzte ist 6 Monate alt
3. Unverschlüsselte Übertragung — Backup-Server gehackt = alle Daten offen
4. Restore-Tests ausgelassen — versagt am entscheidenden Tag
5. Zu lange Aufbewahrung — Storage verschwendet; Rotation 7-30-90 Tage
6. Nur Datenbank gesichert — uploads/, .htaccess, Config-Dateien vergessen

Fazit

3-2-1-Backup ist keine technische Vorliebe, sondern eine Notwendigkeit für Geschäftskontinuität. Unternehmen, die Daten verlieren und schließen, sind nicht die, die von der Regel gehört, sondern die, die sie nicht angewendet haben.

Heute prüfen:

• Wie viele Kopien? (Sollte 3 sein)
• Auf wie vielen Medien? (Sollte 2 sein)
• Off-site-Kopie vorhanden? (Sollte 1 sein)
• Letzter Restore-Test wann? (Höchstens 1 Monat her)

KavesNET-Server decken zwei Beine von 3-2-1 bereits mit RAID10 + Veeam + externen Backup-Servern ab. Server-Pakete ansehen → oder Kontakt aufnehmen für Off-site-Backup-Architektur.

Verwandt: VDS vs VPS Unterschied · WordPress-Hosting-Leitfaden