Die 3-2-1-Regel – wie ich sie mit Restic und pCloud umsetze

Backups macht man nicht, weil es Spaß macht, sondern weil man sie irgendwann braucht. Und dann reicht eine einzelne Sicherung nicht. Die Frage ist nicht *ob* eine Platte stirbt, sondern *wann* – und ob dann noch etwas übrig ist. Deshalb gilt bei mir seit langem die 3-2-1-Regel. Wie ich sie mit meinem Restic-Setup und meinem pCloud-Lifetime-Account umsetze, zeige ich hier.

Was ist die 3-2-1-Regel?

Die 3-2-1-Regel ist eine Faustregel aus der Backup-Welt:

3 Kopien deiner Daten – das Original zählt mit
2 verschiedene Medien – nicht alles auf derselben Platte
1 Kopie offsite – außerhalb deines Standorts

Zahl	Bedeutung	Warum?
3	Drei Kopien, inkl. Original	Eine Kopie kann durch Plattenfehler, Fehlbedienung oder Malware ausfallen – die zweite fängt das ab
2	Zwei unterschiedliche Medien	Hängt alles an einem Medium, ist bei dessen Defekt alles weg
1	Eine Kopie offsite	Brand, Wasser, Diebstahl oder Ransomware treffen den ganzen Standort

Ein Backup, das im selben Regal steht wie der Rechner, ist kein Backup für den Ernstfall. Und ein Backup auf derselben Platte ist gar keins – eine defekte Platte nimmt Original und Kopie mit.

Warum eine Kopie nicht reicht

Der häufigste Denkfehler: "Ich sichere doch regelmäßig." Ja – aber auf dieselbe Platte, oder auf ein Laufwerk im selben Schrank. Im Schadensfall ist beides weg:

Plattenfehler: Eine SSD stirbt, Original und Kopie sind auf derselben Platte → alles weg.
Fehlbedienung: rm -rf im falschen Verzeichnis löscht Original und lokale Kopie synchron.
Ransomware: Verschlüsselt, was sie erreichen kann – auch eingehängte Backup-Laufwerke.
Standort-Schaden: Brand, Wasser oder Diebstahl treffen alles im Haus, egal auf wie vielen Platten es verteilt war.

Die 3-2-1-Regel deckt genau diese Fälle ab: Die dritte Kopie liegt auf einem anderen Medium und an einem anderen Ort – und ist damit von fast allen Szenarien unberührt.

Mein Aufbau im Überblick

Seit der Umstellung auf Backup pro Instanz sichert jede Incus-Instanz sich selbst gegen die zentrale Restic-Instanz. Den Offsite-Teil übernimmt die zentrale Instanz: Sie spiegelt ihre Repositories nachts per restic copy in meine pCloud.

              Original in der Instanz
                        │
      restic backup ────┤  (SFTP, jede Instanz selbst)
                        ▼
        restic-Server ──→ /repos/<instanz>          Kopie 2, lokale Platte
                        │
       restic copy ─────┤  (rclone, nachts vom Server)
                        ▼
            pCloud ─────→ /restic/<instanz>         Kopie 3, offsite

Auf die Regel gemappt:

Regel	Umsetzung
3 Kopien	Original in der Instanz + Restic-Repo auf dem Server + Restic-Repo in der pCloud
2 Medien	Lokale Platte (Server) + Cloud-Speicher (pCloud)
1 offsite	pCloud-Lifetime, an einem anderen Standort

Die lokale Schiene kennt ihr aus dem vorherigen Artikel. Hier geht es um den Offsite-Teil.

Warum pCloud?

Ein offsite-Ziel muss zuverlässig, bezahlbar und aus dem Backup-Handwerk heraus nutzbar sein. Bei mir ist das pCloud:

Lifetime statt Abo. Einmal bezahlt, keine monatlichen Kosten – für ein Backup-Ziel genau richtig.
rclone-Anbindung. pCloud ist bei rclone als Remote nativ dabei. Restic delegiert den Speicherzugriff an rclone (rclone:pcloud:…) – das Debian-Paket bringt WebDAV zwar nicht mit, mit rclone braucht es im Restic-Binary aber auch keins.
Verschlüsselung liegt bei Restic. Die Daten gehen als AES-256-Chiffrat in die pCloud. Der Anbieter sieht nur verschlüsselte Blöcke – vertrauen muss ich ihm für die Daten nicht. pCloud-eigene Crypto-Features brauche ich deshalb nicht.

Das Offsite-Repo in der pCloud anlegen

Einmalig auf dem Restic-Server rclone mit dem pCloud-Remote einrichten – der Zugriff aufs Cloud-Repo läuft komplett darüber:

apt install rclone
rclone config        # Remote "pcloud" anlegen (pCloud-Login bzw. OAuth)

Dann lege ich pro Instanz eine zweite Config an. Das Repository-Passwort liegt weiterhin getrennt in einer eigenen Datei:

# /srv/restic/backup/clients/meine-instanz/pcloud.env
export PCLOUD_REPO=rclone:pcloud:restic/meine-instanz
export PCLOUD_PASSWORD_FILE=/srv/restic/backup/clients/meine-instanz/pcloud.pw

. /srv/restic/backup/clients/meine-instanz/pcloud.env
restic -r "$PCLOUD_REPO" --password-file "$PCLOUD_PASSWORD_FILE" init

Die Pfad-Konvention ist dieselbe wie lokal: /restic/ pro Instanz ein eigenes Repository – dann bleibt die Zuordnung im Cloud-Repo genauso sauber wie auf dem Server.

Die Spiegelung per restic copy

restic copy kopiert Snapshots aus einem Repository in ein anderes – die Übertragung passiert Server-seitig, jede Instanz bleibt unberührt. Auf dem Restic-Server läuft dafür nachts ein Skript über alle Clients:

#!/bin/sh
# /usr/local/sbin/restic-mirror-pcloud.sh
set -e
for dir in /srv/restic/backup/clients/*; do
    . "$dir/server.env"
    . "$dir/pcloud.env"
    restic -r "$PCLOUD_REPO" \
        --password-file "$PCLOUD_PASSWORD_FILE" \
        copy \
        --from-repo "$RESTIC_REPOSITORY" \
        --from-password-file "$RESTIC_PASSWORD_FILE"
    restic -r "$PCLOUD_REPO" \
        --password-file "$PCLOUD_PASSWORD_FILE" \
        forget --keep-daily 6 --keep-weekly 3 --keep-monthly 18 --prune
done
curl -d "pcloud mirror ok" https://ntfy.frischux.de/backup

Die dazu passende lokale Config je Instanz:

# /srv/restic/backup/clients/meine-instanz/server.env
export RESTIC_REPOSITORY=/srv/restic/backup/repos/meine-instanz
export RESTIC_PASSWORD_FILE=/srv/restic/backup/clients/meine-instanz/server.pw

Und der Cron-Eintrag – passend zur Cron-Strategie aus dem letzten Artikel, damit er auch auf Alpine-Umgebungen funktioniert:

# /etc/crontab
0 4 * * * root /usr/local/sbin/restic-mirror-pcloud.sh

Drei Dinge sind dabei wichtig:

rclone statt WebDAV: Das Debian-Restic-Paket enthält kein WebDAV-Backend. Der Speicherzugriff läuft deshalb über rclone (rclone:pcloud:…), das pCloud nativ unterstützt – Locks funktionieren darüber normal, --no-lock ist nicht nötig.
Retention auch im pCloud-Repo: restic copy spiegelt nur Snapshots. Die forget-Policy läuft deshalb im selben Lauf gegen das pCloud-Repo – sonst wächst es endlos.
Der Erstlauf dauert: Beim ersten copy wandert das komplette Repository hoch. Danach überträgt Restic nur noch, was fehlt – es erkennt bereits vorhandene Snapshots und überspringt sie.

Wiederherstellung aus der pCloud

Fällt der Restic-Server selbst aus, bleibt die pCloud als Quelle – die Repositories sind ja gespiegelt. Der Restore funktioniert von dort direkt:

restic -r "$PCLOUD_REPO" --password-file "$PCLOUD_PASSWORD_FILE" snapshots
restic -r "$PCLOUD_REPO" --password-file "$PCLOUD_PASSWORD_FILE" restore latest --target /

Die automatisierte restore.sh bleibt dabei unverändert – nur das Ziel-Repository wechselt von sftp: auf rclone:pcloud:.

Integrität prüfen

Ein Backup ist nur so viel wert wie seine Prüfung. Einmal im Monat läuft restic check deshalb auch gegen das pCloud-Repo:

restic -r "$PCLOUD_REPO" --password-file "$PCLOUD_PASSWORD_FILE" \
    check --read-data-subset=10%

--read-data-subset liest bei jedem Lauf einen Teil der Daten wirklich zurück – über mehrere Monate ist so irgendwann jedes Stück geprüft.

Fazit

Mit dem zentralen Restic-Server und der pCloud ist die 3-2-1-Regel fast geschenkt: Die lokale Kopie entsteht ohnehin pro Instanz, die offsite übernimmt eine einzige nachts laufende Spiegelung. Der Aufwand war das Anlegen des rclone-Remotes und ein Skript – danach läuft der Rest von alleine.

Und das Wichtigste zum Schluss: Ein Backup-Setup, das nie getestet wird, ist nur eine Hoffnung. Ich lege deshalb mindestens einmal im Jahr eine Instanz komplett aus der pCloud neu auf – dann weiß ich, dass der Notfallplan funktioniert, wenn er gebraucht wird.