Verschlüsseltes Backup auf pCloud mit rclone

2026-10-06

Ich wollte ein Backup, das jeden Tag von allein läuft, meine Daten verschlüsselt in der Cloud ablegt und mir erlaubt, versehentlich gelöschte oder überschriebene Dateien noch Wochen später zurückzuholen. Meine Wahl: rclone als Werkzeug, pCloud als Speicher, rclone crypt für die Verschlüsselung und launchd als Zeitplaner auf dem Mac.

Diese Anleitung beschreibt genau den Weg, den ich gegangen bin, inklusive der Fehler und der Tests. Als Testordner habe ich ~/TestBackup benutzt, ein kleiner Ordner mit einer Bilddatei und einem Git-Repository (54 Dateien, rund 1 MB).

Was am Ende herauskommt

Jede Nacht um 02:00 Uhr wird der gewählte Ordner nach pCloud gesichert.
Dateinamen und Inhalte sind clientseitig verschlüsselt. pCloud sieht nur Zeichensalat.
aktuell/ enthält immer den letzten Stand der Quelle.
Geänderte oder gelöschte Dateien wandern in archiv/<Datum_Uhrzeit>/ und bleiben dort 90 Tage.
Auf dem eigenen Rechner wird nie etwas gelöscht.
Bei einem Fehler bricht das Skript ab und liefert einen Exit-Code ungleich 0.
Zusätzlich gibt es ein manuelles Backup ohne Verschlüsselung in einen getrennten Ordner.

Die Struktur in pCloud sieht (entschlüsselt betrachtet) so aus:

Backup/
├── aktuell/
│   └── TestBackup/…
└── archiv/
    ├── 2026-10-06_02-00-01/TestBackup/…
    └── 2026-10-07_02-00-03/TestBackup/…

Voraussetzungen

macOS mit Homebrew
ein pCloud-Konto (ich habe ein EU-Konto, das ist gleich wichtig)
ein Passwortmanager für das Crypt-Passwort

1. rclone installieren

brew install rclone
rclone version

Das offizielle Installationsskript von rclone.org funktioniert ebenfalls, braucht aber sudo. Ich habe Homebrew genommen: kein sudo, und die fehlende mount-Funktion unter macOS spielt für Backups keine Rolle. Bei mir wurde rclone 1.75.1 installiert.

2. pCloud-Remote einrichten

rclone config

Dann:

n (New remote), Name pcloud, Typ pcloud (in der Liste Nummer 46 oder einfach pcloud tippen)
client_id und client_secret leer lassen (Enter)
Edit advanced config: y
Alle folgenden Felder mit Enter überspringen: token, auth_url, token_url, client_credentials, encoding, root_folder_id
Bei hostname für ein EU-Konto die Option 2 (EU region, eapi.pcloud.com) wählen. Für ein US-Konto bleibt es beim Standard.
username und password leer lassen (bei password die Antwort n). Beide werden nur für rclone cleanup gebraucht.
description leer lassen. Auf die zweite Frage „Edit advanced config?“ mit n antworten.
Use web browser to automatically authenticate: y. Im Browser bei pCloud anmelden und den Zugriff erlauben. Das Terminal meldet danach „Got code“.
Die Zusammenfassung mit y bestätigen, mit q beenden.

Wichtig bei EU-Konten: Ohne hostname = eapi.pcloud.com funktioniert die Anmeldung nicht, weil die Daten auf dem europäischen Server liegen.

Test:

rclone lsd pcloud:

Es sollten deine pCloud-Ordner erscheinen.

Token nicht weitergeben

Die Konfigurationsausgabe von rclone enthält den OAuth-Token im Klartext, auch die Zusammenfassung am Ende von rclone config. Kopiere sie nie in Chats, Tickets oder Screenshots. Bei mir ist es genau so passiert, deshalb habe ich den Token danach erneuert:

In pCloud den Zugriff von rclone widerrufen (Sicherheit, verbundene Apps).
Danach neu verbinden:

rclone config reconnect pcloud:

Die Reihenfolge ist wichtig: erst widerrufen, dann neu verbinden. Sonst wird der frische Token vermutlich gleich mit ungültig, weil pCloud den Zugriff pro App verwaltet.

3. Verschlüsselung mit rclone crypt

Wieder rclone config:

n, Name pcloudcrypt, Typ crypt (Nummer 16)
remote: pcloud:Backup
filename_encryption: standard, directory_name_encryption: true (jeweils Enter)
password: g (generieren), Bit-Länge 1024
password2 (Salt): ebenfalls g, 1024
Erweiterte Optionen mit n, Konfiguration mit y bestätigen, mit q beenden

rclone zeigt das generierte Passwort nur einmal an. Speichere es und das Salt sofort im Passwortmanager, bevor du mit y bestätigst.

Ohne Passwort und Salt sind die Backups verloren. Sichere außerdem die Datei ~/.config/rclone/rclone.conf an einem Ort außerhalb des Rechners. Sie enthält die verschleierten Passwörter und den pCloud-Token.

Dass rclone lsd pcloudcrypt: anfangs „directory not found“ meldet, ist normal: Der Ordner Backup existiert in pCloud erst nach dem ersten Lauf.

4. Das Backup-Skript

Ich lege es nach ~/.local/bin/pcloud-backup.sh, damit ich kein sudo brauche:

#!/bin/bash
# Taegliches Backup nach pCloud (verschluesselt via rclone crypt).
# Aufruf:  pcloud-backup.sh [--dry-run]
# Geaenderte/geloeschte Dateien landen 90 Tage lang in Backup/archiv/<Datum_Uhrzeit>.
# Auf dem lokalen Rechner wird nichts geloescht.

set -euo pipefail

# launchd startet mit minimalem PATH
export PATH="/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"

REMOTE="pcloudcrypt"                  # crypt-Remote auf pcloud:Backup
RETENTION_DAYS=90
LOG_FILE="$HOME/Library/Logs/pcloud-backup.log"
LOCK_DIR="${TMPDIR:-/tmp}/pcloud-backup.lock"

SOURCES=(
  "$HOME/TestBackup"
)

EXCLUDES=(
  ".DS_Store"
  ".Trash/**"
  "node_modules/**"
  ".cache/**"
  "Caches/**"
  "*.tmp"
  "*.temp"
  "tmp/**"
  "*.vmdk" "*.vdi" "*.qcow2" "*.vhd" "*.vhdx"
  "*.pvm/**" "*.vmwarevm/**" "*.utm/**"
)

DRY=()
if [[ "${1:-}" == "--dry-run" ]]; then
  DRY=(--dry-run)
fi

STAMP="$(date +%Y-%m-%d_%H-%M-%S)"
CURRENT="$REMOTE:aktuell"
ARCHIVE="$REMOTE:archiv"

mkdir -p "$(dirname "$LOG_FILE")"
log() { printf '%s %s\n' "$(date '+%Y/%m/%d %H:%M:%S')" "$*" >> "$LOG_FILE"; }
fail() { log "FEHLER: $*"; echo "FEHLER: $*" >&2; exit 1; }

# Nur ein Lauf gleichzeitig
if ! mkdir "$LOCK_DIR" 2>/dev/null; then
  fail "Ein anderer Backup-Lauf ist aktiv (Lock: $LOCK_DIR)"
fi
trap 'rc=$?; rmdir "$LOCK_DIR" 2>/dev/null; exit $rc' EXIT

command -v rclone >/dev/null || fail "rclone nicht gefunden"
log "=== Start ${DRY[*]:-} Archiv=$STAMP ==="

EXCLUDE_ARGS=()
for e in "${EXCLUDES[@]}"; do EXCLUDE_ARGS+=(--exclude "$e"); done

for SRC in "${SOURCES[@]}"; do
  # Schutz: fehlende/leere Quelle darf nicht zum Archivieren des gesamten Backups fuehren
  [[ -d "$SRC" ]] || fail "Quelle fehlt: $SRC"
  [[ -n "$(ls -A "$SRC" 2>/dev/null)" ]] || fail "Quelle ist leer: $SRC"

  NAME="$(basename "$SRC")"
  log "Sync $SRC -> $CURRENT/$NAME"
  rclone sync "$SRC" "$CURRENT/$NAME" \
    --backup-dir "$ARCHIVE/$STAMP/$NAME" \
    "${EXCLUDE_ARGS[@]}" \
    --log-file "$LOG_FILE" --log-level INFO \
    --stats-one-line --stats 0 \
    ${DRY[@]+"${DRY[@]}"}
done

# Archivordner aelter als RETENTION_DAYS entfernen (nach Zeitstempel im Ordnernamen,
# nicht nach Datei-Aenderungsdatum, das beim Archivieren erhalten bleibt).
if rclone lsf --dirs-only "$ARCHIVE" >/dev/null 2>&1; then
  CUTOFF="$(date -v-"${RETENTION_DAYS}"d +%Y-%m-%d_%H-%M-%S)"
  log "Archiv aufraeumen: Ordner aelter als $CUTOFF"
  while IFS= read -r dir; do
    dir="${dir%/}"
    [[ "$dir" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}-[0-9]{2}-[0-9]{2}$ ]] || continue
    if [[ "$dir" < "$CUTOFF" ]]; then
      log "Entferne altes Archiv $dir"
      rclone purge "$ARCHIVE/$dir" --log-file "$LOG_FILE" --log-level INFO ${DRY[@]+"${DRY[@]}"}
    fi
  done < <(rclone lsf --dirs-only "$ARCHIVE")
  rclone rmdirs "$ARCHIVE" --leave-root \
    --log-file "$LOG_FILE" --log-level INFO ${DRY[@]+"${DRY[@]}"}
fi

log "=== Ende OK ==="

Ausführbar machen:

chmod +x ~/.local/bin/pcloud-backup.sh

Was das Skript tut

rclone sync mit --backup-dir: Die Quelle wird nach aktuell/<Ordner> gespiegelt. Alles, was dabei überschrieben oder gelöscht würde, wird stattdessen nach archiv/<Zeitstempel>/ verschoben.
--exclude-Regeln: Caches, Temp-Dateien, node_modules, Papierkorb und virtuelle Maschinen bleiben draußen. Sie sind groß, ändern sich ständig und lassen sich neu erzeugen.
Lock-Verzeichnis: Verhindert, dass zwei Läufe gleichzeitig starten, etwa wenn der erste Lauf sehr lange dauert.
Schutz vor leerer Quelle: Ist die Quelle nicht lesbar oder leer, bricht das Skript ab. Sonst würde sync das komplette Backup als „gelöscht“ ins Archiv schieben.
set -euo pipefail und Exit-Code: Jeder Fehler beendet das Skript mit Exit-Code ungleich 0.

5. Zuerst trocken, dann echt

~/.local/bin/pcloud-backup.sh --dry-run

Der Trockenlauf kopiert nichts. Er schreibt nur ins Log, was passieren würde:

tail ~/Library/Logs/pcloud-backup.log

Bei mir meldete der Trockenlauf 54 Dateien, die kopiert würden, und nichts, was gelöscht oder archiviert würde, weil das Ziel noch leer war. Danach der echte Lauf:

~/.local/bin/pcloud-backup.sh

Der erste Lauf kann bei großen Datenmengen Stunden dauern. Alle weiteren übertragen nur Änderungen und sind schnell. Meine 1 MB waren in Sekunden durch.

In pCloud sind danach Datei- und Ordnernamen unlesbar (etwas wie p2rog72jil513rgtausblkkc90/). Über rclone lsl pcloudcrypt: siehst du sie entschlüsselt.

6. Täglich um 02:00 mit launchd

Der Agent liegt unter ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist. Ersetze adrian durch deinen Benutzernamen und de.adrian durch deinen eigenen Label-Präfix:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>de.adrian.pcloud-backup</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/adrian/.local/bin/pcloud-backup.sh</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>2</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>
    <key>StandardOutPath</key>
    <string>/Users/adrian/Library/Logs/pcloud-backup.launchd.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/adrian/Library/Logs/pcloud-backup.launchd.log</string>
    <key>ProcessType</key>
    <string>Background</string>
    <key>LowPriorityIO</key>
    <true/>
</dict>
</plist>

Laden und testen:

plutil -lint ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist
launchctl kickstart gui/$(id -u)/de.adrian.pcloud-backup
launchctl print gui/$(id -u)/de.adrian.pcloud-backup | grep 'last exit'

last exit code = 0 und ein Eintrag „Ende OK“ im Log zeigen, dass der Lauf über launchd funktioniert. Der Agent läuft als dein Benutzer und findet damit dieselbe rclone-Konfiguration wie dein Terminal. Hat der Mac um 02:00 Uhr geschlafen, holt launchd den Lauf beim Aufwachen nach. War er ausgeschaltet, entfällt der Lauf.

7. Alles testen, was ich getestet habe

Ein Backup ist erst ein Backup, wenn man es ausprobiert hat. Das habe ich geprüft:

Wiederherstellung einer Datei:

mkdir -p /tmp/restore-test
rclone copyto pcloudcrypt:aktuell/TestBackup/adrian.jpg /tmp/restore-test/adrian.jpg
shasum -a 256 ~/TestBackup/adrian.jpg /tmp/restore-test/adrian.jpg

Beide Prüfsummen waren identisch.

Abgleich des ganzen Ordners:

rclone check ~/TestBackup pcloudcrypt:aktuell/TestBackup --exclude .DS_Store

Ergebnis: 0 Unterschiede, 54 passende Dateien. Dass rclone dabei „No common hash found“ meldet, ist bei Crypt normal. Verglichen wird dann über Größe und Zeitstempel.

Fehlerfall: Ich habe das Skript absichtlich auf einen nicht vorhandenen Quellordner gerichtet. Es brach mit „Quelle fehlt“ ab und lieferte Exit-Code 1.

Archiv: Ich habe in einem Wegwerf-Ordner (nicht in meinen echten Daten) eine Datei geändert (a.txt, von v1 zu v2) und eine zweite gelöscht (b.txt) und danach gesichert. aktuell/ enthielt nur noch die neue a.txt, und archiv/<Zeitstempel>/ hielt die alte a.txt (Inhalt v1) und die gelöschte b.txt.

Aufräumen nach 90 Tagen: Ich habe künstlich zwei Archivordner in pCloud angelegt: 2026-01-01_00-00-00 (älter als 90 Tage) und 2026-09-01_00-00-00 (jünger). Nach einem Lauf war nur der Januar-Ordner weg. Der Trockenlauf hatte genau diesen Ordner zuvor als „würde entfernt“ gemeldet.

Die Testdaten habe ich danach aus pCloud entfernt.

8. Eine Variante ohne Verschlüsselung (manuell)

Manchmal will ich Dateien in pCloud direkt im Browser öffnen oder jemandem zeigen. Dafür gibt es ein zweites Skript, das nur auf Zuruf läuft, ohne Zeitplan und in einen getrennten Ordner schreibt. So vermischen sich verschlüsselte und lesbare Daten nicht.

Das Skript ist eine Kopie des ersten mit diesen Änderungen:

# statt: REMOTE="pcloudcrypt"
BASE="pcloud:Backup-Klartext"

LOG_FILE="$HOME/Library/Logs/pcloud-backup-klartext.log"
LOCK_DIR="${TMPDIR:-/tmp}/pcloud-backup-klartext.lock"

# statt $REMOTE:aktuell und $REMOTE:archiv
CURRENT="$BASE/aktuell"
ARCHIVE="$BASE/archiv"

Alles andere (Ausschlüsse, Schutz vor leerer Quelle, 90 Tage Archiv, Exit-Codes) bleibt gleich. Aufruf:

~/.local/bin/pcloud-backup-klartext.sh --dry-run
~/.local/bin/pcloud-backup-klartext.sh

Beim Test mit meinem TestBackup-Ordner wurden 54 Dateien nach pcloud:Backup-Klartext/aktuell/TestBackup kopiert. Der Abgleich ergab 0 Unterschiede, und die wiederhergestellte Datei hatte dieselbe Prüfsumme. Das verschlüsselte Backup blieb dabei unberührt.

Wähle bewusst, was im Klartext liegen darf. Dateien dort sind für pCloud lesbar. Wer Zugriff auf dein Konto hat, sieht sie.

Stolpersteine, die ich erlebt habe

`--min-age 90d` löscht zu früh

Die naheliegende Lösung für die 90 Tage ist:

rclone delete archiv --min-age 90d

Das prüft aber die Änderungszeit der Datei, nicht den Zeitpunkt der Archivierung. --backup-dir verschiebt Dateien mit ihrem alten Zeitstempel. Löschst du heute eine zwei Jahre alte Datei, landet sie im Archiv, und der nächste Aufräumlauf entfernt sie sofort wieder. Deshalb löscht mein Skript stattdessen ganze Archivordner, deren Name (ein Zeitstempel) älter als 90 Tage ist.

Leeres Array unter macOS-Bash 3.2

macOS liefert noch Bash 3.2 mit. Dort führt "${DRY[@]}" bei einem leeren Array und aktivem set -u zum Fehler unbound variable. Die Lösung ist ${DRY[@]+"${DRY[@]}"}. Bei mir ist der erste echte Lauf genau daran gescheitert, bevor etwas hochgeladen wurde.

Der Exit-Trap verschluckte den Fehlercode

Mein erster Trap (trap 'rmdir "$LOCK_DIR"' EXIT) hat den Exit-Code des Skripts überschrieben, ein Fehler wurde als Erfolg gemeldet. Der Trap muss den Status sichern und zurückgeben:

trap 'rc=$?; rmdir "$LOCK_DIR" 2>/dev/null; exit $rc' EXIT

Prüfe so etwas immer mit einem absichtlich fehlerhaften Lauf, zum Beispiel mit einer nicht vorhandenen Quelle.

macOS-Datenschutz (TCC) blockt Hintergrundjobs

~/Desktop, ~/Documents und ~/Downloads sind geschützt. Ein per launchd gestartetes Skript darf dort nicht lesen und sieht die Ordner als leer. Mein erster Testordner lag auf dem Schreibtisch: Der launchd-Lauf scheiterte mit „Quelle ist leer“. Der Schutz im Skript hat in diesem Fall verhindert, dass das Backup als „komplett gelöscht“ archiviert wurde. Zwei Auswege:

Quellordner außerhalb der geschützten Ordner wählen, etwa direkt im Home-Verzeichnis oder unter ~/Developer. Ich habe meinen Testordner nach ~/TestBackup verschoben, danach lief der Agent sofort.
Unter Systemeinstellungen, Datenschutz & Sicherheit, Festplattenvollzugriff /bin/bash hinzufügen. Das gibt aber jedem bash-Skript im Hintergrund weitreichenden Zugriff.

Ich bevorzuge Variante 1.

Alltag

Aufgabe	Befehl
Manuell starten (verschlüsselt)	`~/.local/bin/pcloud-backup.sh`
Manuell starten (Klartext)	`~/.local/bin/pcloud-backup-klartext.sh`
Trockenlauf	beim jeweiligen Skript `--dry-run` anhängen
Log ansehen	`tail -f ~/Library/Logs/pcloud-backup.log`
Agent-Status	`launchctl print gui/$(id -u)/de.adrian.pcloud-backup`
Zeitplan deaktivieren	`launchctl bootout gui/$(id -u)/de.adrian.pcloud-backup`
Zeitplan aktivieren	`launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist`
Einzelne Datei zurückholen	`rclone copyto pcloudcrypt:aktuell/<Ordner>/<Datei> ./<Datei>`
Ganzen Ordner zurückholen	`rclone copy pcloudcrypt:aktuell/<Ordner> ./wiederhergestellt`
Alten Stand aus dem Archiv	`rclone lsd pcloudcrypt:archiv`, dann `rclone copy pcloudcrypt:archiv/<Zeitstempel>/<Ordner> ./archiv-stand`

Beim Wiederherstellen immer in einen neuen, leeren Zielordner kopieren und nie direkt über die Originaldaten. Für das Klartext-Backup ersetzt du pcloudcrypt: durch pcloud:Backup-Klartext/.

Das tägliche Backup abstellen

Der Zeitplan ist ein launchd-Agent. Wenn du ihn entlädst, läuft das Backup nicht mehr von allein:

launchctl bootout gui/$(id -u)/de.adrian.pcloud-backup

Das wirkt sofort. Prüfen, dass er weg ist (die Ausgabe sollte „Could not find service“ melden):

launchctl print gui/$(id -u)/de.adrian.pcloud-backup

Beim nächsten Login würde launchd die plist-Datei aber wieder laden. Für ein dauerhaftes Abschalten benennst du sie um:

mv ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist.aus

Wieder einschalten:

mv ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist.aus ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist

Das Skript, die rclone-Konfiguration und die Daten in pCloud bleiben dabei unverändert. Du kannst das Backup weiter von Hand mit ~/.local/bin/pcloud-backup.sh starten.

Wenn du den Agenten mitten in einem Lauf entlädst: Das Skript legt beim Start ein Lock-Verzeichnis an. Wird der Lauf hart beendet, kann es zurückbleiben. Der nächste Start bricht dann mit „Ein anderer Backup-Lauf ist aktiv“ ab. Prüfe in dem Fall, dass wirklich nichts mehr läuft (pgrep rclone), und entferne es: rmdir "${TMPDIR:-/tmp}/pcloud-backup.lock".

Das Entladen löscht keine Daten in pCloud. Wer das Backup auch dort entfernen will, muss den Ordner Backup (und ggf. Backup-Klartext) selbst in pCloud löschen.

Was du sichern musst

~/.config/rclone/rclone.conf (pCloud-Token und verschleierte Crypt-Passwörter)
Crypt-Passwort und Salt im Klartext, getrennt davon im Passwortmanager

Ohne diese beiden Dinge hilft dir das beste Backup nichts. Wenn dein Mac einmal weg ist, brauchst du genau sie, um auf einem neuen Rechner mit rclone config die Remotes wieder anzulegen (dort dieselben Passwörter eintragen, nicht neu generieren).

Wo liegt die rclone.conf?

Den genauen Pfad zeigt rclone selbst an:

rclone config file

Unter macOS ist das normalerweise:

~/.config/rclone/rclone.conf

Der Ordner .config ist im Finder unsichtbar. Du kommst auf zwei Wegen hin:

Finder: Cmd+Shift+G drücken und ~/.config/rclone eintippen. Alternativ im Home-Ordner Cmd+Shift+. drücken, das blendet versteckte Ordner ein.
Terminal: open ~/.config/rclone öffnet den Ordner im Finder.

Die Datei ist klein (bei mir 761 Bytes) und nur für dich lesbar (Rechte 600). Sie enthält den pCloud-Token und die Crypt-Passwörter in verschleierter Form. Verschleiert heißt nicht verschlüsselt: rclone reveal macht sie wieder lesbar. Behandle die Datei deshalb wie ein Passwort:

Sichere sie im Passwortmanager (als Anhang), in einem verschlüsselten Container oder auf einem externen Medium.
Lege sie nicht in ein Git-Repository, nicht im Klartext in einen Cloud-Ordner und nicht in einen Chat oder ein Ticket.
Nach einer Wiederherstellung auf einem neuen Mac setzt du die Rechte wieder: chmod 600 ~/.config/rclone/rclone.conf.

Mein 3-2-1-Setup

Mit dem pCloud-Backup ist meine 3-2-1-Strategie komplett. Die Regel: 3 Kopien der Daten, auf 2 verschiedenen Medien, davon 1 an einem anderen Ort.

Kopie	Wo	Medium
Original	Mac bzw. NAS	interne Platte / NAS-Platten
Backup 1	NAS	NAS-Platten
Backup 2	externe Festplatte, vom NAS aus gesichert	externe HDD
Backup 3 (extern)	pCloud, verschlüsselt per rclone crypt	Cloud

Damit sind es mehr als drei Kopien auf zwei Medientypen, und pCloud ist die Kopie außerhalb des Hauses. Sie schützt vor Feuer, Wasser, Einbruch und Überspannung, also vor allem, was NAS und externe Festplatte gleichzeitig treffen kann. Die externe Festplatte zählt nur dann als räumlich getrennt, wenn sie nicht neben dem NAS liegt. Als Offsite-Kopie verlasse ich mich aber auf pCloud.

Das Archiv (archiv/) gibt mir zusätzlich einen Schutz gegen versehentliches Löschen, Überschreiben und Ransomware: Auch wenn ein Fehler oder Schadcode die Dateien im lokalen Ordner verändert und der nächste Lauf das nach aktuell/ spiegelt, liegt der vorherige Stand 90 Tage im Archiv.

Was ich dabei im Blick behalte

Was liegt im pCloud-Backup? Das Skript sichert nur die Ordner in SOURCES. Liegen die wichtigen Daten auf dem NAS, müssen sie dort hinein: entweder die NAS-Freigabe auf dem Mac mounten und den Pfad eintragen, oder rclone direkt auf dem NAS laufen lassen. Ein Backup des Macs allein sichert die Daten auf dem NAS nicht.
Läuft der Mac um 02:00? Ist er aus, entfällt der Lauf, und der Zeitplan holt ihn nicht nach. Bei einem gemounteten NAS-Share muss der Share erreichbar sein. Ist er es nicht, bricht das Skript wegen „Quelle ist leer“ ab, statt das Backup zu leeren.
Fehler fallen nicht von selbst auf. Der Agent liefert bei Fehlern Exit-Code ungleich 0, aber ohne Benachrichtigung. Deshalb schaue ich gelegentlich ins Log (tail ~/Library/Logs/pcloud-backup.log) und prüfe den Status mit launchctl print gui/$(id -u)/de.adrian.pcloud-backup | grep 'last exit'. Eine automatische Meldung bei Fehlern habe ich noch nicht eingebaut.
Wiederherstellung regelmäßig testen. Ein Backup zählt erst, wenn ich es zurückgespielt habe. Einmal im Quartal hole ich eine Datei aus aktuell/ und eine aus dem Archiv zurück und vergleiche die Prüfsummen (siehe Abschnitt 7).
Schlüssel an einem anderen Ort. Crypt-Passwort, Salt und eine Kopie der rclone.conf liegen nicht auf dem Mac, nicht auf dem NAS und nicht auf der externen Festplatte. Wären sie nur dort, wäre das Offsite-Backup bei einem Totalverlust nutzlos. Ich bewahre sie im Passwortmanager und zusätzlich an einem getrennten Ort auf, etwa ausgedruckt oder auf einem USB-Stick.

Nach einer Neuinstallation des Macs

Das Backup ist für genau diesen Fall da. Wichtig ist die Reihenfolge: erst wiederherstellen, dann den Zeitplan wieder einschalten. Läuft das Backup auf einem frischen Mac mit teilweise gefüllten Ordnern, spiegelt sync diesen Zustand nach pCloud. Alles, was dort fehlt, wandert ins Archiv und ist nach 90 Tagen weg.

Du brauchst dafür drei Dinge, die nicht auf dem Mac selbst liegen dürfen:

dein pCloud-Login
das Crypt-Passwort und das Salt aus dem Passwortmanager
optional eine Kopie von ~/.config/rclone/rclone.conf

1. rclone installieren

brew install rclone

Falls Homebrew noch fehlt, installierst du es zuerst von brew.sh.

2. Remotes wiederherstellen

Variante A: Mit der gesicherten rclone.conf (schnell). Kopiere die Datei an ihren Platz:

mkdir -p ~/.config/rclone
cp /Pfad/zur/Sicherung/rclone.conf ~/.config/rclone/rclone.conf
chmod 600 ~/.config/rclone/rclone.conf

Falls der pCloud-Token inzwischen ungültig ist, meldet rclone Authentifizierungsfehler. Dann einmal neu anmelden:

rclone config reconnect pcloud:

Variante B: Ohne rclone.conf (aus Passwortmanager). Lege beide Remotes wie in den Abschnitten 2 und 3 neu an, mit zwei Unterschieden:

Bei pcloudcrypt nicht generieren, sondern bei password die Antwort y wählen und das alte Passwort eintippen. Bei password2 genauso das alte Salt. Ein neues Passwort erzeugt einen anderen Schlüssel, und die alten Daten blieben unlesbar.
Der Remote-Name muss pcloudcrypt heißen und remote = pcloud:Backup zeigen, sonst passen die Skripte nicht.

3. Prüfen, dass der Schlüssel stimmt

rclone lsd pcloud:
rclone lsf pcloudcrypt:aktuell

Der zweite Befehl muss deine Ordner im Klartext zeigen, zum Beispiel TestBackup/. Siehst du stattdessen Fehler wie „failed to decrypt“ oder eine leere Liste, stimmen Passwort oder Salt nicht. In dem Fall nichts weiter tun, sondern die Werte erneut prüfen.

4. Daten zurückholen

Immer in einen neuen, leeren Ordner, nie direkt über vorhandene Daten:

rclone copy pcloudcrypt:aktuell/TestBackup ~/TestBackup-wiederhergestellt --progress

Vorher kannst du mit dem Trockenlauf sehen, was kopiert würde:

rclone copy pcloudcrypt:aktuell/TestBackup ~/TestBackup-wiederhergestellt --dry-run

Ältere Stände findest du im Archiv:

rclone lsd pcloudcrypt:archiv
rclone copy pcloudcrypt:archiv/<Zeitstempel>/TestBackup ./archiv-stand

Prüfe das Ergebnis stichprobenartig und verschiebe den Ordner an seinen alten Platz. Nach dem Zurückkopieren sollte rclone check keine Unterschiede melden:

mv ~/TestBackup-wiederhergestellt ~/TestBackup
rclone check ~/TestBackup pcloudcrypt:aktuell/TestBackup --exclude .DS_Store

Liegt die Quelle am selben Pfad wie früher, findet das nächste Backup keinen Unterschied und überträgt fast nichts.

5. Skripte und Zeitplan wieder einrichten

Die Skripte (und diese Anleitung) solltest du in einem Git-Repository oder einem anderen Backup aufbewahren. Dann:

mkdir -p ~/.local/bin
cp pcloud-backup.sh pcloud-backup-klartext.sh ~/.local/bin/
chmod +x ~/.local/bin/pcloud-backup*.sh

Die plist-Datei aus Abschnitt 6 legst du wieder unter ~/Library/LaunchAgents/ an und passt den Benutzernamen an. Dann zuerst trocken, dann laden:

~/.local/bin/pcloud-backup.sh --dry-run
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/de.adrian.pcloud-backup.plist
launchctl kickstart gui/$(id -u)/de.adrian.pcloud-backup

Der Trockenlauf darf nichts löschen oder archivieren wollen. Sieht er das, stimmt etwas mit der Quelle nicht, und du lädst den Agenten noch nicht.

Die Quelle sollte außerhalb von ~/Desktop, ~/Documents und ~/Downloads liegen, sonst blockiert macOS den Zugriff aus dem Hintergrund (siehe Stolpersteine).

Wenn der Mac verloren ist und du nur noch Passwort und Salt hast

Das reicht. Du brauchst die rclone.conf nicht zwingend, denn pCloud-Login und Crypt-Werte genügen, um die Remotes neu anzulegen (Variante B). Ohne das Crypt-Passwort und das Salt sind die verschlüsselten Daten nicht zu retten. Das Klartext-Backup (pcloud:Backup-Klartext) lässt sich dagegen jederzeit auch ohne rclone im Browser herunterladen.

#backup #rclone #pcloud #macos #launchd

Verschlüsseltes Backup auf pCloud mit rclone

Was am Ende herauskommt

Voraussetzungen

1. rclone installieren

2. pCloud-Remote einrichten

Token nicht weitergeben

3. Verschlüsselung mit rclone crypt

4. Das Backup-Skript

Was das Skript tut

5. Zuerst trocken, dann echt

6. Täglich um 02:00 mit launchd

7. Alles testen, was ich getestet habe

8. Eine Variante ohne Verschlüsselung (manuell)

Stolpersteine, die ich erlebt habe

--min-age 90d löscht zu früh

Leeres Array unter macOS-Bash 3.2

Der Exit-Trap verschluckte den Fehlercode

macOS-Datenschutz (TCC) blockt Hintergrundjobs

Alltag

Das tägliche Backup abstellen

Was du sichern musst

Wo liegt die rclone.conf?

Mein 3-2-1-Setup

Was ich dabei im Blick behalte

Nach einer Neuinstallation des Macs

1. rclone installieren

2. Remotes wiederherstellen

3. Prüfen, dass der Schlüssel stimmt

4. Daten zurückholen

5. Skripte und Zeitplan wieder einrichten

Wenn der Mac verloren ist und du nur noch Passwort und Salt hast

`--min-age 90d` löscht zu früh