3-2-1-Backup-Strategie umsetzen: Anleitung mit Restic, USB-Disk und S3-Cloud

Die 3-2-1-Backup-Strategie umzusetzen schützt Ihre Daten gegen Hardwaredefekte, Ransomware, versehentliches Löschen, Brand und Diebstahl. Diese Anleitung zeigt, wie Sie die 3-2-1-Backup-Regel auf einem Linux-Server praktisch umsetzen: eine schnelle lokale Kopie mit restic, eine zweite Kopie auf einer externen USB-Festplatte (anderer Medientyp) und eine verschlüsselte Offsite-Kopie in der S3-Cloud bei Wasabi oder Backblaze B2. Am Ende läuft alles automatisiert per Cron, und Sie haben einen geprüften, wiederherstellbaren Backup-Bestand an drei Orten.

Was ist die 3-2-1-Backup-Regel und warum brauchen Sie sie?

Die 3-2-1-Regel ist eine Faustformel für ausfallsichere Backups:

1. 3 Kopien Ihrer Daten insgesamt: das Original plus zwei Backups.
2. 2 verschiedene Medientypen: damit ein medienspezifischer Fehler (z. B. ein fehlerhafter SSD-Controller oder ein USB-Bug) nicht beide Kopien gleichzeitig trifft. Typisch: interne Disk plus externe USB-Festplatte oder Cloud.
3. 1 Offsite-Kopie: mindestens eine Kopie liegt physisch woanders. Schützt gegen Brand, Wasserschaden, Diebstahl und einen lokal verschlüsselnden Ransomware-Angriff.

Erst die Kombination aus schneller lokaler Kopie, unabhängigem Medium und Offsite-Standort schützt zuverlässig. Ein Backup, das Sie nie zurückgespielt haben, ist nur eine Vermutung: Restore-Tests gehören dazu.

Warum Restic als zentrales Tool?

Restic ist ein quelloffenes, plattformübergreifendes Backup-Werkzeug (ein einzelnes Binary). Es verschlüsselt clientseitig (AES-256), dedupliziert, arbeitet mit Snapshots und unterstützt lokale Verzeichnisse, USB-Disks, SFTP und S3-kompatible Object-Storage-Dienste wie Wasabi oder Backblaze B2. Sie nutzen damit dasselbe Werkzeug für alle drei Ziele. Für die USB-Kopie ist alternativ borg möglich; diese Anleitung bleibt bei Restic.

Voraussetzungen

1. Ein Linux-System (Debian/Ubuntu, Fedora oder Arch) mit Root- bzw. sudo-Zugriff; 1 CPU-Kern und 1 GB RAM genügen für kleine Datenbestände, Restic braucht bei großen Repositories mehr RAM für den Index.
2. Eine separate lokale Disk oder Partition für das erste Repository (nicht die Systemplatte).
3. Eine externe USB-Festplatte, mindestens so groß wie die zu sichernden Daten plus etwa 50 % Reserve für Snapshots.
4. Ein S3-kompatibles Cloud-Konto, zum Beispiel Wasabi oder Backblaze B2, mit Access Key, Secret Key, Endpoint und Bucket.
5. restic installiert (Paketquellen oder offizielles GitHub-Release).
6. Ein sicher aufbewahrtes Repository-Passwort; ohne dieses Passwort sind die Backups verloren.

Schritt 1: Restic installieren und Verzeichnisse vorbereiten

Installieren Sie Restic über die Paketverwaltung Ihrer Distribution:

# Debian / Ubuntu
sudo apt update
sudo apt install -y restic

# Fedora
sudo dnf install -y restic

# Arch Linux
sudo pacman -S restic

# Version prüfen
restic version

Legen Sie das Repository-Passwort in eine nur für root lesbare Datei. Alle folgenden Befehle führen Sie als root aus (sudo -i), da die Datei sonst nicht lesbar ist:

sudo mkdir -p /etc/restic
# Starkes Passwort erzeugen und speichern (einmalig, sicher aufbewahren!)
openssl rand -base64 32 | sudo tee /etc/restic/password.txt > /dev/null
sudo chmod 600 /etc/restic/password.txt
sudo chown root:root /etc/restic/password.txt

Sichern Sie dieses Passwort zusätzlich außerhalb des Servers (z. B. im Passwort-Manager). Geht es verloren, sind alle Repositories unbrauchbar.

Verifizieren: restic version gibt eine Version aus (Stand September 2026 aktuell: 0.19.1), und ls -l /etc/restic/password.txt zeigt -rw------- mit Eigentümer root.

Schritt 2: Lokales Repository als primäres Backup einrichten

Die erste Kopie liegt lokal auf einer separaten Disk, schnell für den Alltags-Restore. Initialisieren Sie das lokale Repository:

export RESTIC_PASSWORD_FILE=/etc/restic/password.txt
export RESTIC_REPOSITORY=/srv/backup/restic-local

sudo mkdir -p /srv/backup/restic-local
restic init

Sichern Sie die wichtigen Verzeichnisse. --exclude hält Caches und temporäre Daten heraus:

restic backup /etc /home /srv/data \
  --exclude /home/*/.cache \
  --exclude '*.tmp' \
  --tag local

Prüfen Sie die angelegten Snapshots:

restic snapshots

Ergebnis prüfen

Restic zeigt nach dem Backup eine Zusammenfassung mit verarbeiteten Dateien, Snapshot-ID und übertragenem Volumen.

Verifizieren: restic snapshots listet einen Snapshot mit Tag local und den Pfaden /etc, /home, /srv/data. Notieren Sie die Snapshot-ID für den Restore-Test.

Schritt 3: Externe USB-Festplatte als zweites Medium einbinden

Die zweite Kopie auf der USB-Disk erfüllt die Anforderung „2 verschiedene Medientypen“. Schließen Sie die Platte an und ermitteln Sie Gerät und UUID:

# UUID der USB-Disk ermitteln
lsblk -f

# Mountpoint anlegen und einhängen (Beispiel: ext4-Disk)
sudo mkdir -p /mnt/usb-backup
sudo mount /dev/sdb1 /mnt/usb-backup

Tragen Sie die Disk per UUID in die /etc/fstab ein. noauto verhindert das Einhängen beim Booten, nofail verhindert Bootfehler, wenn die Platte fehlt. Danach genügt sudo mount /mnt/usb-backup:

# /etc/fstab
UUID=xxxx-xxxx  /mnt/usb-backup  ext4  defaults,nofail,noauto  0  2

Initialisieren Sie ein eigenes Repository auf der USB-Disk und sichern Sie dieselben Daten:

export RESTIC_REPOSITORY=/mnt/usb-backup/restic-usb
restic init

restic backup /etc /home /srv/data \
  --exclude /home/*/.cache \
  --tag usb

Hängen Sie die Platte nach dem Backup aus und trennen Sie sie vom Rechner. Nur eine abgezogene Platte ist vor Ransomware geschützt (Air Gap); eine nur ausgehängte Platte kann ein Angreifer mit Root-Rechten wieder einhängen:

sudo umount /mnt/usb-backup

Verifizieren: Vor dem Aushängen listet restic -r /mnt/usb-backup/restic-usb snapshots einen Snapshot mit Tag usb; nach dem Aushängen liefert mountpoint /mnt/usb-backup „is not a mountpoint“.

Schritt 4: S3-Cloud als Offsite-Backup konfigurieren

Die dritte Kopie ist Ihr Offsite-Backup in der Cloud. Restic spricht S3-kompatible Dienste über das Schema s3: an. Legen Sie die Zugangsdaten in der Datei /etc/restic/s3.env ab:

# /etc/restic/s3.env  (chmod 600!)
export AWS_ACCESS_KEY_ID="IHR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="IHR_SECRET_KEY"

# Wasabi (Beispiel-Region eu-central-1)
export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.wasabisys.com/mein-backup-bucket/restic-offsite"

# Alternativ Backblaze B2 über S3-kompatiblen Endpoint
# export RESTIC_REPOSITORY="s3:https://s3.eu-central-003.backblazeb2.com/mein-backup-bucket/restic-offsite"

Schränken Sie die Rechte ein, da die Datei Zugangsschlüssel enthält:

sudo chmod 600 /etc/restic/s3.env

Den Endpoint Ihres Buckets entnehmen Sie der Konsole des Anbieters; er muss zur Region des Buckets passen. Initialisieren Sie das Cloud-Repository und führen Sie das erste Offsite-Backup aus:

source /etc/restic/s3.env
export RESTIC_PASSWORD_FILE=/etc/restic/password.txt

restic init

restic backup /etc /home /srv/data \
  --exclude /home/*/.cache \
  --tag offsite

Da Restic clientseitig verschlüsselt, verlassen nur verschlüsselte Datenblöcke Ihren Server; der Anbieter sieht keine Klartextdaten.

Verifizieren: restic snapshots (mit geladener s3.env) listet einen Snapshot mit Tag offsite, und in der Konsole des Anbieters enthält der Bucket die Ordner data, index, keys und snapshots.

Schritt 5: Aufbewahrung (Retention) und Pruning einrichten

Ohne Aufräumen wachsen Repositories endlos. Eine Retention-Policy behält die sinnvollen Snapshots und gibt Speicher frei. restic forget wirkt nur auf das Repository in RESTIC_REPOSITORY; führen Sie den Befehl daher für jedes der drei Repositories aus:

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

Diese Policy hält die letzten 7 Tage, 4 Wochen und 6 Monate vor und löscht dann ungenutzte Datenblöcke. --prune reorganisiert das Repository und erzeugt bei der Cloud zusätzlichen Datenverkehr; führen Sie es deshalb wöchentlich statt bei jedem Lauf aus.

Verifizieren: Die Ausgabe von restic forget listet unter „keep“ die behaltenen und unter „remove“ die entfernten Snapshots; restic snapshots zeigt danach nur noch die behaltenen.

Schritt 6: Verifikation und erster Restore-Test

Prüfen Sie zuerst die Integrität des Repositories:

# Strukturelle Integrität prüfen
restic check

# Stichprobe: 5 % der Daten tatsächlich lesen und entschlüsseln
restic check --read-data-subset=5%

Spielen Sie dann einen Snapshot in ein temporäres Verzeichnis zurück und vergleichen Sie die Inhalte:

mkdir -p /tmp/restore-test
restic restore latest --target /tmp/restore-test

# Inhalt sichten
ls -la /tmp/restore-test/srv/data

Alternativ hängen Sie ein Repository als Dateisystem ein (benötigt FUSE):

mkdir -p /tmp/restic-mount
restic mount /tmp/restic-mount
# in einem zweiten Terminal: Snapshots durchsuchen, danach mit Strg+C aushängen

Wiederholen Sie diesen Restore-Test regelmäßig, mindestens für die Cloud-Kopie.

Verifizieren: restic check endet mit „no errors were found“, und diff -r /srv/data /tmp/restore-test/srv/data meldet keine Unterschiede (außer seit dem Backup geänderten Dateien). Löschen Sie /tmp/restore-test danach.

Schritt 7: Backups per Cron automatisieren

Legen Sie ein Skript /usr/local/bin/backup-321.sh an, das alle drei Ziele bedient:

#!/usr/bin/env bash
# /usr/local/bin/backup-321.sh
set -euo pipefail
export RESTIC_PASSWORD_FILE=/etc/restic/password.txt
SRC=(/etc /home /srv/data)
EXCL=(--exclude '/home/*/.cache' --exclude '*.tmp')

# 1) Lokal
RESTIC_REPOSITORY=/srv/backup/restic-local restic backup "${SRC[@]}" "${EXCL[@]}" --tag local

# 2) USB (nur wenn eingehängt)
if mountpoint -q /mnt/usb-backup; then
  RESTIC_REPOSITORY=/mnt/usb-backup/restic-usb restic backup "${SRC[@]}" "${EXCL[@]}" --tag usb
fi

# 3) Offsite S3
source /etc/restic/s3.env
restic backup "${SRC[@]}" "${EXCL[@]}" --tag offsite

Machen Sie das Skript nur für root ausführbar:

sudo chmod 700 /usr/local/bin/backup-321.sh

Tragen Sie den täglichen Lauf in die root-Crontab ein:

sudo crontab -e
# Täglich um 02:30 Uhr Backup auf alle drei Ziele
30 2 * * * /usr/local/bin/backup-321.sh >> /var/log/restic-backup.log 2>&1

Führen Sie das Skript einmal von Hand aus (sudo /usr/local/bin/backup-321.sh), bevor Sie sich auf Cron verlassen. Die USB-Kopie entsteht nur, wenn die Platte zum Zeitpunkt des Laufs eingehängt ist; hängen Sie sie dafür zum Beispiel einmal pro Woche vor 02:30 Uhr ein.

Verifizieren: Nach dem nächsten Lauf enthält /var/log/restic-backup.log für jedes Ziel die Zeile „snapshot … saved“ ohne Fehlermeldung.

Eine ausführliche Variante mit systemd-Timer und Windows-Aufgabenplanung finden Sie in der Anleitung zur Restic-Backup-Automatisierung mit Cron unter Linux und Windows.

Updates & Wartung

Halten Sie Restic aktuell. Bei Installation aus dem GitHub-Release aktualisiert es sich selbst:

# Bei Binär-Installation aus dem offiziellen Release
sudo restic self-update

# Bei Paketinstallation über den Paketmanager
sudo apt update && sudo apt install --only-upgrade restic

Planen Sie wiederkehrende Wartung fest ein: wöchentlich restic check und restic forget --prune, monatlich einen Restore-Test der Cloud-Kopie. Rotieren Sie die USB-Festplatte, idealerweise zwei Platten im Wechsel, von denen eine außer Haus liegt.

Backup-Hinweis zum Backup selbst

Sichern Sie das Repository-Passwort, die S3-Zugangsdaten und das Backup-Skript getrennt vom Server, eine Kopie des Passworts offline an einem zweiten Ort. Ohne Passwort kann niemand die Daten wiederherstellen.

Troubleshooting

1. „repository master key and config already initialized“: Das Repository existiert bereits; nutzen Sie es ohne erneutes restic init.
2. S3-Verbindung scheitert / „AccessDenied“: Prüfen Sie Endpoint-URL, Region, Bucket-Name und ob der Access Key Schreibrechte hat. Bei Wasabi muss die Region zum Endpoint passen.
3. USB-Backup wird übersprungen: Das Skript prüft mit mountpoint -q. Hängen Sie die Platte vor dem Lauf ein; nofail in der fstab verhindert Boot-Probleme.
4. „Fatal: wrong password or no key found“: Falsche oder fehlende Passwortdatei, oder der Befehl läuft nicht als root. Kontrollieren Sie RESTIC_PASSWORD_FILE und die Dateirechte.
5. Backup sehr langsam in die Cloud: Das erste Backup überträgt alle Daten. Begrenzen Sie mit --limit-upload (KiB/s) die Bandbreite; Folgeläufe übertragen dank Deduplizierung nur Änderungen.
6. Prune dauert lange / viel Cloud-Traffic: Führen Sie --prune seltener aus (z. B. wöchentlich) und nicht bei jedem Backup.

Häufige Fragen

Reicht es, einfach zwei Festplatten zu spiegeln (RAID)?

Nein. Ein RAID schützt vor dem Ausfall einer Platte, aber nicht vor versehentlichem Löschen, Ransomware, Dateisystemfehlern oder einem Brand. RAID ist Verfügbarkeit, kein Backup. Die 3-2-1-Regel verlangt unabhängige Kopien, idealerweise versioniert und offsite.

Welcher Cloud-Anbieter eignet sich für das Offsite-Backup?

Jeder S3-kompatible Dienst, zum Beispiel Wasabi, Backblaze B2 oder ein Anbieter mit Rechenzentrum in Deutschland. Wählen Sie eine EU-Region. Da Restic clientseitig verschlüsselt, sieht der Anbieter nur verschlüsselte Blöcke; für personenbezogene Daten brauchen Sie dennoch einen Auftragsverarbeitungsvertrag.

Muss ich für die „2 Medientypen“ zwingend zwei verschiedene Tools nutzen?

Nein. Die Regel bezieht sich auf Medientypen (interne Disk, USB-Disk, Cloud-Object-Storage), nicht auf Werkzeuge. Restic für alle Ziele ist zulässig. Wer zusätzlich gegen einen Tool-spezifischen Bug absichern will, nutzt für die USB-Kopie ein zweites Tool wie Borg.

Wie oft sollte ich Restore-Tests machen?

Mindestens monatlich für die Cloud-Kopie und nach jeder größeren Änderung an Setup oder Datenbestand. Planen Sie den Test fest in die Wartung ein.

Wie schütze ich meine Backups vor Ransomware?

Kombinieren Sie mehrere Maßnahmen: die USB-Disk nach dem Backup abziehen (Air Gap), für den Cloud-Bucket eigene, eng berechtigte Zugangsschlüssel verwenden und, falls der Anbieter es unterstützt, Object Lock aktivieren (beachten Sie, dass prune gesperrte Objekte dann erst nach Ablauf der Sperrfrist löschen kann). Restics versionierte Snapshots erlauben zudem die Wiederherstellung eines Standes vor dem Befall.

Fazit

Mit Restic, einer externen USB-Festplatte und einem S3-Bucket haben Sie die 3-2-1-Backup-Strategie umgesetzt: drei Kopien, zwei Medientypen, eine Offsite-Kopie, clientseitig verschlüsselt und automatisiert. Entscheidend im Betrieb sind regelmäßige restic check-Läufe, eine Retention-Policy je Repository und wiederkehrende Restore-Tests.

Weiterführende Anleitungen & Quellen

Zur Vertiefung der Automatisierung: Anleitung zur Restic-Backup-Automatisierung mit Cron. Wer im Unternehmen eine integrierte Lösung einsetzt, sollte aktuelle Sicherheitsthemen beachten, etwa die Schwachstelle in Veeam Backup & Replication (CVE-2026-32996). Weitere Themen finden Sie in der Kategorie Backup.

Quellen: Offizielle Restic-Dokumentation (restic.readthedocs.io), Restic-Projekt auf GitHub (github.com/restic/restic) sowie die Wasabi-S3-Dokumentation (docs.wasabi.com).