Nextcloud Backup: Mehr als nur eine Sicherungskopie

Die eigene Cloud ist nur so gut wie ihr letztes Backup. Doch bei Nextcloud geht es um weit mehr als um das simple Kopieren von Dateien. Eine durchdachte Strategie sichert nicht nur Daten, sondern auch die komplexe Infrastruktur, Metadaten und – was oft vergessen wird – das Vertrauen der Nutzer. Ein Überblick über sinnvolle Ansätze, handfeste Tools und häufige Denkfehler.

Wer Nextcloud betreibt, übernimmt Verantwortung. Für Kalendertermine, geteilte Dokumente, oft sensible Kommunikation über Talk. Es ist die digitale Schaltzentrale für Teams, Vereine oder Familien. Ein Ausfall ist ärgerlich, ein Datenverlust kann existenzbedrohend sein. Und dennoch: Das Backup bleibt oft Stiefkind, ein lästiger Posten auf der To-do-Liste, der nach dem Prinzip „Hauptsache, irgendwas liegt auf einer externen Platte“ abgehakt wird. Das ist grob fahrlässig. Nextcloud ist eine Anwendung mit State – einem Zustand. Sie besteht aus einer Datenbank, Konfigurationsdateien, App-Daten, einem Dateisystem und eventuell sogar Objektstorage. All diese Komponenten müssen konsistent gesichert und, was noch kniffliger ist, wiederhergestellt werden können.

Die Anatomie einer Nextcloud-Instanz: Was muss überhaupt gesichert werden?

Bevor man über das „Wie“ spricht, muss das „Was“ klar sein. Eine typische Nextcloud-Installation setzt sich aus mehreren, teilweise verwobenen Schichten zusammen. Das einfache Sichern des Datenverzeichnisses, wo die Nutzerdateien liegen, ist nur ein Teil der Wahrheit. Stellen Sie sich Nextcloud wie eine mehrstöckige Fabrik vor: Im Erdgeschoss lagern die Rohmaterialien (die Dateien), aber im ersten Stock laufen die Maschinen (die Datenbank), die wissen, wem was gehört und wie es verarbeitet wird. Die Baupläne der Maschinen liegen im Büro (die Konfiguration).

1. Die Nutzerdaten (data/-Verzeichnis): Das Offensichtliche. Hier liegen hochgeladene Dateien, verschlüsselt oder unverschlüsselt. Die Größe ist der bestimmende Faktor für das Backup-Volumen.

2. Die Datenbank (meist MySQL/MariaDB oder PostgreSQL): Das Herzstück. Hier werden Benutzer, Gruppen, Freigabe-Links, Datei-Metadaten (Pfad, Größe, Versionshistorie), Aktivitäten, App-Konfigurationen und vieles mehr verwaltet. Ein Backup der Dateien ohne das konsistente Backup der Datenbank ist wertlos – Sie erhalten einen Haufen Bits ohne Kontext.

3. Die Nextcloud-Codebasis und Konfigurationsdateien: Das config/config.php-File enthält Geheimnisse wie Salts und Passwörter. Die installierten Apps (apps/ und apps-extra/) sowie deren Zustände gehören ebenfalls hierher. Die Codebasis selbst kann zwar neu heruntergeladen werden, die individuelle Konfiguration nicht.

4. App-spezifische Daten: Manche Apps, wie die Preview-Generierung oder bestimmte Groupware-Funktionen, legen eigene Caches oder Datenbank-Tabellen an, die außerhalb des Standard-data/-Verzeichnisses liegen können.

5. Der externe Storage (optional): Wenn S3, SFTP oder andere externe Speicher angebunden sind, muss deren Backup gesondert bedacht werden – Nextcloud sichert diese Inhalte nicht automatisch mit.

Die Grundsatzfrage: Filesystem-Backup vs. Application-Aware Backup

Hier scheiden sich die Geister. Der pragmatische Ansatz nutzt einfache Dateisystem-Tools wie rsync, tar oder BorgBackup, um die gesamte Server-Partition oder spezifische Verzeichnisse zu sichern. Vorteil: Einfachheit, Unabhängigkeit von Nextcloud, oft hohe Geschwindigkeit. Nachteil: Für eine konsistente Sicherung muss die Nextcloud-Instanz idealerweise angehalten werden, um keine halbgeschriebenen Dateien oder inkonsistenten Datenbankzustände zu erfassen. Im laufenden Betrieb ist dies riskant.

Der anwendungsbewusste (Application-Aware) Ansatz hingegen nutzt Tools, die mit Nextcloud und seiner Datenbank „sprechen“. Sie sorgen dafür, dass vor dem Snapshot die Datenbank in einen konsistenten Zustand versetzt wird (z.B. durch einen Dump oder ein FLUSH TABLES WITH READ LOCK). Das Open-Source-Tool Nextcloud Backup (nc-backup) oder kommerziale Lösungen von Hostern folgen diesem Prinzip. Sie verstehen die Nextcloud-Struktur und können oft auch inkrementelle Backups auf App-Ebene durchführen. Nachteil: Höhere Komplexität, Bindung an die Nextcloud-Architektur.

Ein interessanter Kompromiss sind moderne Dateisystem-Snapshots (ZFS, Btrfs). Sie können blitzschnell einen konsistenten Punkt-in-Time-Zustand des gesamten Systems erfassen, ohne es stoppen zu müssen. Kombiniert man einen solchen Snapshot mit einem gezielten MySQL-Dump direkt davor, hat man eine sehr robuste Basis. Dabei zeigt sich: Die Wahl des darunterliegenden Dateisystems hat direkte Auswirkungen auf die Backup-Strategie.

Werkzeugkasten: Von rsync bis Restic

Die Auswahl an Tools ist groß. Jedes hat seinen Charakter und seine optimale Einsatzdomäne.

rsync: Der altehrwürdige Klassiker. Perfekt für synchrone Spiegelungen auf ein anderes Laufwerk oder einen zweiten Server. Allein ist es kein Backup-Tool im engeren Sinne, da es standardmäßig löscht. In Kombination mit harten Links (z.B. via rsnapshot) oder als Transportmechanismus für andere Tools aber unschlagbar effizient.

BorgBackup: Viele Administratoren schwören darauf. Deduplizierung, Kompression, Verschlüsselung, clientseitig. Borg sichert Dateien und behält dabei eine historische Versionierung bei. Ideal für die regelmäßige Sicherung des data/-Verzeichnisses und von MySQL-Dumps. Seine Stärke ist die Effizienz bei großen, sich wenig ändernden Datensätzen – genau das typische Nextcloud-Szenario.

Restic: Ähnlich Borg, aber mit einem Fokus auf Cloud-Storage-Backends (S3, B2, Wasabi). Einfacher zu konfigurieren, vielleicht etwas weniger feinjustierbar. Seine „Snapshots“ sind ebenfalls dedupliziert und verschlüsselt. Eine gute Wahl, wenn das Backup-Ziel von vornherein ein Object Storage sein soll.

Duplicati / Duplicacy: Client-Tools mit GUI, die sich auch für dezentrale Backups von Desktop-Clients eignen. Können Nextcloud-Server als Quelle sichern, sind aber eher für Workstations gedacht. Für den Server-Betrieb sind sie oft zu schwerfällig.

Veeam Agent for Linux / Commvault etc.: Enterprise-Lösungen. Sie bieten Application-Awareness auch für MySQL und können ganze Systeme als Image zurückrollen. Kostspielig, aber mächtig, besonders in heterogenen Umgebungen.

Meine praktische Empfehlung für mittlere Installationen: Ein Shell-Skript, das 1.) Nextcloud in den Wartungsmodus versetzt, 2.) einen MySQL-Dump erstellt, 3.) einen Dateisystem-Snapshot (falls verfügbar) macht oder einfach die relevanten Verzeichnisse (/var/www/nextcloud/, /var/nextcloud_data/) packt, und 4.) dieses Bundle mit Borg oder Restic verschlüsselt und dedupliziert auf ein entferntes Ziel schiebt. Danach wird Nextcloud wieder aktiviert. Dieser Prozess lässt sich zuverlässig automatisieren.

Die 3-2-1-Regel ist nicht verhandelbar

Jede seriöse Backup-Diskussion mündet hier: Drei Kopien der Daten, auf zwei unterschiedlichen Medien, eine davon offsite. Für Nextcloud bedeutet das konkret:

• Kopie 1: Die laufende Produktivinstanz. Zählt nicht wirklich als Backup, aber sei’s drum.
• Kopie 2: Ein lokales Backup auf einer separaten Festplatte, einem NAS oder einem anderen Server im gleichen Rechenzentrum. Schnell für Restores.
• Kopie 3 (offsite): Ein Backup an einem physisch anderen Ort. Das kann ein Cloud Storage wie AWS S3 Glacier, Backblaze B2, ein Hetzner Storage Box oder auch einfach ein Server bei Ihnen zu Hause sein. Wichtig: Dieses Backup muss gegen Ausfall des primären Standorts schützen (Brand, Diebstahl, Konfigurationsfehler des Hosters).

Die Krux liegt oft im Offsite-Backup. Die initiale Übertragung von mehreren Terabyte Nutzdaten kann Wochen dauern. Hier helfen Seed-Verfahren: Man startet das erste Backup lokal auf eine portable Festplatte, schickt diese per Post zum Offsite-Standort und synchronisiert anschließend nur noch die Differenzen über das Netz. Tools wie Restic und Borg unterstützen solche Workflows.

Versionierung und Aufbewahrungsrichtlinien

Nextcloud hat eine eingebaute Dateiversionierung. Die ist praktisch für den Nutzer, die sich mal eine ältere Version eines Dokuments zurückholen wollen. Sie ist aber kein Backup-Ersatz. Eine gelöschte Datei verschwindet samt ihrer Versionen aus der Nextcloud-Oberfläche (wird nach konfigurierbarer Zeit endgültig gelöscht).

Ein richtiges Backup-System muss eigene Aufbewahrungsrichtlinien (Retention Policies) haben. Wie viele tägliche Snapshots behalte ich für eine Woche? Wie viele wöchentliche für einen Monat? Wie viele monatliche für ein Jahr? Borg und Restic können das mit Befehlen wie borg prune oder restic forget automatisch verwalten. Das verhindert, dass das Backup-Ziel unkontrolliert wächst. Ein gängiges Schema: 7 tägliche, 4 wöchentliche, 12 monatliche Backups halten. Wichtig: Testen Sie, ob der Restore aus einem mehrere Monate alten Backup auch funktioniert – gerade bei Datenbank-Updates kann es hier zu Überraschungen kommen.

Der schlimmste Albtraum: Der Restore

Backups, die nicht getestet wurden, existieren nicht. Das ist keine Floskel, sondern bittere Erfahrung. Ein Restore-Test muss regelmäßig, zum Beispiel vierteljährlich, auf einem isolierten System durchgeführt werden. Das Prozedere:

1. Einen frischen Server mit der gleichen Basis-OS-Version provisionieren.
2. Nextcloud-Codebasis und Abhängigkeiten (PHP, DB) installieren.
3. Das gesicherte Backup einspielen: Datenbank-Dump importieren, Dateien ins korrekte Verzeichnis kopieren, Konfiguration anpassen (evtl. IP/URL).
4. Nextcloud-Wartungsmodus beenden und occ maintenance:repair ausführen.
5. Funktionstest: Einloggen, Dateien ansehen, Freigaben prüfen, App-spezifische Funktionen testen.

Nur so finden Sie heraus, ob Ihr Backup-Skript wirklich alle Puzzleteile erfasst hat. Ein häufiger Fehler: Vergessen, die App-Daten von Drittanbietern oder bestimmte cron-Job-Konfigurationen mitzunehmen. Nicht zuletzt misst man bei diesem Test die wichtigste Kennzahl überhaupt: Die Recovery Time Objective (RTO). Wie lange dauert es, bis nach einem Totalausfall die Cloud wieder läuft? Wenn es drei Tage sind, müssen Sie Ihre Strategie überdenken.

Spezialfall: Skalierte und hochverfügbare Installationen

Bei großen Nextcloud-Instanzen mit mehreren App-Servern, einem separaten Datenbank-Cluster und einem verteilten Dateisystem (z.B. GlusterFS, Ceph) oder S3-Object-Storage wird es komplex. Ein einfacher Filesystem-Snapshot greift nicht mehr.

Hier muss man auf die Stärken der einzelnen Komponenten setzen: Die Datenbank (z.B. Galera Cluster) bietet eigene Snapshot- oder Export-Mechanismen. Der Object Storage (wie MinIO oder Ceph) hat integrierte Versionierung und Replikation. Die Herausforderung ist die konsistente Erfassung eines globalen Zustands über alle Dienste hinweg. Oft bleibt nur ein fenster (Maintenance Window), in dem die Lastbalancer die Instanzen nacheinander in den Wartungsmodus schalten, während ein zentrales Skript die Schnappschüsse koordiniert. Oder man vertraut auf die Replikationsfeatures der Infrastruktur und hält einen kompletten, abgeschalteten Standby-Cluster als „lebendes Backup“ vor. Kostspielig, aber schnell im Disaster-Fall.

Verschlüsselung: Wer hat den Schlüssel?

Backups enthalten potenziell alle sensiblen Daten Ihrer Nutzer. Daher ist Verschlüsselung auf dem Backup-Ziel Pflicht. Borg und Restic machen das von Haus aus. Die entscheidende Frage ist die Schlüsselverwaltung. Wo liegt das Passwort oder der Private Key? Wenn er auf dem gleichen Server liegt, der abfackelt, sind die Backups unbrauchbar. Der Schlüssel muss physisch getrennt und sicher verwahrt werden. Für Automatisierung bieten sich Secrets-Manager wie HashiCorp Vault an, die den Schlüssel nur bei Bedarf und für autorisierte Systeme freigeben. Ein manueller Schritt beim Restore ist aber aus Sicherheitssicht oft sogar wünschenswert.

Die größten Denkfehler und wie man sie vermeidet

1. „Mein Hoster macht schon Backups.“ Hosting-Backups dienen in erster Linie dem Hoster, sein System bei Hardwarefehlern schnell wiederherzustellen. Sie haben selten die Granularität oder Retention, die Sie benötigen. Und Sie haben keine Kontrolle darüber. Eigenverantwortung ist hier das Zauberwort.

2. „RAID ist ein Backup.“ Nein. RAID schützt vor Hardwareausfall einer Festplatte. Nicht vor Löschung durch Fehlkonfiguration, Ransomware, logical errors oder einem defekten Stromteil, das alle Platten grillt.

3. „Wir sichern nur die Datenbank einmal wöchentlich, die Dateien täglich.“ Das führt zu einem inkonsistenten Gesamtzustand beim Restore. Die Dateiversion vom Dienstag passt vielleicht nicht mehr zur Datenbank vom Montag. Beide müssen aus dem gleichen logischen Zeitpunkt stammen.

4. „Das Backup-Laufwerk ist immer angeschlossen.“ Das macht es anfällig für Ransomware, die auch angeschlossene Netzlaufwerke verschlüsselt. Backup-Medien sollten nach dem Schreibvorgang getrennt oder zumindest read-only gemountet werden.

5. „Wir haben noch nie einen Restore gebraucht, also funktioniert es.“ Siehe oben. Das ist Russian Roulette.

Ein Blick in die Praxis: Drei Szenarien

Kleine private Instanz auf einem VPS (z.B. bei Hetzner): Einfaches Skript, das täglich nachts per Cron einen MySQL-Dump macht und zusammen mit dem /var/www/nextcloud-Verzeichnis via Borg auf eine Hetzner Storage Box (das ist das Offsite) sichert. Kostet wenige Euro im Monat, ist automatisiert und erfüllt 3-2-1.

Mittlere Unternehmensinstanz auf eigenem Server: Der Server nutzt ZFS. Täglich wird ein automatischer Snapshot des gesamten Pools erstellt. Zusätzlich wird vor dem Snapshot ein MySQL-Dump in ein spezielles Verzeichnis geschrieben, das im Snapshot landet. Diese Snapshots werden lokal behalten. Einmal pro Woche wird der letzte Snapshot mit zfs send/receive auf einen zweiten Server im anderen Gebäude repliziert. Zusätzlich läuft ein Restic-Job, der alle sieben Tage die wichtigsten Konfigurationsdateien und den MySQL-Dump verschlüsselt auf S3 Glacier speichert – als letzte Rettung.

Große, skalierte Installation mit S3 Storage: Die Nutzerdaten liegen ohnehin in einem S3-kompatiblen Object Storage (z.B. MinIO), der die Object-Versionierung aktiviert hat. Somit ist eine Datei-Ebene gesichert. Die Datenbank (ein Galera Cluster) wird stündlich mit mydumper konsistent exportiert, die Dumps landen ebenfalls im S3. Die Nextcloud-Konfigurationsserver werden via Ansible beschrieben; ihr Zustand ist also Code. Das eigentliche Backup besteht hier aus den S3-Bucket-Policies und den automatisierten Datenbank-Dumps, die mit einer Lifecycle-Policy nach 90 Tagen in einen Archiv-Tier verschoben werden.

Fazit: Backup als Teil der Betriebskultur

Eine gute Nextcloud-Backup-Strategie ist kein einmaliges Projekt, sondern ein lebendiger Prozess. Sie beginnt mit dem Verständnis der eigenen Architektur, wählt die passenden, möglichst einfachen Tools, implementiert die 3-2-1-Regel ohne Kompromisse und etabliert einen rigorosen Testzyklus für den Restore. Die eigentliche Arbeit liegt nicht im Einrichten, sondern im Überwachen der Backup-Logs, im regelmäßigen Testen und im Anpassen an Wachstum und Architekturänderungen.

Am Ende geht es nicht um Bits und Bytes, sondern um Vertrauen und Zuverlässigkeit. Wenn Nutzer ihre Daten Ihrer Nextcloud anvertrauen, vertrauen sie implizit auch Ihrer Fähigkeit, diese Daten zu schützen. Ein solides Backup ist die technische Umsetzung dieses Versprechens. Es ist die stille, oft unsichtbare Basis, die den mutigen Einsatz von Selbstbestimmung und Digital-Souveränität, für die Nextcloud steht, überhaupt erst ermöglicht. Man könnte auch sagen: Wer keine Zeit für ein gutes Backup hat, wird irgendwann sehr viel Zeit für die Fehlersuche und Datenbeschaffung haben – ohne Garantie auf Erfolg.