Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Backup & Datensicherung 01.06.2026 · 9 min Lesezeit

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

So setzt du die 3-2-1-Backup-Strategie praktisch um: lokale Restic-Kopie, externe USB-Festplatte und ein verschlüsseltes Offsite-Backup in der S3-Cloud (Wasabi/Backblaze B2). Mit echten Befehlen, Restore-Test und Automatisierung.

Externe USB-Festplatte und Server als Teil einer 3-2-1-Backup-Strategie

Die 3-2-1-Backup-Strategie umzusetzen ist der zuverlässigste Weg, um deine Daten gegen Hardwaredefekte, Ransomware, versehentliches Löschen und sogar einen Brand oder Diebstahl abzusichern. Diese Anleitung zeigt dir hands-on, wie du die 3-2-1-Backup-Regel auf einem Linux-Homeserver oder einer kleinen Maschine praktisch realisierst: 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 das Ganze automatisiert per Cron und du hast einen geprüften, wiederherstellbaren Backup-Bestand auf drei Wegen.

Kurzfassung: 3 Kopien deiner Daten, auf 2 verschiedenen Medientypen, davon 1 außer Haus. Wir nutzen Restic als zentrales Tool für lokales Backup, USB-Disk und S3-Cloud-Repository, verschlüsseln alles clientseitig und testen den Restore regelmäßig.

Was ist die 3-2-1-Backup-Regel und warum brauchst du sie?

Die 3-2-1-Regel ist eine bewährte Faustformel für ausfallsichere Backups. Sie besagt:

  1. 3 Kopien deiner 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.

Eine einzige Kopie auf einer zweiten Platte fühlt sich nach Sicherheit an, ist aber keine. Erst die Kombination aus lokaler Geschwindigkeit (schneller Restore), einem unabhängigen Medium und einem Offsite-Standort macht aus einem Backup eine echte Backup-Redundanz über mehrere Medien. Wichtig: Ein Backup, das du nie zurückgespielt hast, ist nur eine Vermutung. Restore-Tests gehören fest dazu.

Warum Restic als zentrales Tool?

Restic ist ein quelloffenes, plattformübergreifendes Backup-Tool (Go, ein einziges Binary). Es bietet clientseitige Verschlüsselung (AES-256), Deduplizierung, Snapshots und unterstützt direkt verschiedene Backends: lokales Verzeichnis, USB-Disk, SFTP und S3-kompatible Object-Storage-Dienste wie Wasabi oder Backblaze B2. Das ist ideal für die 3-2-1-Strategie, weil du dasselbe Werkzeug und denselben Workflow für alle drei Ziele nutzt. Für die USB-Kopie kannst du alternativ borg einsetzen, um die Tool-Vielfalt zu erhöhen; in dieser Anleitung bleiben wir der Einfachheit halber bei Restic für alle Ziele.

Voraussetzungen

  1. Ein Linux-System (Debian/Ubuntu, Fedora oder Arch) als Server oder Homelab-Maschine mit Root- bzw. sudo-Zugriff.
  2. Eine externe USB-Festplatte mit ausreichend Kapazität (mindestens so groß wie deine zu sichernden Daten plus Reserve für Snapshots).
  3. Ein S3-kompatibles Cloud-Konto: Wasabi oder Backblaze B2 (beide bieten S3-kompatible Endpunkte). Du brauchst Access Key, Secret Key, Region/Endpoint und einen Bucket-Namen.
  4. restic installiert (Paketquellen oder offizielles GitHub-Release).
  5. Ein sicher aufbewahrtes Repository-Passwort – ohne dieses Passwort sind verschlüsselte Backups unwiederbringlich verloren.

Schritt 1: Restic installieren und Verzeichnisse vorbereiten

Installiere Restic über die Paketverwaltung deiner 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

Lege einen sicheren Ort für die Passwortdatei und die Umgebungsvariablen an. Wir legen das Repository-Passwort in eine root-only lesbare Datei:

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
Sichere dieses Passwort zusätzlich außerhalb des Servers (z. B. im Passwortmanager). Geht die Datei verloren, ist jedes verschlüsselte Repository unbrauchbar.

Schritt 2: Lokales Repository als primäres Backup einrichten

Die erste Kopie liegt lokal auf einer separaten Disk oder einem separaten Pool – schnell für den Alltags-Restore. Initialisiere 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

Führe das erste Backup deiner wichtigen Verzeichnisse durch. Mit --exclude hältst du Caches und temporäre Daten heraus:

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

Prüfe die angelegten Snapshots:

restic snapshots

Ergebnis prüfen

Restic zeigt dir nach dem Backup eine Zusammenfassung mit verarbeiteten Dateien, Snapshot-ID und übertragenem Volumen. Notiere dir die Snapshot-ID – sie brauchst du später 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". Stecke die Platte ein und ermittle ihren Mountpoint. Wir verwenden ein eigenes Repository auf der USB-Disk:

# 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

Für eine dauerhafte, aber nicht erzwungene Einbindung trägst du die Disk per UUID in die /etc/fstab ein (Option nofail, damit das System auch ohne angesteckte Platte bootet):

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

Initialisiere ein separates Repository auf der USB-Disk und sichere dieselben Daten dorthin:

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

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

Hänge die Platte nach dem Backup wieder aus, damit Ransomware sie nicht erreichen kann (Air-Gap-Prinzip), wenn du sie nicht dauerhaft brauchst:

sudo umount /mnt/usb-backup

Schritt 4: S3-Cloud als Offsite-Backup konfigurieren

Die dritte Kopie ist dein Offsite-Backup in der Cloud. Restic spricht S3-kompatible Dienste über das Schema s3: an. Lege die Zugangsdaten als Umgebungsvariablen in einer geschützten Datei ab:

# /etc/restic/s3.env  (chmod 600!)
export AWS_ACCESS_KEY_ID="DEIN_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="DEIN_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"
sudo chmod 600 /etc/restic/s3.env

Initialisiere das Cloud-Repository und führe 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 AES-256-verschlüsselte Datenblöcke deinen Server. Der Cloud-Anbieter sieht niemals deine Klartext-Daten – ein zentraler Vorteil gegenüber proprietären Backup-Clouds.

Schritt 5: Aufbewahrung (Retention) und Pruning einrichten

Ohne Aufräumen wachsen Repositories endlos. Mit einer Retention-Policy behältst du sinnvolle Snapshots und gibst Speicher frei. Das gilt für alle drei Ziele:

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 – bei der Cloud kostet das etwas Traffic, daher nicht bei jedem Lauf, sondern z. B. wöchentlich.

Schritt 6: Verifikation und erster Restore-Test

Ein Backup ist erst dann eines, wenn der Restore funktioniert. Prüfe 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%

Spiele jetzt einen Snapshot testweise in ein temporäres Verzeichnis zurück und vergleiche die Inhalte:

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

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

Du kannst ein Repository auch direkt als Dateisystem einhängen und browsen:

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

Mache diesen Restore-Test mindestens für die Cloud-Kopie regelmäßig – sie ist im Ernstfall deine letzte Rettung.

Schritt 7: Backups per Cron automatisieren

Damit die 3-2-1-Strategie im Alltag trägt, muss sie automatisch laufen. Lege ein Wrapper-Skript 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 gemountet)
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
sudo chmod 700 /usr/local/bin/backup-321.sh

Trage 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

Eine ausführliche Variante inklusive systemd-Timer und Windows-Aufgabenplanung findest du in unserer Anleitung zur Restic-Backup-Automatisierung mit Cron unter Linux und Windows.

Updates & Wartung

Halte Restic aktuell, damit du von Performance- und Sicherheitsverbesserungen profitierst. Restic kann sich bei Installation aus dem GitHub-Release selbst aktualisieren:

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

# Bei Paketinstallation einfach über den Paketmanager
sudo apt update && sudo apt upgrade restic

Plane wiederkehrende Wartung fest ein: wöchentlich restic check und restic forget --prune, monatlich einen vollständigen Restore-Test der Cloud-Kopie. Rotiere außerdem die USB-Festplatte – idealerweise zwei Platten im Wechsel, von denen eine außer Haus liegt.

Backup-Hinweis zum Backup selbst

Sichere die Schlüsselelemente, ohne die deine Backups wertlos sind: das Repository-Passwort, die S3-Zugangsdaten und die Restic-Konfiguration. Bewahre eine Kopie des Passworts offline und an einem zweiten Ort auf. Verlierst du das Passwort, kann niemand – auch kein Support – die verschlüsselten Daten wiederherstellen.

Troubleshooting

  1. "repository master key and config already initialized": Das Repository existiert bereits – führe kein erneutes restic init aus, nutze es direkt.
  2. S3-Verbindung scheitert / "AccessDenied": Prüfe 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änge die Platte vor dem Lauf ein oder ergänze einen Mount-Schritt; nofail in der fstab verhindert Boot-Probleme.
  4. "Fatal: wrong password or no key found": Falsche oder fehlende Passwortdatei. Kontrolliere RESTIC_PASSWORD_FILE und die Dateirechte.
  5. Backup sehr langsam in die Cloud: Erstes Backup überträgt alle Daten. Nutze --limit-upload, um deine Leitung nicht zu sättigen; Folgeläufe übertragen dank Deduplizierung nur Änderungen.
  6. Prune dauert ewig / viel Cloud-Traffic: Führe --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?

Für ein kostengünstiges, S3-kompatibles Offsite-Backup sind Wasabi und Backblaze B2 in der Selfhosting-Szene beliebt. Beide bieten S3-Endpunkte, die Restic direkt anspricht. Da Restic clientseitig verschlüsselt, ist die Datenschutzlage entspannt – der Anbieter sieht nur verschlüsselte Blöcke.

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 Tools. Du kannst Restic für alle Ziele verwenden. 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. Ein nie getesteter Restore ist das häufigste Versagen echter Backup-Strategien. Plane den Test fest in deine Wartung ein.

Wie schütze ich meine Backups vor Ransomware?

Kombiniere mehrere Maßnahmen: die USB-Disk nach dem Backup aushängen (Air-Gap), für den Cloud-Bucket separate, eng berechtigte Zugangsschlüssel verwenden und – falls der Anbieter es unterstützt – Object-Lock/Immutability aktivieren. Restics versionierte Snapshots erlauben zudem die Wiederherstellung eines Standes vor dem Befall.

Fazit

Mit Restic, einer externen USB-Festplatte und einem S3-Cloud-Bucket hast du die 3-2-1-Backup-Strategie umgesetzt: drei Kopien, zwei Medientypen, eine Offsite-Kopie – clientseitig verschlüsselt, dedupliziert und automatisiert. Entscheidend für die Praxis sind die unscheinbaren Routinen: regelmäßige restic check-Läufe, eine saubere Retention-Policy und vor allem die wiederkehrenden Restore-Tests. Damit ist dein Homelab oder kleiner Server gegen Hardwaredefekte, menschliche Fehler, Ransomware und physische Schäden robust abgesichert.

Weiterführende Anleitungen & Quellen

Wenn du die Automatisierung vertiefen willst, lies unsere Anleitung zur Restic-Backup-Automatisierung mit Cron. Setzt du im Unternehmen auf eine integrierte Lösung, beachte aktuelle Sicherheitsthemen wie die Schwachstelle in Veeam Backup & Replication (CVE-2026-32996). Weitere Themen rund um Datensicherung findest du 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).