# nextcloud-borg-backup Verifizierte, versionierte Sicherung von Nextcloud auf das Synology-NAS. Die Workstation liest `Nextcloud:` direkt mit rclone, prüft einen privaten lokalen Zwischenstand und erstellt daraus verschlüsselte Borg-Archive auf `/net/thor/volume1/NetBackup/Nextcloud/borg-repo`. Der Desktop-Mount `~/Nextcloud` ist unabhängig davon. Die Übertragung geht ausschließlich **von Nextcloud zum NAS**. Dateien werden in Nextcloud weder geändert noch gelöscht. Das NAS enthält eine Borg-Historie, keinen gewöhnlichen Dateispiegel; gelöschte oder überschriebene Dateien bleiben aus älteren Archiven wiederherstellbar. ## Schutz und Zeitplanung - Alle 15 Minuten wird geprüft, ob eine Sicherung fällig ist; nach Erfolg frühestens nach 24 Stunden. Fehler werden beim nächsten Timerlauf erneut versucht, auch nach Neustart oder Aufwachen. - Eigene direkte Cloud-Verbindung ohne FUSE-Verzeichnis-Cache. Vollständige Inventur vor und nach der Übertragung; Abbruch bei Dateiänderungen während des Laufs; wechselnde WebDAV-Prüfsummen werden zusätzlich inhaltlich geprüft. - SHA1/MD5-Prüfung des Zwischenstands gegen Nextcloud. Dateien ohne Serverhash werden vollständig neu gelesen und per Downloadvergleich geprüft. - Vor und nach der Cloud-Übertragung: Prüfung des tatsächlichen NFS-Mounts, des vorhandenen Repositorys und des freien Speicherplatzes. Keine automatische Repository-Neuanlage im Backup. - Schutz vor leerer Quelle, Rückgang von Dateizahl oder Datenmenge um mehr als 20 Prozent und mehr als 1.000 Löschungen im lokalen Zwischenstand. - Jeder neue Borg-Stand wird vollständig auf Lesbarkeit und Datenintegrität geprüft; Dateizahl und Bytezahl müssen zur Cloud-Inventur passen. Erst dann gilt der Lauf als bestätigt. - Vier Wochen Historie, zusätzlich mindestens sieben Archive; Bereinigung ausschließlich nach erfolgreicher Sicherung. Fehlgeschlagene Wartung wird separat erneut versucht. - Unabhängiger stündlicher Alterswächter: Desktop-Warnung bei mehr als 36 Stunden ohne bestätigte Sicherung. Warnungen maximal alle sechs Stunden, Fehler und Details im Journal. ## Installation / Update Voraussetzungen: Linux, systemd User Manager, Python 3.9+, Borg **1.x** (getestet mit 1.4.5), rclone, util-linux (`findmnt`, `flock`), GNU coreutils und optional `notify-send`. rclone muss `Nextcloud:` bereits authentifiziert kennen; das NAS wird durch das vorhandene autofs eingebunden. ```bash cd ~/localdev/nextcloud-borg-backup make check ./scripts/install.sh systemctl --user start --no-block nextcloud-borg-backup.service journalctl --user -u nextcloud-borg-backup.service -f ``` Bestehende Konfiguration, Passphrase und Historie bleiben erhalten. Neue Einstellungen haben kompatible Standardwerte; siehe [etc/config.example](etc/config.example). Für neue Installationen: Konfiguration und NAS prüfen, das Repository einmal ausdrücklich mit `nextcloud-borg-backup init` anlegen. Das Backup selbst legt niemals ein Ersatzrepository an. Der lokale Zwischenstand benötigt ungefähr die Datenmenge der Cloud. Zusätzlich fordert der konservative Speichercheck vor jedem Lauf noch einmal diese Datenmenge plus 5 GiB freien Speicher. Ein Zwischenstand gehört auf einen privaten lokalen Datenträger, niemals auf den Desktop-Mount. ## Zwischenstand auf einer zweiten lokalen Platte `STAGING_DIR` muss der echte absolute Verzeichnispfad sein. Ein Home-Symlink kann für den manuellen Zugriff daneben bestehen, darf aber nicht als Backup-Arbeitsverzeichnis konfiguriert werden. Für eine separate Datenplatte beide Schutzwerte fest hinterlegen: ```bash STAGING_DIR="/mnt/data/johannes/nextcloud-borg-backup/staging" EXPECTED_STAGE_MOUNT="/mnt/data" EXPECTED_STAGE_UUID="UUID-DER-DATENPLATTE" ``` Die UUID einmal mit `findmnt -no UUID --mountpoint /mnt/data` auslesen und als festen Wert eintragen. Nicht bei jedem Lauf dynamisch neu ableiten. Die Prüfung lehnt einen fehlenden Mount oder anderen Datenträger vor dem Anlegen des Zwischenstands und vor dem Sync ab. Ohne beide Optionen bleibt der bisherige Betrieb im Home-Verzeichnis kompatibel. Vor einem Umzug Timer anhalten, laufende Sicherung beenden lassen und den Backup-Lock übernehmen. Daten kopieren und Inhalte/Metadaten prüfen; Original zunächst behalten. `staging.owner.json` am neuen Ort muss denselben Remote und den neuen tatsächlichen Pfad enthalten. Erst dann Konfiguration umstellen, optional am ursprünglichen Home-Pfad einen Symlink anlegen und eine vollständige Sicherung prüfen. Die alte Kopie erst nach erfolgreicher Abnahme entfernen; danach Timer wieder einschalten. Schlüssel, Borg-Repository und Historie bleiben an ihren bisherigen Orten. ## Betrieb und Wiederherstellung ```bash nextcloud-borg-backup health # JSON, Exit 0: aktuell, Exit 2: überfällig nextcloud-borg-backup backup # sofortiger manueller Lauf nextcloud-borg-backup backup --if-due # wie der Timer nextcloud-borg-backup list nextcloud-borg-backup info systemctl --user list-timers 'nextcloud-borg-*' nextcloud-borg-backup restore "" "Dokumente/Beispiel.pdf" ~/Restore-Test nextcloud-borg-backup mount nextcloud-borg-backup umount ``` Eine manuelle Sofortsicherung kann lange dauern. Das Archiv wird erst nach erfolgreicher Datenprüfung als bestätigt markiert. `health` zeigt auch die letzte fehlgeschlagene Phase; `status` zeigt die herkömmlichen Borg-Informationen. Die Passphrase in `~/.config/nextcloud-borg-backup/passphrase` und ein Borg-Schlüsselexport gehören zusätzlich an einen sicheren unabhängigen Ort. Niemals ins Repository einchecken. Der lokale Zwischenstand ist unverschlüsselt; seine Dateirechte sind privat, eine Datenträgerverschlüsselung richtet dieses Projekt nicht ein. Details, Fehlerbehandlung, Grenzen und Abnahme: [Dokumentation.md](Dokumentation.md). ## Abnahme am 26.10.2026 Auf der Workstation eingerichtet und produktiv geprüft: **8.218 Dateien, 38.274.641.627 Bytes**, Archiv `nextcloud-2026-10-26_12-48-01`. Vollständige Archivdatenprüfung und Repository-Prüfung erfolgreich. Drei Dateien aus dem NAS-Archiv wiederhergestellt und per SHA-256 mit dem geprüften Zwischenstand verglichen: alle identisch. `health` meldet `healthy: true`; beide Timer sind aktiv. 18 automatisierte Tests bestanden. Details stehen in der Betriebsdokumentation.