Offsite Backup Strategien nach der 3-2-1-Regel

1. Die 3-2-1-Regel erklaert: drei Kopien, zwei Medien, ein Offsite-Ziel

Die 3-2-1-Regel ist die am weitesten verbreitete Formel fuer belastbare Backup-Strategien und der Ausgangspunkt jedes Offsite Backup Konzepts. Sie fordert drei Kopien der Daten: das Original in Produktion und zwei weitere Sicherungen. Diese Kopien sollen auf mindestens zwei unterschiedlichen Medienarten liegen, etwa lokale Platte und Object Storage, damit ein Fehler in einer Technologie nicht automatisch alle Kopien betrifft. Und mindestens eine Kopie muss offsite liegen, physisch getrennt vom Hauptstandort.

Das Offsite Backup ist damit kein optionales Extra, sondern der Kern der Regel, ohne den die anderen beiden Kopien bei einem lokalen Ereignis wertlos werden. Ein Serverraum, der abbrennt, nimmt sowohl das Produktivsystem als auch ein lokal danebenstehendes Backup-NAS gleichzeitig mit. Ein Offsite Backup, sei es in einer anderen Filiale, einem zweiten Rechenzentrum oder einem Cloud-Object-Storage, uebersteht dieses Szenario, weil es physisch nicht im selben Gebaeude liegt.

2. Warum ein zweites lokales Backup allein nicht ausreicht

Viele Teams verwechseln ein zweites lokales Backup mit einer vollstaendigen Backup-Strategie. Ein NAS im selben Serverraum wie der Produktivserver schuetzt zuverlaessig vor einem einzelnen Festplattendefekt, aber nicht vor den Ereignissen, die in der Praxis am haeufigsten zu vollstaendigem Datenverlust fuehren: Ransomware, die sich ueber das Netzwerk auf alle erreichbaren Freigaben ausbreitet, ein Stromausfall mit Ueberspannungsschaden, ein Diebstahl oder ein Wasserschaden im Serverraum. Genau fuer diese Faelle ist ein Offsite Backup unverzichtbar.

Ransomware ist dabei das relevanteste Bedrohungsszenario der letzten Jahre. Moderne Verschluesselungstrojaner suchen aktiv nach erreichbaren Netzlaufwerken und Backup-Freigaben und verschluesseln diese gezielt mit, bevor sie die eigentlichen Produktivdaten angreifen, um genau die Wiederherstellung zu verhindern, die ein Offsite Backup sonst ermoeglichen wuerde. Ein Offsite Backup, das nicht dauerhaft als beschreibbares Netzlaufwerk eingebunden ist, sondern nur fuer den Transfer kurzzeitig authentifiziert wird, entzieht sich diesem Angriffsmuster.

3. Medienvielfalt praktisch umsetzen

Die zweite Saeule der 3-2-1-Regel, zwei unterschiedliche Medienarten, laesst sich auf einem typischen Linux-Server-Setup gut abbilden. Die erste Kopie liegt meist lokal auf einem RAID-Array oder einer zweiten Festplatte im selben Server fuer schnelle Restores kleinerer Probleme. Die zweite Kopie sollte auf einer strukturell anderen Technologie liegen: ein NAS im eigenen Netz mit anderem Dateisystem, oder direkt Cloud-Object-Storage wie S3, Backblaze B2 oder Wasabi. Genau dieses Cloud-Ziel uebernimmt in der Praxis meist gleichzeitig die Rolle des Offsite Backup.

Wichtig ist, dass die Medienvielfalt nicht nur physisch, sondern auch im Zugriffspfad besteht. Zwei Backup-Ziele, die beide ueber dieselben Zugangsdaten und denselben Netzwerkpfad erreichbar sind, teilen ein gemeinsames Risiko: kompromittierte Zugangsdaten treffen beide gleichzeitig. Ein robustes Offsite Backup nutzt deshalb eigene, moeglichst eingeschraenkte Zugangsdaten, die nur Schreibrechte fuer neue Objekte besitzen, aber keine Loeschrechte fuer bereits existierende.

4. Offsite-Transport automatisieren mit rclone

rclone ist das Standardwerkzeug, um ein Offsite Backup von einem Linux-Server aus zu einem Cloud-Object-Storage zu synchronisieren. Es unterstuetzt praktisch alle relevanten S3-kompatiblen Anbieter ueber ein einheitliches Kommandozeileninterface und bietet mit rclone sync einen inkrementellen Abgleich, der nur veraenderte oder neue Dateien uebertraegt. Fuer ein zuverlaessiges Offsite Backup gehoert rclone in einen systemd-Timer statt in einen einfachen Cron-Eintrag, weil systemd bessere Log-Integration und Fehlerbehandlung bietet.

Ein haeufiger Fehler bei der Automatisierung: rclone sync spiegelt das Ziel exakt auf den Quellzustand, loescht also auch Dateien im Offsite Backup, die lokal geloescht wurden. Das ist bei versehentlichem lokalem Datenverlust gefaehrlich, weil sich der Fehler sonst sofort ins Offsite Backup fortpflanzt. Die Loesung ist rclone sync mit einer Backup-Directory-Option, die geloeschte oder ueberschriebene Dateien in einen separaten Ordner statt sie endgueltig zu entfernen, sowie eine Versionierung auf Seiten des Object Storage.

#!/usr/bin/env bash
# offsite-sync.sh — 3-2-1 offsite backup with rclone
set -euo pipefail

readonly LOCAL_SOURCE="/var/backup/nightly"
readonly REMOTE="offsite-s3:mironsoft-backups/$(hostname)"
readonly DELETED_ARCHIVE="offsite-s3:mironsoft-backups-deleted/$(hostname)/$(date +%Y%m%d)"
readonly LOG_FILE="/var/log/offsite-sync.log"

# --backup-dir keeps deleted/overwritten files instead of removing them outright
rclone sync "$LOCAL_SOURCE" "$REMOTE" \
  --backup-dir "$DELETED_ARCHIVE" \
  --transfers 8 \
  --checkers 16 \
  --fast-list \
  --log-file "$LOG_FILE" \
  --log-level INFO

exit_code=$?
if [[ $exit_code -ne 0 ]]; then
  echo "[ERROR] Offsite sync failed with code $exit_code" >&2
  exit "$exit_code"
fi

echo "[OK] Offsite backup synced to $REMOTE"

5. Bandbreite und Kosten kalkulieren

Ein realistisches Offsite Backup Budget muss Bandbreite, Speicherkosten und Egress-Gebuehren gemeinsam betrachten. Die erste vollstaendige Uebertragung eines Offsite Backup, die Erstsicherung, ist der bandbreitenintensivste Schritt und kann bei mehreren Terabyte Daten je nach Uplink Tage dauern. Danach reduziert sich das taegliche Volumen durch inkrementelle Syncs meist auf einen Bruchteil, solange sich Nutzdaten nicht komplett aendern.

Bei der Anbieterwahl fuer das Offsite Backup lohnt der Blick auf Egress-Kosten, also Gebuehren fuer das Herunterladen der Daten im Ernstfall. Manche Anbieter kalkulieren Speicher guenstig, verlangen aber hohe Gebuehren fuer den Abruf im Restore-Fall, was das Offsite Backup im entscheidenden Moment teuer macht. Anbieter mit egress-freien Modellen sind fuer Disaster-Recovery-Szenarien oft die wirtschaftlichere Wahl, auch wenn die reine Speichergebuehr geringfuegig hoeher liegt.

6. Unveraenderliche Kopien gegen Ransomware

Der wirksamste Schutz eines Offsite Backup gegen Ransomware ist Unveraenderlichkeit, technisch als Object Lock oder WORM (Write Once Read Many) umgesetzt. Dabei wird ein hochgeladenes Objekt fuer eine definierte Zeitspanne gegen Ueberschreiben und Loeschen gesperrt, selbst mit den Admin-Zugangsdaten des Kontos. Ein Angreifer, der Zugriff auf die Backup-Zugangsdaten erlangt, kann das bestehende Offsite Backup dann zwar theoretisch mit neuen, verschluesselten Daten ueberschreiben wollen, die gesperrten aelteren Versionen bleiben aber unangetastet erhalten.

Die Object-Lock-Funktion ist bei den meisten S3-kompatiblen Anbietern als Compliance- oder Governance-Modus verfuegbar und muss beim Anlegen des Buckets aktiviert werden, eine nachtraegliche Aktivierung ist meist nicht moeglich. Fuer ein Offsite Backup mit Ransomware-Schutz sollte die Sperrfrist mindestens so lang gewaehlt werden, wie realistischerweise zwischen einer Kompromittierung und ihrer Entdeckung vergeht, in der Praxis oft 30 bis 90 Tage.

#!/usr/bin/env bash
# verify-object-lock.sh — confirm offsite bucket enforces immutability
set -euo pipefail

readonly BUCKET="mironsoft-backups"
readonly TEST_KEY="object-lock-test-$(date +%s).txt"

echo "test payload" > /tmp/lock-test.txt

# Upload with a 30-day compliance retention lock
aws s3api put-object \
  --bucket "$BUCKET" \
  --key "$TEST_KEY" \
  --body /tmp/lock-test.txt \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "$(date -u -d '+30 days' +%Y-%m-%dT%H:%M:%SZ)"

# Deletion must fail while the retention period is active — that failure is the proof
if aws s3api delete-object --bucket "$BUCKET" --key "$TEST_KEY" 2>/dev/null; then
  echo "[FAIL] Object was deletable — object lock is NOT enforced" >&2
  exit 1
else
  echo "[OK] Deletion correctly blocked — object lock is enforced"
fi

rm -f /tmp/lock-test.txt

7. Verschluesselung und Zugriffskontrolle fuer Offsite-Ziele

Ein Offsite Backup verlaesst die physische Kontrolle des eigenen Rechenzentrums, deshalb ist Verschluesselung hier kein optionales Extra, sondern Grundvoraussetzung. Die Uebertragung sollte ausschliesslich per TLS erfolgen, was rclone gegen S3-kompatible Endpunkte standardmaessig sicherstellt. Fuer die Daten selbst empfiehlt sich clientseitige Verschluesselung vor dem Hochladen, etwa mit rclone crypt als verschluesselnder Remote-Layer, sodass der Cloud-Anbieter selbst niemals unverschluesselte Daten zu Gesicht bekommt.

Die Zugriffskontrolle fuer das Offsite-Ziel sollte nach dem Prinzip geringster Rechte konfiguriert sein: eigene IAM-Zugangsdaten pro Server, beschraenkt auf genau einen Bucket-Prefix, mit Schreibrecht fuer neue Objekte, aber ohne Loeschrecht, kombiniert mit der in Abschnitt sechs beschriebenen Object-Lock-Sperre. Zugangsdaten fuer das Offsite Backup sollten niemals in Skripten im Klartext liegen, sondern ueber Umgebungsvariablen aus einem Secret-Store oder zumindest aus einer Datei mit restriktiven Dateiberechtigungen geladen werden.

; rclone.conf — encrypted offsite remote with restricted credentials
; File permissions must be 600, owned by the backup service user only

[offsite-s3]
type = s3
provider = Other
access_key_id = AKIA_OFFSITE_RESTRICTED_KEY
secret_access_key = ${OFFSITE_SECRET_FROM_ENV}
endpoint = s3.eu-central-1.example-cloud.com
region = eu-central-1
acl = private

[offsite-crypt]
type = crypt
remote = offsite-s3:mironsoft-backups-encrypted
filename_encryption = standard
directory_name_encryption = true
password = ${RCLONE_CRYPT_PASSWORD_OBSCURED}

8. Monitoring und Alerting fuer ausbleibende Offsite-Syncs

Ein Offsite Backup, das seit Wochen nicht mehr erfolgreich gelaufen ist, ohne dass es jemandem auffaellt, ist ein stiller Ausfall der gesamten Backup-Strategie. Monitoring fuer das Offsite Backup muss deshalb mindestens drei Dinge pruefen: Ist der letzte Sync erfolgreich abgeschlossen, liegt das letzte erfolgreiche Sync-Datum innerhalb der erwarteten Frequenz, und stimmt die uebertragene Datenmenge groessenordnungsmaessig mit der Quelle ueberein. Ein Sync, der ohne Fehler durchlaeuft, aber aus Versehen ein leeres Verzeichnis synchronisiert, faellt sonst ueber Monate nicht auf.

In der Praxis bewaehrt sich ein Dead-Man-Switch-Muster: Nach jedem erfolgreichen Offsite Backup sendet das Skript ein Signal an einen externen Monitoring-Dienst wie Healthchecks.io oder ein selbst betriebenes Pendant. Bleibt dieses Signal innerhalb eines definierten Zeitfensters aus, loest der Dienst automatisch eine Alarmierung aus, unabhaengig davon, ob das Backup-Skript selbst noch laeuft oder der ganze Server ausgefallen ist.

#!/usr/bin/env bash
# offsite-sync-monitored.sh — dead man's switch for offsite backup health
set -euo pipefail

readonly HEALTHCHECK_URL="https://hc-ping.com/YOUR-UNIQUE-CHECK-ID"
readonly LOCAL_SOURCE="/var/backup/nightly"
readonly REMOTE="offsite-s3:mironsoft-backups/$(hostname)"

# Signal "start" so a hung sync is also detected, not only a missing one
curl -fsS -m 10 --retry 3 "${HEALTHCHECK_URL}/start" || true

if rclone sync "$LOCAL_SOURCE" "$REMOTE" --transfers 8 --checkers 16; then
  # Compare local and remote size as a sanity check against silent empty syncs
  local_size=$(du -sb "$LOCAL_SOURCE" | cut -f1)
  remote_size=$(rclone size "$REMOTE" --json | jq -r '.bytes')

  if (( remote_size < local_size / 2 )); then
    echo "[WARN] Remote size ($remote_size) far below local ($local_size)" >&2
    curl -fsS -m 10 "${HEALTHCHECK_URL}/fail" || true
    exit 1
  fi

  curl -fsS -m 10 --retry 3 "$HEALTHCHECK_URL" || true
  echo "[OK] Offsite backup verified and monitored"
else
  curl -fsS -m 10 "${HEALTHCHECK_URL}/fail" || true
  exit 1
fi

9. Offsite-Optionen im Vergleich

Fuer die konkrete Umsetzung der 3-2-1-Regel stehen mehrere Offsite Backup Optionen zur Wahl, die sich in Kosten, Automatisierbarkeit und Wiederherstellungsgeschwindigkeit deutlich unterscheiden.

Fuer die meisten mittelstaendischen Setups ist rclone zu einem S3-kompatiblen Object Storage mit aktiviertem Object Lock der beste Kompromiss aus Automatisierbarkeit, Ransomware-Schutz und Kosten. Ein Bandlaufwerk bleibt fuer besonders hohe Sicherheitsanforderungen relevant, weil eine wirklich physisch getrennte, nicht dauerhaft vernetzte Kopie kein Angriffsziel im Netzwerk darstellt.

10. Zusammenfassung

Die 3-2-1-Regel bleibt die verlaesslichste Grundformel fuer Backup-Strategien, weil sie drei unabhaengige Fehlerquellen gleichzeitig adressiert: Hardware-Ausfall durch mehrere Kopien, Technologie-Ausfall durch Medienvielfalt und lokale Katastrophen durch ein Offsite Backup. Ein zweites lokales Backup allein schuetzt vor keinem dieser Szenarien vollstaendig, insbesondere nicht vor Ransomware, die gezielt erreichbare Netzlaufwerke mitverschluesselt.

Ein modernes Offsite Backup kombiniert automatisierten Transport mit rclone, Object Lock fuer Unveraenderlichkeit, clientseitige Verschluesselung und ein Dead-Man-Switch-Monitoring, das ausbleibende Syncs sofort meldet. Wer diese vier Bausteine konsequent umsetzt, hat ein Offsite Backup, das nicht nur existiert, sondern im Ernstfall auch tatsaechlich nutzbar ist.

11. FAQ: Offsite Backup nach der 3-2-1-Regel