Nextcloud hat sich in den letzten Jahren als die zentrale Plattform für viele Organisationen etabliert – als selbstgehostete Alternative zu proprietären Cloud-Diensten. Doch genau diese Eigenverantwortung bringt eine Verpflichtung mit sich: die Notfallplanung. Wer Nextcloud betreibt, muss sich fragen: Was passiert, wenn der Server ausfällt, die Datenbank korrupt ist oder ein Ransomware-Angriff die Installation lahmlegt? Dieser Artikel beleuchtet alle Aspekte einer soliden Notfallstrategie – von Backup-Konzepten über Hochverfügbarkeit bis hin zur regelmäßigen Überprüfung der Wiederherstellbarkeit. Denn eines ist klar: Nextcloud ist kein Selbstläufer. Es ist ein machtvolles Werkzeug, aber es verlangt dem Administrator einiges ab, wenn es um Ausfallsicherheit und Datenrettung geht.
Dabei zeigt sich immer wieder: Viele Administratoren setzen Nextcloud auf, konfigurieren Benutzer und Apps, und vergessen dann die existenzielle Frage: Wie stelle ich das System wieder her, wenn etwas schiefgeht? Nicht zuletzt die jüngsten Sicherheitsvorfälle bei großen Cloud-Anbietern haben das Bewusstsein für die eigene Verantwortung geschärft. Aber gerade bei selbstgehosteten Umgebungen liegt die Last komplett beim Betreiber. Ein interessanter Aspekt ist, dass Nextcloud selbst einige Mechanismen mitbringt, die die Notfallplanung erleichtern – aber sie sind oft nicht ausreichend, wenn man wirklich auf Nummer sicher gehen will.
Wer eine Notfallplanung für Nextcloud aufsetzt, sollte zuerst die Architektur verstehen. Nextcloud besteht im Kern aus drei Komponenten: der Dateiablage (entweder lokal oder angebunden an Objektspeicher), der Datenbank (meist MariaDB oder PostgreSQL) und dem Web- und App-Server (Apache oder Nginx plus PHP). Hinzu kommen Konfigurationsdateien, die App-Daten, die Redis-Instanz für Caching und Sessions, und – je nach Setup – der Mailserver, Cronjobs und externe Dienste wie LDAP. Jede dieser Komponenten kann ausfallen und muss in der Notfallplanung berücksichtigt werden. Ein einfaches Backup der Dateien allein reicht nicht; die Datenbank muss konsistent gesichert sein, und die Konfigurationsparameter müssen nach einer Wiederherstellung exakt stimmen.
Ein interessanter Punkt ist die Frage der Datenkonsistenz: Wenn man während eines laufenden Betriebs ein Backup zieht, kann es passieren, dass eine Datei gerade fertiggeschrieben wird, während die Datenbank den Eintrag schon hat – oder umgekehrt. Nextcloud hat dafür eine Transaktionslogik, aber im Fall einer Wiederherstellung aus einem unsauberen Backup kann es zu Inkonsistenzen kommen, die sich kaum noch automatisch reparieren lassen. Deshalb sollte man entweder Backups während eines definierten Wartungsfensters erstellen oder auf Snapshot-basierte Verfahren setzen (etwa LVM-Snapshots oder Dateisystem-Snapshots bei Btrfs/ZFS). Das ist einer der Punkte, an dem sich zeigt, ob die Notfallplanung wirklich durchdacht ist.
Die Anatomie eines Backup-Konzepts für Nextcloud
Backups sind die Basis jeder Notfallplanung, doch sie werden oft vernachlässigt. Manche Administratoren neigen dazu, das Backup als lästige Pflicht abzutun – ein gefährlicher Irrtum. Ein gutes Backup-Konzept für Nextcloud umfasst mehrere Ebenen. Zuerst die Dateien: Das sind die User-Daten, die meist im Verzeichnis data liegen, sowie die App-Daten und der Config-Ordner config. Diese können mit rsync, Borg oder einem anderen Tool auf einen separaten Storage gesichert werden. Die Datenbank muss dagegen mit einem Dump-Tool wie mysqldump (bei MariaDB) oder pg_dump gesichert werden, und zwar in einer konsistenten Transaktion. Nextcloud bietet sogar ein integriertes Kommandozeilen-Tool: occ maintenance:backup – aber das erstellt nur ein Backup des Nextcloud-Ordners und der Datenbank, ohne die User-Dateien. Das ist ein häufiger Irrtum: Viele glauben, dieser Befehl erzeuge ein vollständiges System-Backup. Tatsächlich sichert er nur die Nextcloud-Installation, nicht die eigentlichen Daten der Benutzer.
Ein weiterer wichtiger Aspekt ist die 3-2-1-Regel: Drei Kopien der Daten auf zwei verschiedenen Medien, eine davon offsite. Für Nextcloud bedeutet das konkret: Ein lokales Backup auf einer externen Festplatte oder NAS, ein weiteres Backup auf einem anderen Server im selben Rechenzentrum, und ein drittes in einer anderen Region oder bei einem Cloud-Anbieter. Die Verschlüsselung der Backups ist dabei Pflicht, insbesondere bei Offsite-Backups. Man sollte aber darauf achten, dass der Verschlüsselungsschlüssel nicht auf dem zu sichernden System liegt – sonst nützt die ganze Verschlüsselung nichts, wenn der Server kompromittiert wird.
Interessant ist auch die Frage der inkrementellen vs. differentiellen vs. vollständigen Backups. Für Nextcloud-Dateien bieten sich inkrementelle Verfahren an, da die Datenmengen schnell wachsen können. Werkzeuge wie Borg, Restic oder Duplicati ermöglichen Deduplizierung und Versionierung. Die Datenbank dagegen sollte man in regelmäßigen Abständen vollständig dumpen – und die Dumps dann wiederum in das inkrementelle Backup einbinden. Das erlaubt eine granulare Wiederherstellung: Man kann einen bestimmten Zustand des Filesystems mit einer bestimmten Datenbankversion kombinieren. Die Wiederherstellung ist dann allerdings komplexer und sollte gut dokumentiert sein.
Praxisbeispiel: Ein Backup-Skript für Nextcloud
Viele Administratoren schreiben sich eigene Skripte. Ein typisches Vorgehen: Ein Bash-Skript, das per mysqldump die Datenbank sichert, dann mit rsync das Nextcloud-Data-Verzeichnis auf einen externen Mount kopiert, und danach die Konfiguration als tar-Archiv packt. Das Skript läuft nachts per Cronjob. Nach der Sicherung sollte eine Prüfung erfolgen: Lässt sich der Dump ohne Fehler importieren? Sind die Dateien vollständig? Das ist oft die Schwachstelle: Backups werden erstellt, aber nie getestet. Ein Backup, das nie wiederhergestellt wurde, ist wertlos – das ist eine Binsenweisheit, aber sie wird in der Praxis ständig ignoriert. Nicht zuletzt aus Zeitmangel.
Ein interessanter Aspekt ist die Verwendung von Snapshots auf Storage-Ebene. Wer Nextcloud auf einem System mit Btrfs oder ZFS betreibt, kann für das Data-Verzeichnis alle paar Stunden einen Snapshot erstellen und diesen dann per rsync auf ein anderes System übertragen. Das ist sehr effizient und vermeidet Inkonsistenzen, weil der Snapshot einen frozen State liefert. Bei der Datenbank muss man aber aufpassen: Ein LVM-Snapshot einer laufenden MariaDB-Instanz ist nicht unbedingt konsistent, wenn die Datenbank gerade schreibt. Besser ist es, vor dem Snapshot kurz die Datenbanktabellen zu sperren oder einen Dump zu machen. Es gibt aber auch Tools wie mylvmbackup oder snapper, die das automatisieren.
Hochverfügbarkeit: Wenn Nextcloud niemals ausfallen darf
Notfallplanung bedeutet nicht nur Backups, sondern auch, die Ausfallzeit zu minimieren. Hochverfügbarkeit (High Availability, HA) für Nextcloud ist ein anspruchsvolles Thema, aber für viele Unternehmen notwendig, wenn der Dienst geschäftskritisch ist. Eine typische HA-Architektur für Nextcloud besteht aus mehreren Web-Instanzen hinter einem Load Balancer, einer gemeinsamen Datenbank im Master-Slave-Verbund oder mit Galera-Cluster, und einem shared Storage, der von allen Knoten gelesen und geschrieben werden kann. Der Engpass ist meist der Storage: NFS kann hier schnell zum Flaschenhals werden, oder es treten Locking-Probleme auf. Viele setzen daher auf Objektspeicher (S3-kompatibel) wie MinIO, Ceph oder AWS S3, der von Natur aus skalierbar und ausfallsicher ist. Nextcloud unterstützt S3 als primären Speicher – das vereinfacht die HA-Architektur erheblich.
Ein interessanter Aspekt ist Redis: Nextcloud nutzt Redis für File Locking und Caching. In einer HA-Umgebung sollte Redis ebenfalls im Cluster betrieben werden, etwa mit Redis Sentinel oder Redis Cluster. Fällt Redis aus, kann Nextcloud zwar noch laufen, aber die Performance sinkt drastisch, und File Locking funktioniert nicht mehr – was zu Datenverlust führen kann, wenn zwei User gleichzeitig in die gleiche Datei schreiben. Das ist ein oft übersehenes Detail. Auch die Session-Verwaltung (über Redis) muss ausfallsicher sein, sonst werden Benutzer bei einem Ausfall einer Web-Instanz abgemeldet und verlieren ihre Arbeit.
Die Datenbank-HA ist der nächste Punkt. MariaDB Galera Cluster ermöglicht synchrone Replikation auf mehrere Knoten. Das ist robust, aber es gibt Grenzen: Bei hohem Schreibdurchsatz kann die Latenz steigen. Für Nextcloud reicht in der Regel ein Master-Slave-Setup mit automatischem Failover (z.B. mit Orchestrator oder MySQL InnoDB Cluster). Wichtig ist, dass die Anwendung die Verbindung zur Datenbank umschalten kann. Nextcloud hat dafür keine nativen Mechanismen; man muss auf Treiber-Ebene (z.B. mit ProxySQL) oder DNS-basiert umschalten. Ein interessanter Aspekt ist, dass die Nextcloud-OCC-Commands nicht für HA ausgelegt sind: Der Cronjob für Hintergrundaufgaben sollte nur auf einem Knoten laufen, sonst gibt es Konflikte. Man kann das mit einer Lock-Datei auf dem Shared Storage oder per Redis steuern.
Failover-Tests: Der ultimative Check
Nicht zuletzt muss die HA-Architektur regelmäßig getestet werden. Ein Failover-Test bedeutet: Man schaltet den primären Web-Server ab, beobachtet, ob der Load Balancer den sekundären aktiviert, und prüft, ob Nextcloud weiterhin funktioniert. Gleiches für die Datenbank und Redis. Viele Administratoren verzichten auf solche Tests, weil sie Angst haben, dass das System dabei Schaden nimmt. Aber das Gegenteil ist der Fall: Nur durch regelmäßige Übungen stellt man sicher, dass der Notfallplan im Ernstfall auch greift. Dabei zeigt sich oft, dass Konfigurationsdetails falsch sind – etwa dass die Load-Balancer-Healthchecks auf einen Pfad zeigen, der bei einem Teilausfall nicht mehr antwortet, oder dass die Timeouts zu kurz sind. Ein interessanter Aspekt ist, dass sich ein Failover auch automatisiert durchführen lässt, zum Beispiel mit Chaos-Engineering-Tools wie Chaos Monkey oder Gremlin. Das setzt aber voraus, dass die Umgebung orchestriert ist und die Auswirkungen überwacht werden können.
Ein weiterer Punkt: Der Notfallplan muss auch die menschliche Komponente abdecken. Wer ist für den Failover verantwortlich? Gibt es eine Eskalationskette? Sind die Zugänge zu den Backup-Servern, den Clouds und den Konfigurationsdateien dokumentiert? Im hektischen Fall ist das Gedächtnis oft unzuverlässig. Deshalb gehört zu einer guten Notfallplanung ein Runbook – eine detaillierte Anleitung, die Schritt für Schritt beschreibt, was im Falle eines Ausfalls zu tun ist. Das Runbook sollte regelmäßig aktualisiert und im Team verteilt werden. Ein Beispiel: “Wenn die Datenbank nicht erreichbar ist, prüfen Sie die CPU-Last auf den DB-Knoten. Führen Sie dann den Befehl `systemctl status mariadb` aus. Starten Sie den Dienst notfalls neu. Wenn das nicht hilft, schalten Sie auf den Slave um, indem Sie das DNS-Record ändern.” Solche Anleitungen klingen trivial, aber in der Aufregung übersieht man schnell entscheidende Schritte.
Updates und Migrationen – eine unterschätzte Risikoquelle
Nextcloud erscheint in regelmäßigen Abständen mit neuen Major-Versionen, die umfangreiche Änderungen mit sich bringen. Ein Update ist immer ein Risiko. Nicht zuletzt deshalb sollte die Notfallplanung auch den Update-Prozess umfassen. Viele Organisationen haben schon erlebt, dass nach einem Update plötzlich Apps nicht mehr funktionieren, die Datenbank nicht mehr kompatibel ist oder Drittanbieter-Integrationen brechen. Ein interessanter Aspekt ist, dass Nextcloud selbst eine Rollback-Funktion für Apps bietet, aber nicht für die Core-Installation. Das bedeutet: Vor jedem Update muss ein vollständiges Backup der Datenbank, der Dateien und der Konfiguration erstellt werden. Und man sollte nicht nur ein Backup haben, sondern auch die Möglichkeit, das alte System schnell wiederherzustellen – idealerweise auf einer separaten Testumgebung.
Eine bewährte Methode ist der Blue-Green-Deployment-Ansatz: Man betreibt zwei identische Umgebungen (eine aktive, eine inaktive), führt das Update auf der inaktiven durch, testet gründlich und schaltet dann den Verkehr um. Das setzt natürlich voraus, dass die Daten synchronisiert werden und die Umgebungen skalierbar sind. Für die meisten Nextcloud-Installationen dürfte das Overkill sein, aber ein Staging-System, auf dem Updates vorab getestet werden, ist ein Minimum. Man kann auch mit Snapshots arbeiten: Vor dem Update einen Snapshot des Produktivsystems ziehen, updaten, und falls etwas schiefgeht, vom Snapshot zurück. Das geht besonders gut mit virtuellen Maschinen oder mit Btrfs/ZFS-Snapshots. Wichtig ist, dass die Datenbank während des Snapshots konsistent ist.
Ein typischer Fehler: Administratoren führen Updates im laufenden Betrieb durch, ohne die Wartungsmodi zu aktivieren. Nextcloud hat einen Maintenance-Modus, der die Benutzeroberfläche deaktiviert und Wartungsarbeiten ermöglicht. Dieser sollte vor jedem Update aktiviert werden. Andernfalls kann es vorkommen, dass Benutzer während des Updates Dateien hochladen, die dann in einer inkonsistenten Version gespeichert werden. Der Maintenance-Modus schaltet sich nach dem Update normalerweise automatisch aus, aber in seltenen Fällen bleibt er aktiv – dann müssen Administratoren manuell eingreifen. Auch das sollte im Runbook dokumentiert sein.
Sicherheit der Backups: Der Schutz vor Ransomware und Datenverlust
Ein Backup nützt wenig, wenn es selbst von einem Ransomware-Angriff betroffen ist. Deshalb gehört die Sicherung der Backups zur Notfallplanung dazu. Konkret bedeutet das: Die Backup-Server sollten nicht im selben Netzwerksegment wie die Produktiv-Nextcloud-Instanz liegen. Ideal ist ein komplett getrenntes Backup-Netz, das nur über eine eigene Firewall und mit restriktiven Regeln erreichbar ist. Die Backup-Ziele sollten nicht als Netzlaufwerk auf dem Produktivserver gemountet sein – denn dann kann sich Malware einfach durch das gesamte Netzwerk fressen. Besser ist ein Pull-Prinzip: Der Backup-Server holt sich die Daten vom Produktiv-Server, nicht umgekehrt. Das ist etwas aufwändiger zu konfigurieren, aber erhöht die Sicherheit massiv.
Ein interessanter Aspekt ist die Versionierung: Ältere Backup-Versionen sollten nicht sofort gelöscht werden, sondern für einen bestimmten Zeitraum aufbewahrt werden. Das erlaubt, auch auf einen Ransomware-Befall zu reagieren, der vielleicht erst Tage später bemerkt wird. Die Aufbewahrungsfrist muss im Notfallplan festgelegt sein. Wer nur eine Woche Backups vorhält, steht am Ende ohne Daten da, wenn der Angriff vor zwei Wochen stattfand. Die 3-2-1-Regel gilt auch hier: Zwei lokale Kopien, eine davon offline (etwa auf einer externen Festplatte, die nur während des Backup-Fensters angeschlossen wird) und eine Kopie in einer geografisch getrennten Region.
Dazu kommt die Verschlüsselung der Backups – sowohl während der Übertragung als auch im Ruhezustand. Tools wie Borg bieten integrierte Verschlüsselung mit einem Passwort oder Schlüssel. Der Schlüssel darf nicht auf dem gleichen System liegen wie die verschlüsselten Backups. Bewährt hat sich, den Schlüssel auf einem separaten, stark gesicherten System zu hinterlegen, das nur im Notfall zugänglich ist. Ohne diesen Schlüssel sind die Backup-Daten nutzlos – das ist gleichzeitig eine Stärke (Schutz vor unbefugtem Zugriff) und eine Schwäche (Risk of Verlust des Schlüssels). Deshalb sollte der Schlüssel an mehreren Orten sicher aufbewahrt werden, etwa in einem Tresor oder bei einem Notar. Das klingt übertrieben, aber in der Praxis kommt es immer wieder vor, dass der einzige Administrator, der den Schlüssel kennt, das Unternehmen verlässt oder verunglückt. Der Notfallplan muss auch solche Szenarien abdecken.
Testen der Wiederherstellung: Der ultimative Härtetest
Ein interessanter Aspekt der Notfallplanung ist die regelmäßige Wiederherstellungsübung. Viele Organisationen testen ihre Backups nur, indem sie einen Dump in eine Testdatenbank importieren oder eine Datei zurückspielen. Das ist ein Anfang, aber es reicht nicht. Der gesamte Prozess einer vollständigen Wiederherstellung muss durchgespielt werden: Man nimmt einen leeren Server, installiert das Betriebssystem, die benötigten Pakete (PHP, Datenbank, Webserver), spielt die Nextcloud-Installation aus dem Backup zurück, stellt die Datenbank wieder her, konfiguriert alle Parameter und startet den Dienst. Dabei treten fast immer Hindernisse auf: fehlende PHP-Module, unterschiedliche Versionen von Dependencies, vergessene Cronjobs oder falsche Dateirechte. Diese Probleme im Ernstfall zu beheben, kostet wertvolle Zeit, die man nicht hat.
Dabei zeigt sich, dass die Dokumentation oft Lücken aufweist. Wer nach einem Jahr noch weiß, wie genau die Nextcloud-Umgebung aufgesetzt wurde? Ein gutes Runbook enthält alle Schritte von der Installation bis zur Konfiguration, inklusive der spezifischen Parameter, die für diese Umgebung gelten. Es ist sinnvoll, die Wiederherstellung jährlich oder nach größeren Änderungen (wie einem Update oder einer Migration) zu üben. Die beste Vorgehensweise ist, die Übung als Teil des Notfallplans zu formalisieren: Ein Verantwortlicher erhält den Auftrag, innerhalb von 24 Stunden eine funktionierende Nextcloud-Instanz aus den Backups auf einem frischen System aufzusetzen. Die Erfahrungen werden dokumentiert, und der Plan wird entsprechend angepasst. Das ist aufwändig, aber es gibt kein besseres Mittel, um die Qualität der Notfallplanung zu überprüfen.
Praxisbeispiel: Ein Unternehmen erlebt einen Totalausfall
Betrachten wir ein fiktives, aber durchaus realistisches Szenario: Ein mittelständisches Unternehmen setzt Nextcloud als zentrale Dateiablage ein. Rund 500 Mitarbeiter nutzen die Plattform täglich. Der Administrator hat zwar Backups eingerichtet, aber noch nie getestet. Eines Tages führt ein Hardwarefehler am Server zu einer korrupten Datenbank. Der Server bootet nicht mehr. Der Administrator versucht, die Datenbank zu reparieren – ohne Erfolg. Er greift auf das Backup zurück. Doch das Backup-Skript hatte seit Monaten nicht funktioniert, weil der Speicherplatz auf dem Ziel-Volume voll war. Die letzten konsistenten Backups sind drei Monate alt. Die Firma verliert wertvolle Daten. Ein Albtraum – und leider keine Seltenheit.
Hätte der Administrator regelmäßig die Wiederherstellung getestet, wäre ihm der Fehler aufgefallen. Besser wäre gewesen, ein Monitoring für die Backup-Größe und den Speicherplatz einzurichten, das bei Problemen Alarm schlägt. Auch die Dokumentation der Wiederherstellung hätte geholfen: Ein frischer Server hätte in wenigen Stunden aufgesetzt werden können, wenn alle Schritte klar beschrieben gewesen wären. Stattdessen herrschte Chaos, und die Geschäftsleitung musste eine teure Datenrettungsfirma beauftragen – die am Ende auch nur einen Teil der Daten retten konnte.
Ein interessanter Aspekt ist, dass solche Vorfälle oft gar nicht durch böswillige Angriffe verursacht werden, sondern durch einfache menschliche Fehler oder Planungsmängel. Die beste Notfallplanung ist die, die auch gegen die eigenen Unzulänglichkeiten gewappnet ist. Das bedeutet: Automatisierung, wo möglich, aber auch redundante manuelle Prüfschritte. Und vor allem: eine Kultur, die Ausfälle nicht tabuisiert, sondern als Lernchance begreift. Chaos Engineering, also das absichtliche Herbeiführen von Fehlern in einer kontrollierten Umgebung, kann helfen, die Widerstandsfähigkeit des Systems zu steigern. Für Nextcloud gibt es mittlerweile erste Ansätze, solche Tests in die CI/CD-Pipeline einzubinden, aber das ist noch Neuland.
Fazit: Notfallplanung ist kein einmaliges Projekt
Wer Nextcloud betreibt, trägt die Verantwortung für die Verfügbarkeit und Integrität der Daten. Eine solide Notfallplanung umfasst mehr als nur ein Backup-Skript. Sie muss die gesamte Architektur berücksichtigen, von der Datenbank über den Storage bis hin zur Netzwerkinfrastruktur. Hochverfügbarkeit kann helfen, Ausfallzeiten zu minimieren, aber sie ist kein Ersatz für eine ordentliche Backup- und Recovery-Strategie. Denn auch ein Cluster kann durch einen logischen Fehler oder eine korrupte Datenbank in Mitleidenschaft gezogen werden. Nicht zuletzt ist die regelmäßige Überprüfung der Wiederherstellbarkeit der entscheidende Faktor: Ein ungetestetes Backup ist ein schlechtes Backup.
Ein interessanter Aspekt ist die psychologische Komponente: Administratoren neigen dazu, die Notfallplanung auf die lange Bank zu schieben, weil sie im Alltagsgeschäft andere Prioritäten setzen. Dabei ist ein guter Notfallplan wie eine Versicherung: Man hofft, sie nie zu brauchen, aber wenn der Ernstfall eintritt, ist sie unbezahlbar. Die Investition in Zeit und Ressourcen lohnt sich – sowohl in technischer Hinsicht als auch für das Vertrauen der Nutzer, die darauf angewiesen sind, dass ihre Daten sicher und verfügbar sind.
Aktuelle Entwicklungen wie die Integration von Nextcloud in Kubernetes-Umgebungen und die zunehmende Nutzung von Objektspeichern eröffnen neue Möglichkeiten für die Notfallplanung. Beispielsweise lassen sich mit Helm-Charts Nextcloud-Instanzen schnell deployen und per PersistentVolumeClaims mit dynamischen Snapshots sichern. Auch die Kombination mit Tools wie Velero oder Kasten K10 für Kubernetes-basierte Backup- und Disaster-Recovery-Lösungen verspricht mehr Automatisierung. Doch diese Technologien sind noch nicht ausgereift und erfordern spezifisches Know-how. Für viele Organisationen bleibt die bewährte Methode aus Dump, rsync und Offsite-Backup der Goldstandard – ergänzt um regelmäßige Tests und ein detailliertes Runbook.
Nicht zuletzt sollte man auch an die rechtlichen Aspekte denken: Datenschutzverordnung, Compliance-Anforderungen, Aufbewahrungspflichten. Die Notfallplanung muss diese Rahmenbedingungen abbilden. Wer etwa Patientendaten oder personenbezogene Daten in Nextcloud speichert, muss sicherstellen, dass die Backups den gleichen Sicherheitsanforderungen genügen wie die produktive Umgebung. Das bedeutet unter anderem, dass die Verschlüsselung der Backups dokumentiert sein muss und dass die Wiederherstellung im Ernstfall nicht gegen geltendes Recht verstößt. Das sind Themen, die über die reine Technik hinausgehen, aber zur ganzheitlichen Notfallplanung dazugehören.
Insgesamt gilt: Nextcloud ist eine mächtige Plattform, aber ihr Betrieb erfordert Disziplin und Weitsicht. Wer die Notfallplanung ernst nimmt, kann mit ruhigem Gewissen schlafen – und seine Benutzer auch. Denn am Ende zählt die Gewissheit, dass die Daten nicht verloren sind, selbst wenn der Server morgen in Flammen aufgeht. Oder – wie es ein altes Admin-Sprichwort sagt: “Never trust a backup you haven’t restored.”