Nextcloud Backup Mehr als nur eine Kopie

Nextcloud Backup Strategien: Mehr als nur eine Kopie der Daten

Egal wie sorgfältig Sie Ihre Nextcloud-Instanz betreiben – irgendwann werden Sie froh sein, ein Backup zu haben. Das klingt dramatisch, ist aber schlichte Erfahrung. Ein fehlgeschlagenes Update, ein defekter Datenträger, ein versehentlich gelöschter Ordner: Die Liste der Szenarien, in denen eine Sicherung den Unterschied zwischen stundenlangem Reparaturstress und entspanntem Restore ausmacht, ist lang. Nextcloud ist dabei ein besonderer Fall, denn es kombiniert Daten (Dateien, Kontakte, Kalender) mit einer relationalen Datenbank (MySQL, MariaDB oder PostgreSQL) und einer Vielzahl von App-Konfigurationen. Ein naives „einfach alles kopieren“ führt hier schnell ins Desaster.

Der folgende Artikel richtet sich an Administratoren, die ihre Nextcloud nicht nur betreiben, sondern auch schützen wollen. Kein Patentrezept, aber eine systematische Betrachtung der Komponenten, Werkzeuge und Fallstricke. Denn die optimale Strategie hängt von der Umgebung ab: ob Docker oder Bare Metal, ob Community-Edition oder Enterprise, ob zehn oder zehntausend Benutzer. Fangen wir also mit dem Fundament an.

Die Anatomie einer Nextcloud-Instanz – Was genau muss gesichert werden?

Bevor man über Werkzeuge spricht, sollte man das Ziel verstehen. Eine Nextcloud-Instanz besteht aus mehreren Schichten, die alle konsistent zueinander sein müssen. Die offensichtlichste Schicht sind die Benutzerdaten – also die hochgeladenen Dateien, Fotos, Dokumente. Sie liegen meist im Verzeichnis „data“ (oder einem externen Mount) und können mehrere Terabyte umfassen. Daneben gibt es die Datenbank, die Metadaten speichert: Ordnerstruktur, Freigaben, Nutzerprofile, Einstellungen und vor allem die Zuordnung von Dateipfaden zu ihren entsprechenden Einträgen in der Datenbank. Ohne intakte Datenbank sind die Dateien nur eine Ansammlung von Bytes – sie lassen sich nicht mehr ihrem Besitzer zuordnen.

Hinzu kommen die Konfigurationsdateien der Nextcloud-Instanz: die config.php, in der Einstellungen wie Datenbankverbindung, Redis-Cache oder die nächste Unternehmensintegration hinterlegt sind. Auch die Apps (also Erweiterungen) haben oft eigene Konfigurationen, etwa für externe Speicher wie S3-kompatible Buckets oder für Verschlüsselung. Und nicht zu vergessen: die Transaktionslogs der Datenbank, wenn man Point-in-Time-Recovery (PITR) ermöglichen möchte. Wer Nextcloud in Containern betreibt, muss zusätzlich die Docker-Volumes und die Container-Konfiguration berücksichtigen – etwa docker-compose.yml oder Kubernetes-Manifeste.

Ein interessanter Aspekt ist die Verschlüsselung auf Server-Seite. Nextcloud kann Dateien serverseitig verschlüsseln, was bedeutet, dass die Schlüssel in der Datenbank liegen. Ein Backup, das nur die verschlüsselten Dateien sichert, ohne die Datenbank, ist wertlos. Gleiches gilt für die clientseitige Verschlüsselung (Ende-zu-Ende), bei der aber die Schlüssel beim Benutzer verbleiben – der Administrator ist hier zumindest vom kryptografischen Risiko befreit, muss aber sicherstellen, dass die verschlüsselten Blöcke konsistent gebackupt werden.

Nicht zuletzt spielen externe Speicher eine Rolle. Viele Instanzen nutzen S3-kompatible Objektspeicher für die primären Daten. Das Backup dieser Daten übernimmt dann der Objektspeicher-Anbieter – aber die Metadaten in der Datenbank müssen trotzdem in einem konsistenten Zustand sein. Bei einem Disaster muss die Datenbank den Zustand genau des Moments widerspiegeln, zu dem die Daten im S3-Bucket gesichert wurden. Andernfalls entstehen sogenannte „orphan data“ – Dateien, die in der Datenbank referenziert, aber im Speicher nicht mehr vorhanden sind, oder umgekehrt.

Methoden und Werkzeuge: Von einfach bis robust

Die einfachste Methode, die viele Admins in ihrer Anfangszeit verwenden: ein Skript, das per „mysqldump“ die Datenbank sichert und dann das data-Verzeichnis per rsync auf ein externes Laufwerk kopiert. Das funktioniert – unter einer Bedingung: Die Datenbank muss in einem konsistenten Zustand sein. Ein mysqldump erzeugt eine Momentaufnahme der Datenbank, die logisch konsistent ist, da sie in einer Transaktion läuft. Aber rsync auf die Daten kopiert währenddessen möglicherweise Dateien, die sich gerade ändern, etwa weil ein Benutzer eine Datei hochlädt. Das Ergebnis: Ein Backup, bei dem die Datenbank auf einen bestimmten Zeitpunkt verweist (Dump), die Dateien aber einen anderen Zustand haben – möglicherweise fehlen neuere Dateien, oder teilweise geschriebene Blöcke führen zu Korruption.

Die Lösung heißt Konsistenzsicherung. Entweder man stoppt den Nextcloud-Dienst kurz vor dem Backup (was Downtime bedeutet), oder man nutzt Techniken wie LVM-Snapshots, ZFS-Snapshots oder Dateisystem-Momentsaufnahmen, die einen atomaren Snapshot des gesamten Datenbestands erlauben. Mit LVM kann man einen logischen Snapshot des Volumes erstellen, das Daten und Datenbank enthält, dann in wenigen Sekunden einen kurzen Lock setzen, den Snapshot erstellen und danach den Dienst wieder freigeben. Der Snapshot ist konsistent, da das Dateisystem während der Erstellung eingefroren war. Anschließend kann man den Snapshot mounten und die Daten in Ruhe sichern – meist mit rsync oder tar. Bei ZFS ist das Prinzip ähnlich, aber die Snapshots sind sogar verschiebbar und komprimierbar.

Für Umgebungen, die keine Snapshots unterstützen (etwa einfache Cloud-Server ohne LVM oder mit nicht-snapshottablem Speicher), bieten sich dedizierte Backup-Tools an, die transaktionale Sicherungen ermöglichen. Restic ist ein Open-Source-Werkzeug, das inkrementelle Backups mit deduplizierung und Verschlüsselung erstellt. Es kann parallel zur laufenden Nextcloud betrieben werden, vorausgesetzt man sorgt für Konsistenz auf Datenbankebene. Dazu erstellt man einen mysqldump (oder pg_dump für PostgreSQL) in einen temporären Ordner, sichert diesen und das data-Verzeichnis mit restic. Der Dump repräsentiert einen konsistenten Datenbankzustand, die Dateien werden dann zeitlich versetzt gesichert – das ist nicht perfekt, aber für viele Szenarien akzeptabel, da Nextcloud mit Dateikonflikten umgehen kann. Aber Vorsicht: Ein Konflikt kann zu Datenverlust führen, wenn der Zustand stark auseinanderklafft.

Ein weiteres bewährtes Werkzeug ist BorgBackup. Es bietet ähnliche Funktionen wie restic, hat aber ein anderes Repository-Format und eine etwas andere Philosophie. Beide Tools sind gut dokumentiert und werden in der Nextcloud-Community häufig empfohlen. Wer es einfacher mag: Das Nextcloud-Projekt selbst bietet in der Enterprise-Version ein integriertes Backup-Modul an, das unter anderem Datenbank-Dumps und Dateisicherungen koordiniert. Für die Community-Edition gibt es Drittanbieter-Apps wie „Backup“ (nicht mehr aktiv) oder Skripte wie „nextcloud-backup-restore“ auf GitHub. Diese Skripte automatisieren die Schritte – aber man sollte sie vor dem Ernstfall verstanden haben.

Praktische Umsetzung: Automatisierung und der Albtraum der Wiederherstellung

Backups zu erstellen ist die eine Sache. Sie zu testen, die andere. Und das ist der Punkt, an dem viele Administratoren scheitern. Ein Backup, das nicht regelmäßig auf seine Integrität geprüft wird, ist wie ein Fallschirm, den man nie gefaltet hat – er mag funktionieren, aber man weiß es nicht. Ein bewährtes Mittel: monatliche Restore-Übungen. Man nehme eine frische Umgebung (virtuelle Maschine, Docker-Container oder ein separates Verzeichnis) und spiele das Backup dort ein. Dann überprüft man, ob die Nextcloud startet, ob Benutzer sich anmelden können, ob Dateien lesbar sind und ob die App-Konfigurationen erhalten blieben.

Das klingt aufwändig – und das ist es auch. Aber es deckt typische Fehler auf: Vielleicht wurde die Datenbank mit einem anderen Zeichensatz wiederhergestellt, oder die config.php enthält absolute Pfade, die in der neuen Umgebung nicht existieren. Oder die Backup-Dateien sind korrupt, weil das Speichermedium währed des Backup-Vorgangs ausfiel. Ein Restore-Test simuliert den Ernstfall: 48 Stunden nach dem Crash möchte der Chef wieder auf seine Daten zugreifen. Da zählt jede Stunde.

In der Praxis hat sich folgendes Vorgehen bewährt: Tägliche inkrementelle Backups der Daten (mit restic oder Borg), mindestens eines pro Woche ein vollständiges Backup (oder wenn das zu viel Speicher kostet: ein wöchentlicher Snapshot plus inkrementelle Diffs). Die Datenbank wird vor jedem Backup per mysqldump in einen separaten Ordner gespeichert – entweder mit einem Lock, der den Schreibzugriff kurz pausiert, oder mit einem Replikats-Slave, der die Last abfängt. Noch besser: Man betreibt einen Datenbankreplikat-Server (Read Replica), der kontinuierlich die Transaktionslogs erhält. Für das Backup kann man dann einfach das Replikat anhalten, dort einen Dump erstellen und danach wieder synchronisieren – die Hauptinstanz bleibt unbehelligt.

Ein interessantes Detail: Die Nextcloud-Datenbank enthält auch die Datei-Hashes (SHA-256 oder ähnlich), die zur Integritätsprüfung dienen. Nach einem Restore kann Nextcloud über den occ-Befehl „files:scan“ die Daten neu scannen und mit den Hashes abgleichen. Das ist eine nützliche Funktion, um zu prüfen, ob die Dateien unverändert sind. Aber Achtung: Wenn die Datenbank zurückgespielt wird, aber die Dateien fehlen oder korrupt sind, wird der Scan die Inkonsistenz melden – ein guter Grund, warum man vor dem Restore die Datenbank und die Dateien aus dem gleichen Backup-Repository holen sollte.

Cloud-Integration: S3, Backblaze, Wasabi und die Frage der Verschlüsselung

Immer mehr Nextcloud-Instanzen nutzen externe Objektspeicher – Amazon S3, Backblaze B2, Wasabi oder auch selbstgehostete MinIO-Server. Das hat Vorteile: Skalierbarkeit, Kosteneffizienz (keine teuren lokalem Festplatten, Pay-as-you-go). Und es verlagert das Backup-Problem teilweise zum Anbieter. Die wenigsten Admins sichern ihren S3-Bucket zusätzlich, weil sie darauf vertrauen, dass der Anbieter das selbst tut (und meistens stimmt das auch – Amazon hat eine viel bessere Redundanz als jeder einzelne Server). Aber das Backup-Metadaten-Problem bleibt: Die Datenbank der Nextcloud muss mit dem Zustand des Objektspeichers konsistent sein. Wenn der Objektspeicher ein separates System ist, sollte man auch den Objektspeicher selbst sichern – etwa durch Cross-Region-Replikation oder durch einen eigenen Export.

Ein Trick: Viele legen die Daten (nicht die Datenbank) direkt im S3-Bucket ab, ohne zusätzliches lokales Verzeichnis. Das Backup der Nextcloud-Instanz reduziert sich dann auf die Datenbank, die Konfiguration und eventuell die App-Daten. Für die Dateien vertraut man auf die Anbieter-Sicherung. Das ist in der Regel akzeptabel, solange der Anbieter ein SLA für Datenhaltung bietet – und man sich der Vendor-Lock-in-Konsequenzen bewusst ist. Ein Wechsel zu einem anderen Anbieter erfordert dann einen Export, der Zeit kostet.

Was die Verschlüsselung im Backup-Ziel betrifft: Tools wie restic und Borg verschlüsseln standardmäßig mit starken Algorithmen (AES-256-GCM), bevor die Daten das System verlassen. Das ist gut, denn es schützt vor unbefugtem Zugriff auf das Backup-Medium. Aber der Schlüssel muss natürlich sicher verwahrt werden – am besten getrennt von den Backup-Daten. Bei cloud-basierten Backups sollte man darauf achten, dass die Verschlüsselung clientseitig erfolgt, nicht server-seitig (also beim Backup-Tool und nicht beim Cloud-Provider). Sonst hat der Provider im Zweifel Zugriff auf die Entschlüsselungs-Schlüssel.

Besondere Szenarien: Docker, Kubernetes und der Trend zu Infrastruktur als Code

Nextcloud in Containern ist heute weit verbreitet. Die Docker-Dokumentation empfiehlt, Daten und Datenbank in separaten Volumes zu halten. Ein Backup dieser Volumes ist einfach: Man kann per „docker run –rm -v nextcloud-data:/data -v backupvolume:/backup busybox tar -czf /backup/nextcloud-data.tar.gz -C /data .“ ein tar-Archiv erstellen. Aber auch hier ist der Konsistenzpunkt entscheidend. Stoppt man den Datenbank-Container zuerst, dann den Nextcloud-Container, erstellt die Archive und startet dann beide neu – das ist eine simple, aber funktionierende Methode. Alternativ verwaltet man mit Docker-Compose einen Service, der vor dem Backup die Container pausiert (docker pause) und nach dem Backup wieder unpausiert. Das ist elegant, da die Container kurz eingefroren werden, statt komplett herunterzufahren.

In Kubernetes-Umgebungen nutzt man häufig Velero oder Stash, um Persistent Volumes zu sichern. Diese Tools können Snapshot-basierte Backups von PVCs (Persistent Volume Claims) erstellen, sofern der Cloud-Provider entsprechende Snapshot-Fähigkeiten bietet. Auch hier muss die Datenbank konsistent sein – etwa indem man einen Dump in einen temporären PVC schreibt und den Snapshot des Datenbank-PVCs vermeidet. Oder man setzt auf einen eigenen Backup-Scheduler, der per mysqldump in den Snapshot-Pfad schreibt. Die Komplexität steigt mit der Anzahl der Komponenten, aber die Prinzipien bleiben gleich.

Ein Trend, der sich abzeichnet: Infrastruktur als Code (IaC) erlaubt es, die gesamte Nextcloud-Umgebung als Konfiguration zu behandeln. Das erleichtert Disaster Recovery enorm: Statt eines mühsamen Restores auf dem alten Server installiert man eine neue Instanz auf Basis der IaC-Dateien (z.B. mit Ansible, Terraform oder einem Docker-Compose-Datei), importiert die Datenbank und die Dateien – und schon läuft wieder alles. Aber auch hier gilt: Die IaC-Dateien selbst müssen gesichert werden (im Versionierungssystem, etwa Git). Ein Backup ohne die IaC-Konfiguration ist wie ein Auto ohne Zündschlüssel.

Fallstricke und typische Fehler

Aus der Praxis lässt sich eine Liste wiederkehrender Probleme zusammenstellen. Der häufigste Fehler: Nur die Dateien sichern, aber die Datenbank vergessen. Das Resultat ist nicht etwa eine unvollständige Instanz, sondern eine funktionslose. Nextcloud startet nicht, weil die Datenbank fehlt oder inkonsistent ist. Der zweite Fehler: Ein Backup, das zu selten aktualisiert wird. Wenn die letzte Vollsicherung drei Monate alt ist, sind im Disasterfall viele Daten verloren (es sei denn, man hat inkrementelle Sicherungen). Der dritte Fehler: Kein Offsite-Backup. Ein Gebäudebrand, ein Wasserschaden oder ein Ransomware-Angriff, der auch das Backup-Laufwerk trifft (weil es im selben Server steckt oder per Netzwerk erreichbar ist), macht jedes lokale Backup zunichte. Die 3-2-1-Regel (drei Kopien, auf zwei verschiedenen Medien, eine davon offsite) ist nicht veraltet.

Ein weiterer, subtiler Fehler: Die Datenbank-Konsistenzprüfung nach dem Restore unterlassen. Ein mysqldump ist meist konsistent, aber wenn während des Dumps eine lange Transaktion lief, kann es zu Inkonnsistenzen kommen. Der Befehl „occ db:check“ (Nextcloud-Kommando) führt eine Prüfung der Datenbankintegrität durch – den sollte man nach einem Restore auf jeden Fall laufen lassen. Und dann: die Datei-Prüfung per „occ files:scan –all“. Das kann bei großen Instanzen Stunden dauern, aber es ist der einzige Weg, um sicherzustellen, dass die verknüpften Daten auch wirklich vorhanden sind.

Nicht zuletzt: Die Backup-Strategie dokumentieren. Wer ein Skript schreibt, das alle paar Tage läuft, aber nie dokumentiert, wie das Restore genau funktioniert, wird im Ernstfall hektisch herumprobieren. Ein einfaches Markdown-Dokument mit den Schritten: „1. Neue VM mit Ubuntu 22.04 aufsetzen. 2. Docker installieren. 3. docker-compose.yml aus dem Backup kopieren. 4. Datenbank-Dump importieren. 5. data-Volume entpacken. 6. occ upgrade ausführen. 7. Inbetriebnahme testen.“ Das rettet Nerven.

Ausblick: Was die Zukunft bringt

Nextcloud selbst arbeitet an verbesserten Backup-Funktionen. Seit Version 25 gibt es einen occ-Befehl, der einen „maintenance mode“ setzt und dann einen Dump samt Dateien erstellt – ähnlich wie die Enterprise-Lösung. Auch die Integration von S3-kompatiblen Speichern wird immer nahtloser. Aber die grundlegende Herausforderung bleibt: Eine komplexe Verteilanwendung mit unterschiedlichen Komponenten konsistent zu sichern, erfordert Wissen und Sorgfalt. Tools wie restic und Borg machen vieles einfacher, aber sie ersetzen nicht die Überlegung, ob das Backup auch das benötigte Recovery-Ziel erreicht.

Ein interessanter Trend ist die immutable Backup-Architektur: Speicherplatz, auf dem einmal geschriebene Daten nicht mehr verändert oder gelöscht werden können (z.B. via Object-Lock auf S3). Das schützt vor Ransomware, die auch die Backup-Dateien verschlüsseln könnte. Kombiniert mit der 3-2-1-Regel und regelmäßigen Tests ergibt sich eine robuste Strategie. Allerdings benötigt man dafür oft separate Backup-Infrastruktur – was wiederum Kosten verursacht. Entscheider müssen abwägen: Was kostet ein Ausfall? Ein Unternehmen, das seine Nextcloud als zentrale Kollaborationsplattform nutzt, wird die Investition rechtfertigen können. Ein privater Nutzer mit 50 GB Dateien mag mit einem einfachen rsync auf eine externe Festplatte auskommen.

Abschließend sei gesagt: Die perfekte Backup-Strategie gibt es nicht – aber eine gute. Sie ist das Ergebnis von Analyse, Umsetzung und regelmäßiger Überprüfung. Und sie ist immer besser als gar keine. Denn egal, wie gut die Software ist – ein Fehler bleibt menschlich. Und die Daten? Die sollten bleiben, was sie sind: sicher.