Nextcloud hat sich in den letzten Jahren als eine der führenden Open-Source-Plattformen für Dateisynchronisation, File-Sharing und kollaboratives Arbeiten etabliert. Millionen von Nutzern – vom kleinen Verein bis zum großen Konzern – vertrauen auf die selbst gehostete Alternative zu den Hyperscalern. Doch eine Frage wird erstaunlich oft vernachlässigt, fast verdrängt: Wie sorge ich für ein zuverlässiges Backup meiner Nextcloud-Instanz? Es ist die Achillesferse vieler Installationen. Ein Serverabsturz, ein fehlgeschlagenes Update, ein menschlicher Fehler oder gar ein Ransomware-Angriff – und die gesamte Datenhaltung steht in Frage. Dabei zeigt sich immer wieder: Die meisten Ausfälle sind hausgemacht, nicht etwa die Schuld böswilliger Hacker oder unzuverlässiger Hardware. Wer Nextcloud ernsthaft betreibt, kommt um ein durchdachtes Backup-Konzept nicht herum. Das ist kein schickes Feature, sondern die Grundlage für jede ernsthafte Nutzung.
Die Architektur und ihre Tücken
Um ein effektives Backup zu entwerfen, muss man die Architektur einer Nextcloud-Instanz verstehen. Sie ist kein monolithischer Block, sondern ein Zusammenspiel mehrerer Komponenten, die alle gesichert werden müssen. Das beginnt bei der Datenbank – in der Regel MariaDB oder PostgreSQL –, die sämtliche Metadaten, Benutzerkonten, Freigaben, Einstellungen und die Verknüpfung der Dateien verwaltet. Ohne eine konsistente Datenbank sind die gespeicherten Dateien wertlos, weil die Zuordnung fehlt. Dann gibt es das Dateisystem, in dem die eigentlichen Nutzerdaten liegen. Nextcloud verwendet einen Ordner namens data, der alle hochgeladenen Dateien enthält – oft strukturiert in Unterordnern nach Benutzern und Versionen. Hinzu kommt der Konfigurationsordner config mit der config.php, die sensible Informationen wie Datenbankzugänge, Verschlüsselungsschlüssel und App-Einstellungen enthält. Nicht zuletzt speichern viele Apps eigene Daten, etwa in der Datenbank oder in speziellen Verzeichnissen unter apps oder custom_apps. Diese Heterogenität macht ein simples Kopieren der Dateien oft unzureichend. Wer einfach per rsync den gesamten Nextcloud-Ordner auf ein anderes Laufwerk spiegelt, riskiert inkonsistente Zustände – die Datenbank kann während des Kopiervorgangs verändert werden, Dateien werden nur teilweise geschrieben oder Metadaten passen nicht mehr.
Ein interessanter Aspekt ist die Dateiversionierung, die Nextcloud standardmäßig anbietet. Ältere Versionen einer Datei werden im Verzeichnis files_versions abgelegt, gelöschte Dateien landen im Papierkorb (files_trashbin). Diese Daten wachsen schnell an und verbrauchen mitunter ein Vielfaches des eigentlichen Speicherplatzes. Ein Backup, das diese Versionen nicht berücksichtigt, kann im Wiederherstellungsfall zu Datenverlust führen, weil die Versionierung dann fehlt. Andererseits kann eine unbedachte Sicherung aller Versionen die Backup-Dauer und das Speichervolumen unnötig aufblähen. Hier ist eine strategische Entscheidung gefragt: Welche Daten muss ich wirklich wiederherstellen können? Nicht jeder braucht alle Versionen der letzten zwei Jahre. Ein guter Kompromiss ist, die Versionierung auf einen sinnvollen Zeitraum zu begrenzen und diesen dann auch im Backup abzubilden.
Backup-Strategien: Nicht alle Wege führen nach Rom
Es gibt nicht die eine perfekte Backup-Lösung für Nextcloud. Die Wahl hängt von der Größe der Installation, der Kritikalität der Daten und den vorhandenen Ressourcen ab. Drei grundlegende Ansätze kristallisieren sich in der Praxis heraus: das klassische Datei-Backup mit geplanten Downtimes, das Hot-Backup mittels Snapshots und das inkrementelle Backup mit spezialisierten Tools. Viele Administratoren kombinieren diese Methoden, um sowohl im Alltag schnell zu sein als auch im Ernstfall ein konsistentes Abbild zu haben. Besonders beliebt, weil relativ einfach umsetzbar, ist die Kombination aus rsync für die Dateien und mysqldump für die Datenbank, jeweils im laufenden Betrieb. Das birgt jedoch das Risiko, dass die Datenbank während des Dumps verändert wird – etwa durch einen gerade aktiven Nutzer, der eine Datei verschiebt. Um das zu umschiffen, muss man die Datenbank in einen konsistenten Zustand versetzen, etwa durch FLUSH TABLES WITH READ LOCK und den anschließenden Dump. Allerdings blockiert das Schreiboperationen für die Dauer des Vorgangs. In einer produktiven Umgebung mit vielen Nutzern kann das zu spürbaren Ausfällen führen.
Eine Alternative ist der Einsatz von Dateisystem-Snapshots, etwa mit LVM (Logical Volume Manager) oder Btrfs. Dabei wird ein schreibgeschützter Schnappschuss des gesamten Dateisystems erstellt, der in Sekundenschnelle konsistent ist. Anschließend kann man in aller Ruhe ein Backup des Snapshots anfertigen, ohne dass der laufende Betrieb gestört wird. Voraussetzung ist, dass sowohl die Datenbank als auch die Dateien auf einem Dateisystem liegen, das Snapshots unterstützt. Viele moderne Linux-Distributionen bieten das standardmäßig an. Der Haken: Die Einrichtung erfordert etwas Planung, und die Snapshots verbrauchen temporär zusätzlichen Speicherplatz. Bei großen Datenmengen kann das den verfügbaren Plattenplatz schnell aufbrauchen. Zudem ist ein Snapshot kein Ersatz für ein Backup – er schützt nicht vor einem physischen Plattenfehler oder einem Brand im Rechenzentrum. Er dient eher als erste Stufe, um schnelle Wiederherstellungspunkte zu schaffen, die dann auf ein externes Medium übertragen werden müssen.
Die Datenbank: Der Dreh- und Angelpunkt
Ein Großteil der Schwierigkeiten bei Nextcloud-Backups konzentriert sich auf die Datenbank. Ohne eine saubere Datenbanksicherung ist alles andere Makulatur. Das Standardwerkzeug mysqldump (für MariaDB/MySQL) oder pg_dump (für PostgreSQL) erzeugt eine Textdatei mit SQL-Befehlen, die die Datenbank komplett wiederherstellt. Das Verfahren ist bewährt, hat aber zwei Nachteile: Es dauert bei großen Datenbanken (mehrere Gigabyte) recht lange, und es belastet die Datenbank während des Dumps. Besser geeignet sind für große Installationen die binären Backup-Methoden, etwa xtrabackup (Percona) oder pg_basebackup. Diese Werkzeuge erstellen einen physikalischen Kopie der Datenbankdateien, ohne die Datenbank zu blockieren, und das oft deutlich schneller. Allerdings sind diese Dateien nicht ohne Weiteres portierbar – die Wiederherstellung muss auf dem gleichen Datenbanksystem und versional erfolgen. Zudem benötigt man spezielle Werkzeuge, um die konsistente Wiederherstellung zu gewährleisten.
Ein oft übersehener Punkt ist die Verschlüsselung der Nextcloud-Daten. Wenn die serverseitige Verschlüsselung aktiviert ist, befinden sich die Verschlüsselungsschlüssel in der Datenbank. Ein Backup dieser Schlüssel ist existentiell, denn ohne sie sind die hochgeladenen Dateien nicht lesbar. Viele Admins konfigurieren die Verschlüsselung, um sich vor unbefugtem Zugriff auf den Server zu schützen, vergessen aber, dass die Schlüssel regelmäßig gesichert werden müssen. Einmal verloren, sind auch die Backup-Dateien nutzlos. Die offizielle Dokumentation empfiehlt, die encryption.key sowie den Inhalt der Tabelle oc_encrypted_keys zu sichern. In der Praxis wird das gerne vernachlässigt, denn die Datei liegt meist im Nextcloud-Verzeichnis und wird bei einem einfachen Datei-Backup mit erfasst – aber nur, wenn das Backup vollständig ist und die Datenbank konsistent dazu. Genau das ist der Knackpunkt: Ein Datei-Backup ohne zugehörigen Datenbankstand führt zu inkonsistenten Verschlüsselungszuständen.
Datei-Backup: rsync, Borg und restic
Für die Sicherung der Dateien bieten sich mehrere Werkzeuge an. Der Klassiker rsync ist schnell, zuverlässig und überall verfügbar. Er kopiert nur geänderte Teile einer Datei und kann sogar über SSH in ein entferntes Netzwerk übertragen werden. Ein typischer Einzeiler: rsync -avz --delete /var/www/nextcloud/data/ backup@remote:/backup/nextcloud/data/. Das funktioniert, so lange die Datenbank in einem konsistenten Zustand ist. Allerdings speichert rsync keine Historie: Jedes Backup überschreibt das vorherige. Das ist gut für den Speicherplatz, schlecht für die Möglichkeit, auf ältere Versionen von Dateien zugreifen zu können. Für eine reine Disaster Recovery kann das ausreichen, aber wer versehentliche Löschungen oder Datenveränderungen rückgängig machen will, benötigt eine Versionierung.
Hier kommen deduplizierende Backup-Tools wie BorgBackup oder restic ins Spiel. Borg zerlegt die Daten in kleine Blöcke, erkennt Duplikate und speichert nur neue Blöcke. Das reduziert den Speicherbedarf enorm – gerade bei Nextcloud, wo viele Nutzer dieselbe Datei oder ähnliche Versionen haben. Borg erlaubt zudem die Verschlüsselung der Backups direkt auf der Quelle, sodass die Daten auch auf einem fremden Server sicher sind. Restic funktioniert ähnlich, unterstützt aber mehr Backends (S3, Swift, SFTP, etc.) und ist oft einfacher in der Handhabung. Beide Werkzeuge sind ideal für regelmäßige, platzsparende Backups. Der Nachteil: Die Ersteinrichtung erfordert etwas Fummelei, und bei sehr großen Datenmengen kann die Deduplizierung langsamer sein als ein einfaches rsync. Zudem muss man sich um die Aufbewahrungsrichtlinien kümmern – wie viele Snapshots will man behalten? Borg und restic lassen sich per Skript anpassen, aber ohne klare Strategie wächst das Backup-Volumen unkontrolliert.
Ein kleiner, aber feiner Tipp: Verwenden Sie für die Nextcloud-Daten grundsätzlich die Option --one-file-system bei rsync, um nicht versehentlich eingehängte Partitionen oder temporäre Verzeichnisse mitzusichern. Oder nutzen Sie Borg mit dem Filter --exclude für Caches und temporäre Dateien. Nextcloud legt unter data auch Thumbnails, Previews und temporäre Upload-Fragmente ab. Das sind Daten, die sich im Notfall leicht neu generieren lassen. Sie müssen nicht unbedingt im Backup landen. Eine kluge Exclusion kann das Backup-Volumen um 20 bis 30 Prozent reduzieren – und das merkt man bei täglichen Sicherungen.
Konfiguration und Apps – die oft vergessene Zone
Neben den Nutzerdaten und der Datenbank gibt es weitere kritische Elemente. Die config.php enthält die komplette Konfiguration der Instanz: Datenbank-User und -Passwort, Redis-Server, Mail-Server, Verschlüsselungseinstellungen, Treuhand-Domains, App-Liste und vieles mehr. Ein Backup dieses einen Files ist trivial, wird aber gern vergessen, weil es tief im Verzeichnisbaum steckt. Die Wiederherstellung einer Nextcloud-Instanz ohne die config.php ist ein Albtraum – man müsste alle Einstellungen manuell aus dem Gedächtnis rekonstruieren. Also: config.php immer mit sichern, am besten in einem separaten, verschlüsselten Archiv.
Die installierten Apps liegen meist unter apps oder custom_apps. Einige Apps speichern ihre eigenen Daten in der Datenbank, andere in eigenen Verzeichnissen. Wenn Sie eine Drittanbieter-App verwenden, die nicht im offiziellen App-Store ist, sollten Sie deren Daten unbedingt in das Backup einbeziehen. Ein Beispiel: Die App „Deck“ für Kanban-Boards speichert Board-Informationen in der Datenbank, aber angehängte Dateien können im Dateisystem landen. Ohne eine vollständige Sicherung sind die Deck-Daten nach einem Totalausfall verloren. Die offizielle Nextcloud-Installationsanleitung empfiehlt, die Apps aus dem Store neu zu installieren – das ist bei vielen Standard-Apps auch in Ordnung, aber nicht alle Einstellungen und Daten werden dabei wiederhergestellt. Sicherer ist es, die App-Verzeichnisse komplett zu sichern und später wieder einzuspielen. Achten Sie darauf, dass die Versionen der Apps mit denen des Backups übereinstimmen. Ein Upgrade der App zwischen Backup und Restore kann zu Kompatibilitätsproblemen führen.
Automation und Skripting – den Zufall ausschalten
Kein Backup ist besser als seine regelmäßige Durchführung. Manuelle Sicherungen sind keine Sicherheit, sondern Zeitbomben. Fast jeder Admin kennt das Gefühl: „Ach, das mache ich nächste Woche“ – und dann ist der Server weg. Ein zuverlässiges Backup-Konzept lebt von der Automatisierung. Ein einfaches Shell-Skript, das per Cron täglich ausgeführt wird, kann Wunder wirken. Dabei sollte man unbedingt eine Protokollierung einbauen, um fehlgeschlagene Backups zu erkennen. Ein Skript, das still versagt, ist nutzlos. Ideal ist eine Kombination aus lokalem Snapshot, Übertragung auf einen anderen Host und einer regelmäßigen Überprüfung der Integrität. Die Überprüfung kann etwa durch ein mysqlcheck oder durch das Testen der Datenbankwiederherstellung auf einem zweiten System erfolgen.
Beliebt ist auch der Einsatz von Konfigurationsmanagement wie Ansible oder Puppet, um die Backup-Prozedur standardisiert auf vielen Servern auszurollen. Das ist vor allem in größeren Umgebungen sinnvoll, wo mehrere Nextcloud-Instanzen betreut werden. Mit Ansible kann man ein Playbook schreiben, das auf allen Servern die gleiche Backup-Logik einrichtet – inklusive Benachrichtigungen per E-Mail oder Slack bei Fehlern. Der Initialaufwand ist höher, aber die Wartung wird zum Kinderspiel. Ein interessanter Aspekt ist die Verwendung von Healthchecks.io oder ähnlichen Diensten, um zu überwachen, ob der Cron-Job tatsächlich läuft. Ein Server, der seit drei Tagen keine Backups mehr erstellt hat, sollte sofort Alarm schlagen – nicht erst im Schadensfall.
Restore – die wahre Nagelprobe
Das beste Backup nützt nichts, wenn die Wiederherstellung nicht funktioniert. Das klingt banal, ist aber der häufigste Fehler: Backups werden erstellt, aber nie getestet. Eine Wiederherstellungsübung sollte regelmäßig auf einem separaten System durchgeführt werden – idealerweise einmal pro Quartal. Dabei stellt man nicht nur die Datenbank und die Dateien wieder her, sondern auch die Konfiguration und die Apps. Und dann startet man die Nextcloud-Instanz und prüft, ob alle Benutzer sich anmelden können, Dateien vorhanden sind und die Freigaben funktionieren. Das klingt aufwändig, und das ist es auch. Aber man glaubt gar nicht, wie viele Unternehmen nach einem Ausfall feststellen, dass die Backup-Datenbank ein paar Tage alt ist oder die config.php fehlt. Der Test deckt solche Lücken auf, bevor es weh tut.
Ein spezifisches Problem bei Nextcloud ist der Umgang mit der Datei- und Ordnerstruktur nach einem Restore. Die Datenbank enthält Pfade zu den Dateien, die auf das Dateisystem verweisen. Wenn sich die Pfade nach der Wiederherstellung ändern (etwa weil das Backup auf einem anderen Server eingespielt wird), müssen die Pfade in der Datenbank angepasst werden. Das ist eine Fummelei, die man nur einmal machen möchte, aber darauf vorbereitet sein sollte. Auch die Cache- und Thumbnail-Verzeichnisse können nach einem Restore Probleme bereiten – Nextcloud regeneriert sie zwar automatisch, das kann aber Stunden dauern und die Performance beeinträchtigen. Ein geplanter Wartungsmodus während der Wiederherstellung ist daher unerlässlich.
Besonderheiten bei externen Speichern und Verschlüsselung
Nextcloud erlaubt das Einbinden externer Speicher, etwa Amazon S3, FTP-Server, WebDAV oder andere Nextcloud-Instanzen. Diese externen Speicher werden vom System als eine Art zweite Festplatte behandelt, jedoch liegen die Metadaten weiterhin in der lokalen Datenbank. Ein Backup, das nur die lokalen Dateien sichert, erfasst die externen Daten nicht. Das ist eine der größten Fallstricke. Viele Admins glauben, ein Backup der Nextcloud-Instanz sichere alle Daten – dabei sind externe S3-Buckets nicht eingeschlossen. Für diese externen Speicher muss man separate Backup-Strategien entwickeln, etwa die S3-Bucket-Versionierung oder die Replikation auf einen anderen Bucket. Die lokale Nextcloud-Datenbank enthält nur die Referenzen, nicht die Daten. Wenn der externe Speicher ausfällt oder gelöscht wird, sind die Daten trotz Nextcloud-Backup verloren.
Die End-to-End-Verschlüsselung (E2EE) ist ein weiteres Spezialgebiet. Wenn E2EE aktiviert ist, werden die Dateien auf dem Client verschlüsselt, bevor sie auf den Server gelangen. Der Server sieht nur verschlüsselte Blöcke, aber die Entschlüsselungsschlüssel liegen beim Client. Ein Backup der Serverdaten allein reicht nicht, um die Dateien zu lesen – der Benutzer muss seine Schlüssel haben. Das ist eigentlich gewünscht, aber für den Admin bedeutet es, dass er keine Garantie für die Wiederherstellbarkeit der Inhalte übernehmen kann. Bei einem Disaster muss jeder Benutzer seine Daten erneut hochladen oder seine lokalen Schlüssel verwenden. Für Unternehmen kann das problematisch sein. Ein pragmatischer Ansatz ist, die E2EE nur für bestimmte freigegebene Ordner zu aktivieren und die Standard-Ordner unverschlüsselt zu lassen, damit das Backup auf dem Server die Daten im Klartext sichern kann.
Rechtliche Aspekte und Compliance
Nextcloud-Backups unterliegen in Deutschland und der EU der Datenschutz-Grundverordnung (DSGVO). Das bedeutet: Personenbezogene Daten, die in Nextcloud gespeichert sind, müssen auch in Backups geschützt werden. Das fängt an bei der Verschlüsselung der Backup-Medien und hört auf bei der Aufbewahrungsdauer. Ein Backup, das fünf Jahre lang ohne Zugriffskontrolle auf einem USB-Stick im Schreibtisch liegt, ist nicht datenschutzkonform. Viele Unternehmen sichern ihre Nextcloud-Instanz auf einen zentralen Backup-Server, der wiederum in das allgemeine Backup-Management eingebunden ist. Hier muss sichergestellt sein, dass die Zugriffsrechte auf die Backup-Daten strenger geregelt sind als auf die Live-Daten. Außerdem muss das Backup im Falle einer Datenlöschung (etwa bei Kündigung eines Mitarbeiters) ebenfalls gelöscht werden können. Das ist technisch oft aufwändig, weil Backups meist als Archiv vorliegen.
Die Aufbewahrungsfristen sind ein weiteres Thema. Viele Unternehmen haben gesetzliche Vorgaben, wie lange Daten aufbewahrt werden müssen (z. B. steuerlich relevante Dokumente sieben Jahre). In einer Nextcloud-Instanz liegen solche Dokumente oft zusammen mit privaten Fotos. Ein Backup, das alles speichert, hält die Fotos unnötig lange vor. Eine granulare Aufbewahrung ist mit Nextcloud-Backups nur schwer zu realisieren. Hier kann man überlegen, die Nextcloud-Instanz selbst um eine Löschrichtlinie zu ergänzen (etwa per App oder Skript) und die Backups entsprechend kurz zu halten. Ein verbreiteter Ansatz: Tägliche Backups für die letzten sieben Tage, wöchentliche Backups für einen Monat, monatliche Backups für ein Jahr. Das reduziert das Speichervolumen und hält die Compliance ein.
Praktische Empfehlungen und ein Blick in die Glaskugel
Was rät ein erfahrener Technikjournalist nun dem IT-Entscheider, der eine Nextcloud-Instanz betreibt? Erstens: Nicht auf Nebelkerzen hereinfallen. Es gibt keine Wonder-App, die alle Backup-Probleme löst. Die offizielle Nextcloud-Dokumentation ist an dieser Stelle gut, aber nicht erschöpfend. Sie beschreibt die Grundlagen, geht aber selten auf spezielle Szenarien wie Docker-Installationen, große Instanzen oder E2EE ein. Zweitens: Man sollte bereit sein, in die Automatisierung zu investieren. Ein Skript, das täglich läuft und Protokolle schreibt, ist besser als jede manuelle Sicherung. Drittens: Testen, testen, testen. Ein nicht getestetes Backup ist keins. Das mag wie eine Floskel klingen, aber ich habe selbst erlebt, wie ganze Abteilungen nach einem Crash auf ein Backup angewiesen waren, das sich als unbrauchbar erwies – weil die Datenbank inkonsistent war oder das Backup-Medium defekt.
Ein interessanter Trend ist die zunehmende Integration von Nextcloud in Container-Umgebungen wie Docker oder Kubernetes. Docker-Container sind flüchtig, Daten werden in Volumes oder Bind Mounts gespeichert. Hier ist das Backup-Konzept komplexer, weil man nicht einfach einen Snapshot des gesamten Containers nehmen kann – die Zustandsdaten müssen separat gesichert werden. Viele Docker-Images für Nextcloud liefern eigene Backup-Skripte mit, die oft auf mysqldump und rsync basieren. Die Qualität dieser Skripte schwankt, und ich empfehle, sie vor dem ersten Einsatz zu überprüfen. In Kubernetes-Umgebungen bieten sich Tools wie Velero oder Stash an, die Pod-Volumes sichern und die Wiederherstellung automatisieren. Das ist ein weites Feld, das hier nur angerissen werden kann – Fakt ist, dass Containerisierung die Backup-Planung nicht vereinfacht, sondern eher zusätzliche Ebenen der Abstraktion einzieht.
Nicht zuletzt sollte man die Kosten im Auge behalten. Backups verbrauchen Speicherplatz, Bandbreite und Rechenzeit. Ein kompromissloses Backup aller Versionen aller Dateien kann schnell teuer werden – vor allem, wenn man Cloud-Speicher (S3, Wasabi, etc.) als Ziel nutzt. Eine clevere Strategie ist, die wichtigsten Daten (Ordner mit geschäftskritischen Dokumenten) häufiger zu sichern als temporäre oder private Ordner. Nextcloud erlaubt es, pro Benutzer oder pro Ordner unterschiedliche Versionsrichtlinien zu definieren – das kann man für die Backup-Planung nutzen. Wer seine Benutzer in Gruppen einteilt, kann dann das Backup auf die kritischen Gruppen fokussieren. Das erfordert etwas Vorarbeit, aber es lohnt sich.
Fazit: Backup ist kein Projekt, sondern ein Prozess
Zusammenfassend lässt sich sagen: Nextcloud-Backup ist kein einmaliges Setup, das man nach der Installation abhakt. Es ist ein fortlaufender Prozess, der regelmäßig überprüft und angepasst werden muss. Die Komplexität wächst mit der Größe der Instanz und der Anzahl der integrierten Dienste. Aber die Grundlagen sind einfach: Datenbank, Dateien, Konfiguration – alles drei muss konsistent gesichert werden. Wer die Werkzeuge rsync, mysqldump und Borg oder restic beherrscht, kann mit wenig Aufwand einen soliden Schutz aufbauen. Wer die Automatisierung beherrscht, schaltet die größte Fehlerquelle aus: den Menschen. Und wer testet, schafft Vertrauen in die eigene Infrastruktur.
Am Ende bleibt eine Einsicht, die vielleicht unbequem ist: Ein perfektes Backup gibt es nicht. Es wird immer ein Restrisiko geben – ein fehlerhafter Speicher, ein nicht erkanntes Logikproblem, eine Sicherheitslücke im Backup-Tool. Aber die Alternative, nämlich gar kein Backup oder ein unzureichendes, ist keine Alternative. Nextcloud hat sich in der Unternehmens- und Privatwelt als verlässliche Plattform etabliert. Sorgen Sie dafür, dass diese Verlässlichkeit nicht durch eine nachlässige Backup-Strategie untergraben wird. Denn wenn der Ernstfall eintritt, zählen nicht die tollen Features oder das schöne Interface – sondern einzig und allein die Frage: Kann ich meine Daten morgen noch lesen? Und wenn die Antwort „ja“ lautet, haben Sie alles richtig gemacht. Wenn nicht, dann liegt es nicht an Nextcloud.