Wenn die Wolke stillsteht Nextcloud Disaster Recovery

Wenn die Wolke stillsteht: Disaster Recovery für Nextcloud-Umgebungen

Es ist eine dieser Nächte, die man als Administrator nicht vergisst. Der Anruf kommt kurz nach drei Uhr morgens: Die Nextcloud-Instanz reagiert nicht mehr. Monitoring zeigt rote Lichter, der Storage-Node hat einen Massendefekt, die Datenbank hängt in einer Endlosschleife. Was jetzt zählt ist nicht mehr die Ausfallsicherheit der Lösung, sondern das, was man vorher an Vorsorge betrieben hat – oder eben nicht. Disaster Recovery (DR) ist kein Feature, das man nachrüstet, wenn der Schaden bereits eingetreten ist. Es ist eine Haltung, die jede Entscheidung von der Partitionierung der Festplatten bis zur Wahl des Backup-Ziels durchzieht.

Nextcloud hat sich in den letzten Jahren von einer netten Open-Source-Alternative zu einer ernstzunehmenden Plattform für Unternehmensdaten entwickelt. Millionen von Nutzern vertrauen auf die Synchronisation, die Kollaboration und die Dateifreigabe. Doch mit wachsender Verbreitung steigen auch die Anforderungen an die Betriebssicherheit. Ein Ausfall ist nicht mehr nur ein Ärgernis für ein paar Enthusiasten – er kann ganze Abteilungen lahmlegen, Compliance-Vorgaben verletzen und im schlimmsten Fall unwiderbringliche Daten kosten. Genau hier setzt ein durchdachtes Disaster Recovery-Konzept an. Es geht nicht nur darum, dass man ein Backup hat. Sondern darum, dass man im Ernstfall innerhalb definierter Zeiträume und mit minimalen Datenverlust wieder hochfahren kann.

Die Anatomie einer Nextcloud-Instanz: Was muss geschützt werden?

Bevor man über Wiederherstellung spricht, muss man verstehen, aus welchen Komponenten eine Nextcloud-Umgebung besteht. Denn nicht alle Teile sind gleich kritisch – und nicht alle lassen sich mit denselben Methoden sichern. Im Kern setzt sich die Plattform aus vier Schichten zusammen:

• Die Datenbank (meist MariaDB oder PostgreSQL) enthält alle Metadaten: Benutzerkonten, Dateilisten, Freigaben, Einstellungen, Aktivitätsprotokolle. Ohne die Datenbank ist die Instanz ein leeres Gehäuse.
• Das Dateisystem (häufig auf NFS, S3 oder lokalen Platten) speichert die eigentlichen Nutzerdateien. In modernen Installationen sind das oft mehrere Terabyte, bei großen Umgebungen auch Petabyte, verteilt auf Objektspeicher.
• Die Anwendungsschicht mit PHP-Code, Konfigurationsdateien (config.php), Apps und dem Webserver (Apache oder Nginx). Diese Komponente ist relativ stabil und ändert sich selten radikal – es sei denn, man aktualisiert oder installiert neue Module.
• Caches und temporäre Daten wie Redis, APCu oder Memcached, die für Performance sorgen, aber nicht persistiert werden müssen. Im Disaster-Fall können sie neu aufgebaut werden.

Die Herausforderung liegt in der Interaktion dieser Komponenten. Ein konsistenter Wiederherstellungspunkt erfordert, dass Datenbank und Dateisystem zum selben Zeitpunkt gesichert werden. Ansonsten drohen Inkonsistenzen: Eine Datei ist in der Datenbank als vorhanden markiert, aber auf dem Storage fehlt sie – oder umgekehrt. Das Resultat sind Fehlermeldungen beim Synchronisieren, fehlgeschlagene Freigaben und im schlimmsten Fall Datenverlust, der sich nur schwer lokalisieren lässt.

Backup-Strategien: Mehr als nur ein Cronjob

Viele Administratoren beginnen mit einem simplen rsync der Dateien und einem mysqldump der Datenbank. Das funktioniert für einen ersten Schutz, aber es ist nicht skalierbar und schon gar nicht disaster-resistent. Denn rsync benötigt ein laufendes Dateisystem, und ein mysqldump unter Last kann inkonsistente Datenbank-Snapshots liefern – etwa wenn Schreiboperationen während des Dumps stattfinden. Für eine Produktionsumgebung mit mehr als ein paar Dutzend Nutzern braucht es durchdachtere Verfahren.

Die klassische Methode: occ maintenance:mode und Snapshots

Die Nextcloud-Kommandozeile bietet eine robuste Option: occ maintenance:mode --on versetzt die Instanz in einen Wartungsmodus, der Schreibzugriffe blockiert. Während dieser Phase können Datenbank-Dumps und Dateisystem-Backups ohne Inkonsistenzen erstellt werden. Der Nachteil: Die Ausfallzeit beträgt je nach Datenvolumen Minuten bis Stunden. Für viele Unternehmen ist das nur in einem festgelegten Wartungsfenster akzeptabel – und genau das ist der Knackpunkt: Ein Disaster kann jederzeit passieren, nicht nur nachts um drei.

Moderne Dateisysteme und Storage-Systeme bieten Snapshots auf Blockebene an. Ob LVM, ZFS, Btrfs oder ein Storage-Array eines Herstellers: Ein Snapshot friert den Zustand des Dateisystems in Sekundenbruchteilen ein. In Kombination mit einer Datenbank, die mit LVM-Snapshots oder einem ähnlichen Mechanismus abgeglichen wird, lässt sich ein konsistenter Zustand ohne längere Ausfallzeit erzeugen. Die Herausforderung ist die Koordination: Der Snapshot muss exakt den Zeitpunkt abbilden, zu dem auch die Datenbank in einem konsistenten Zustand war – was bei hoher Schreiblast schwierig werden kann.

Inkrementelle vs. vollständige Backups: Ein Kompromiss

Vollständige Backups sind die sicherste, aber auch teuerste und zeitaufwendigste Methode. Bei Nextcloud-Instanzen mit mehreren Terabyte Nutzdaten sind tägliche Vollbackups oft nicht realistisch. Hier kommen inkrementelle oder differentielle Strategien ins Spiel. Tools wie BorgBackup, restic oder duplicity nutzen deduplizierende, inkrementelle Verfahren, die nur die geänderten Blöcke sichern. Das reduziert das Storage-Volumen erheblich und verkürzt die Backup-Fenster. Allerdings verlängert sich die Wiederherstellungszeit, weil mehrere Generationen zusammenspielen müssen.

Ein interessanter Aspekt ist die Wahl zwischen Datei- und Blockebene. Borg und restic arbeiten auf Dateiebene und erkennen Änderungen anhand von Metadaten und Prüfsummen. Blockverfahren (wie LVM-Snapshots) hingegen sichern ganze Blöcke – unabhängig davon, ob sie zu einer Datei gehören oder nicht. Für große Nextcloud-Installationen mit tausenden kleinen Dateien (etwa bei vielen Freigaben und Vorschaubildern) haben blockbasierte Verfahren oft die Nase vorn, da sie die Metadaten-Last des Dateisystems umgehen. Bei reinen Objektspeicher-Backends wie S3 oder Swift müssen die Sicherungsstrategien noch einmal anders gedacht werden: Snapshots gibt es dort nicht, stattdessen kommen Versionierung oder spezielle Backup-Tools des Providers zum Einsatz.

Nextcloud-spezifische Fallstricke: Dateilocking, Versionsverwaltung und App-Daten

In der Praxis tauchen immer wieder Probleme auf, die nur Nextcloud betreffen. Drei Beispiele: Dateilocking, die eingebaute Versionierung und die App-konfiguration.

Nextcloud unterstützt Locking auf Dateiebene, um zu verhindern, dass zwei Benutzer gleichzeitig dasselbe Dokument überschreiben. Im Backup-Kontext bedeutet das, dass ein Lock zum Zeitpunkt der Sicherung bestehen kann. Beim Wiederherstellen wird dieser Lock nicht automatisch aufgelöst – die Datei ist dann für andere Nutzer gesperrt, bis manuell eingegriffen wird. Ein guter DR-Plan muss daher einen Schritt vorsehen, der alle Locks entweder mit einem Befehl (occ files:scan --repair oder direktes Löschen der Lock-Datenbank) entfernt.

Die eingebaute Versionierung ist ein Segen für den Nutzer, aber ein Fluch für die Backup-Strategie. Jede Änderung einer Datei erzeugt eine neue Version. Wer also eine 10-MB-Datei zehnmal ändert, hat möglicherweise 100 MB Speicherplatz belegt. Bei einem Backup, das alle Versionen sichert, kann das Volumen explodieren. Eine sinnvolle Strategie ist, die Versionierung entweder auf ein Maximum zu begrenzen (z. B. auf 5 Versionen) oder die Versionen gar nicht zu sichern, sondern sie als „Risiko“ zu akzeptieren. Im Ernstfall verlieren die Nutzer dann ihre Versionshistorie, aber die aktuellen Dateien sind sicher.

App-Daten sind ein weiteres Minenfeld. Viele Nextcloud-Apps speichern eigene Daten in der Datenbank oder im Dateisystem. Dazu gehören Kalender, Kontakte, die Deck-App oder die Talk-Daten. Ein extremes Beispiel: Nextcloud Talk erzeugt Audio- und Videodateien, die im Dateisystem unter einem eigenen Pfad abgelegt werden. Wenn die Sicherung dieses Pfads vergessen wird, sind alle aufgezeichneten Gespräche futsch. Ein guter DR-Plan muss daher eine Liste aller relevanten Dateipfade und Datenbanktabellen enthalten – und die regelmäßig auf Aktualität prüfen.

Wiederherstellung: Nicht nur ein Replay des Backups

Ein Backup ist nur die halbe Miete – die Wiederherstellung ist der eigentliche Test. Die häufigste Fehlannahme: Man kann einfach die gesicherten Dateien zurückkopieren und den Datenbank-Dump einspielen. Das funktioniert vielleicht auf einem identischen System, aber schon minimale Abweichungen – etwa eine andere PHP-Version, ein anderer Datenbank-Character-Set oder eine andere Pfadstruktur – können die Instanz unbrauchbar machen.

Deshalb gehört zu einem Disaster Recovery-Konzept immer auch eine dokumentierte Prozedur, die Schritt für Schritt beschreibt, was zu tun ist. Angefangen bei der Bereitstellung einer neuen Infrastruktur (oder der Wiederherstellung der alten), über die Installation der exakt gleichen Nextcloud-Version (inklusive des gleichen PHP-Modulsatzes) bis hin zum Auftragen der gesicherten Konfiguration und Daten.

Ein kritischer Punkt ist die Reihenfolge: Zuerst muss die leere Datenbank eingerichtet werden, dann der Datenbank-Dump eingespielt. Parallel dazu wird das Dateisystem in den entsprechenden Pfad kopiert. Danach erfolgt die Überprüfung der Konsistenz mit occ files:scan --all. Dieser Befehl durchsucht das Dateisystem und trägt fehlende Einträge in die Datenbank ein – und umgekehrt. Nicht selten treten hier Inkonsistenzen auf, die manuell bereinigt werden müssen.

Das Einspielen der App-Daten ist ebenfalls heikel. Apps werden in der Datenbank unter der Tabelle oc_appconfig verwaltet, einige Apps haben eigene Datenbanktabellen. Wenn man den Dump einer älteren Instanz auf eine neuere Nextcloud-Version einspielt, können Migrationskonflikte auftreten. Deshalb ist es empfehlenswert, die Versionsnummer der Nextcloud beim Backup mit zu dokumentieren – und immer zuerst auf einem Testsystem zu prüfen, ob die Wiederherstellung fehlerfrei läuft.

Geografische Verteilung: Die Wolke ist nicht überall

Ein Disaster wie ein Brand im Rechenzentrum, eine Überflutung oder ein kompletter Netzausfall trifft nicht nur einzelne Komponenten, sondern die gesamte physische Umgebung. Wer seine Nextcloud in nur einem Rechenzentrum oder noch schlimmer: auf einem einzelnen Server im Keller betreibt, hat ein akutes DR-Problem. Die Lösung heißt geografische Redundanz – das heißt, die Daten sind an mindestens zwei physisch getrennten Standorten verfügbar.

Nextcloud bietet von Haus aus keine echte Multi-Datacenter-Replikation. Man kann aber auf Storage-Ebene ansetzen: Ein S3-kompatibler Objektspeicher wie MinIO, Ceph oder die Cloud-Angebote von AWS, Azure oder Hetzner ermöglichen Cross-Region-Replikation. Die Datenbank kann mit MariaDB Galera oder PostgreSQL-Streaming-Replikation auf einen zweiten Standort gespiegelt werden. Die Anwendungsschicht selbst lässt sich parallel betreiben, wenn man einen Load-Balancer vorschaltet – allerdings müssen die Sessions und der Cache (Redis) geteilt oder ebenfalls repliziert werden.

Ein interessantes Modell ist der sogenannte „Active-Passive“-Betrieb: Ein Standort ist aktiv, der andere wartet im Standby. Im Disasterfall wird der DNS-Record umgestellt oder der Load-Balancer aktiviert. Die Herausforderung ist die Synchronisation: Während der aktive Standort läuft, müssen alle Änderungen zum passiven Standort übertragen werden. Bei hoher Schreiblast und Latenz zwischen den Standorten kann das zu Konflikten führen – und im schlimmsten Fall zu Datenverlust, wenn der aktive Standort plötzlich ausfällt. Deshalb sind asynchrone Replikationsverfahren üblich, die eine kleine Verzögerung (meist wenige Sekunden bis Minuten) in Kauf nehmen. Der RPO (Recovery Point Objective) beträgt dann eben diese Verzögerung.

Datenintegrität: Das vergessene Problem

Ein Backup nutzt nichts, wenn die Daten darin korrupt sind. Dateisystemfehler, Bitrot auf den Speichermedien oder Fehler während der Übertragung können dazu führen, dass die gesicherte Daten nicht wiederherstellbar ist. Bei großen Datenmengen wird dieses Risiko gerne unterschätzt. Nextcloud selbst hat mit der `occ integrity:check`-Funktion eine Möglichkeit, die Integrität der App-Dateien zu prüfen – das ist ein guter Anfang, deckt aber nicht die Nutzerdateien ab.

Für das Dateisystem empfiehlt sich der Einsatz von Prüfsummen. Borg und restic berechnen beim Backup Prüfsummen und prüfen sie bei der Wiederherstellung. ZFS und Btrfs können das auch auf Dateisystemebene. Für besonders kritische Umgebungen lohnt sich der Einsatz von object-storage-basierten Backups, die eine integrierte CRvC-Prüfung (Cyclic Redundancy Check) haben. Aber letztendlich gilt: Ein Backup ist nur dann ein echtes Backup, wenn es regelmäßig auch getestet wird – und zwar indem man es auf einem separaten System einspielt und die Daten stichprobenartig prüft.

Nicht zuletzt zeigt sich hier der Unterschied zwischen Backup und Disaster Recovery. Ein Backup kann noch so umfangreich sein, wenn der Wiederherstellungsprozess nicht dokumentiert, automatisiert und regelmäßig geprobt wird, ist die Wahrscheinlichkeit hoch, dass beim Ernstfall etwas schiefgeht. Ein typischer Fehler: Die Wiederherstellung wird nur auf dem ursprünglichen System getestet. Fällt aber genau dieses System aus (Hardware-Defekt, Ransomware), dann fehlt der Kontext. Ein echter DR-Test sollte immer auf einer frischen Infrastruktur stattfinden – idealerweise in einer Cloud-Umgebung, die als letzte Rettung dienen kann.

Ransomware und böswillige Insider: Wenn das Backup Teil des Angriffs wird

Disaster Recovery beschränkt sich nicht auf technische Defekte. Die größte Bedrohung für Daten ist heutzutage oft menschlicher Natur – entweder durch Kriminelle, die ein System verschlüsseln, oder durch Administratoren, die versehentlich oder absichtlich Daten löschen. Ein Backup, das auf demselben Storage-System oder im selben Netzwerksegment liegt, ist nutzlos, wenn ein Ransomware-Angriff es ebenfalls verschlüsselt. Deshalb gehört zu einem soliden DR-Konzept das Prinzip der Luftdichtigkeit: mindestens eine Kopie der Daten muss offline gehalten werden, also physikalisch getrennt und ohne dauerhafte Netzverbindung. Das kann ein externes NAS sein, das nur während des Backup-Fensters angeschlossen wird, oder ein Backup in einer separaten Cloud-Region, auf das nur über restriktive Zugriffsrechte zugegriffen werden kann.

Die Wiederherstellung nach einem Ransomware-Angriff ist zusätzlich erschwert, weil nicht nur die Daten, sondern auch die Systemkonfiguration und die Benutzerkonten möglicherweise kompromittiert wurden. Hier hilft nur eine komplette Neuinstallation der Nextcloud mit anschließendem Import der sauberen Backup-Daten. Und selbst da ist Vorsicht geboten: Wenn der Angriff bereits vor dem Backup-Zeitpunkt stattfand, können infizierte Dateien im Backup landen. Deshalb ist es sinnvoll, mehrere Generationen von Backups zu behalten – mindestens einen Zeitraum von mehreren Wochen, um einen sauberen Stand vor dem Angriff zu finden.

Tools und Workflows: Ein Überblick

Die Wahl der richtigen Werkzeuge hängt stark von der Größe der Instanz, dem verfügbaren Know-how und dem Budget ab. Für kleine bis mittlere Umgebungen (bis ca. 1 TB Daten) reichen häufig Open-Source-Lösungen wie BorgBackup oder Restic in Kombination mit einem Datenbank-Dump. Ein bewährtes Setup sieht so aus:

• Ein Skript, das zuerst einen konsistenten Datenbank-Dump erstellt (mit mysqldump --single-transaction für InnoDB oder pg_dump).
• Danach wird der Nextcloud-Wartungsmodus aktiviert, ein zweiter Datenbank-Dump (falls nötig) und dann ein Snapshot oder ein inkrementelles Backup des Dateisystems mit Borg oder Restic.
• Das Ziel-Repository kann lokal, auf einem separaten Server oder in der Cloud (z. B. Backblaze B2, Hetzner Storage Box, S3) liegen.
• Die Wiederherstellung wird in einem halbautomatischen Skript dokumentiert, das die Schritte in der richtigen Reihenfolge ausführt und am Ende einen Konsistenzcheck durchführt.

Für größere Umgebungen mit mehreren Terabyte und hunderte Benutzer bietet sich der Einsatz von Speziallösungen an. Nextcloud selbst bietet eine kostenpflichtige „Backup“-App im Enterprise-Programm, die eine integrierte Sicherung inklusive Apps, Datenbank und Dateien ermöglicht. Diese App ist allerdings nicht als reines DR-Tool konzipiert, sondern eher als einfaches Backup auf einem zweiten Volume. Wer ernsthafte Disaster Recovery benötigt, wird um ein externes Tool wie Commvault, Veeam oder Bacula nicht herumkommen. Diese Systeme können mit Nextcloud über die Dateisystemschnittstelle interagieren – ein tiefergehendes API ist nicht notwendig, solange die Konsistenz gewährleistet ist.

Ein interessanter Nebenaspekt ist der Einsatz von Git für die Konfigurationsdateien. Die config.php und wichtige App-Konfigurationen können in einem Git-Repository versioniert werden – das erleichtert nicht nur die Wiederherstellung, sondern auch das Nachvollziehen von Änderungen. Selbstverständlich sollten keine Passwörter oder Secrets direkt im Commit landen – hier kommen Umgebungsvariablen oder eine separate Secrets-Verwaltung ins Spiel.

Fragile Hochverfügbarkeit: Nextcloud im Cluster

Viele Administrator träumen von einem Nextcloud-Cluster, der Ausfälle einzelner Knoten automatisch abfängt. Nextcloud unterstützt einen mehrköpfigen Betrieb, indem man die Anwendung mehrfach hinter einem Load-Balancer startet und einen geteilten Speicher (NFS, GlusterFS, CephFS) verwendet. Die Datenbank wird ebenfalls geclustert (Galera, Patroni). Der Haken: Nextcloud selbst ist nicht state-less, vor allem der Session-Handler benötigt einen zentralen Redis-Cluster. Und das Dateisystem muss Locking unterstützen, was bei verteilten Dateisystemen wie NFSv3 nicht immer zuverlässig funktioniert. Die Nextcloud-Dokumentation empfiehlt daher explizit, einen geteilten Speicher zu verwenden, der POSIX-konformes Locking bietet – das sind vor allem verteilte Dateisysteme mit einer Metadatenschicht wie GlusterFS oder CephFS, aber die sind alles andere trivial in der Wartung.

Hochverfügbarkeit ist nicht gleich Disaster Recovery. Ein Cluster schützt vor dem Ausfall eines einzelnen Knotens, nicht aber vor einem Datenverlust durch einen Bug oder eine korrupte Transaktion. Zudem erhöht sich die Komplexität drastisch. Wer einen Cluster betreibt, muss die DR-Strategie noch sorgfältiger planen, denn die Wiederherstellung eines Clusters ist um ein Vielfaches aufwändiger als die eines Einzelservers. Manche Architekten gehen daher den pragmatischen Weg: Sie setzen auf einen einzelnen, robusten Server mit einem guten Backup und einer schnellen Wiederherstellungsmöglichkeit, statt sich in die Untiefen eines Nextcloud-Clusters zu begeben. Die Ausfallzeit wird in Kauf genommen – mit dem Argument, dass eine saubere Wiederherstellung nach zwei Stunden besser ist als ein Cluster, der nach einem Fehler tagelang repariert werden muss.

Testen, testen, testen – und das bitte regelmäßig

Der größte Feind jeder DR-Strategie ist die Vernachlässigung. Ein Backup-Skript, das jahrelang unbeobachtet läuft, kann still und leise Fehler produzieren – sei es weil die Festplatte voll ist, weil sich die Pfadstruktur geändert hat oder weil eine neue App Daten an einem unerwarteten Ort ablegt. Deshalb gehört ein automatisierter Test zum DR-Plan. Mindestens einmal im Quartal sollte eine vollständige Wiederherstellung auf einem separaten System durchgeführt werden. Dabei wird nicht nur geprüft, ob die Daten einlesbar sind, sondern auch, ob die Berechtigungen, die Freigaben und die App-Einstellungen korrekt sind. Am Ende des Tests können die Benutzer aufgefordert werden, eine bestimmte Datei zu öffnen und zu bearbeiten – das deckt oft die unerwarteten Fehler auf.

In größeren Organisationen empfiehlt sich ein Disaster-Recovery-Übungstag, bei dem das Team den Ernstfall durchspielt: Die Produktion wird bewusst heruntergefahren, und die Wiederherstellung wird ohne vorherige Planung durchgeführt. Das Ergebnis wird dokumentiert und die Schwachstellen werden behoben. Klingt aufwändig, ist aber günstiger als der tatsächliche Datenverlust – und stärkt das Vertrauen in die Systeme.

Ein Wort zur Lizenz und zu Open-Source-Besonderheiten

Nextcloud ist Open Source, das bedeutet, dass die Wiederherstellung nicht durch proprietäre Lizenzen eingeschränkt wird. Man kann die Software unbegrenzt oft installieren und auf beliebig viele Systeme kopieren. Das ist ein immenser Vorteil gegenüber kommerziellen Lösungen, bei denen die Lizenzierung für DR-Umgebungen oft zusätzliche Kosten verursacht. Allerdings gilt das nur für die Community-Edition. Wer die Enterprise-Features nutzt (etwa die Backup-App, Branding, LDAP-Integration oder Lawsuit), muss sicherstellen, dass die Lizenz für den Recovery-Knoten ebenfalls gültig ist – oder einen Lizenz-Modus vorsehen, der als „Disaster Recovery“ explizit erlaubt ist. Die Nextcloud GmbH hat hier klare Regelungen, die meist einen zusätzlichen Lizenzkauf für den Standby-Node verlangen, wenn dieser dauerhaft bereitsteht.

Ein weiterer, oft übersehener Punkt ist die Wiederherstellung des Ökosystems. Nextcloud lebt von seinen Apps, und viele Apps sind von externen Paketen abhängig (etwa PHP-Bibliotheken oder Systemtools). Ein DR-Test sollte daher immer auch die App-Funktionalität prüfen: Können Benutzer Kalendereinträge erstellen? Funktionieren die Office-Integrationen? Gehen Uploads? Und vor allem: Sind die Apps in der richtigen Version vorhanden? Ein Backup enthält den Code der Apps, aber nicht unbedingt die Abhängigkeiten auf Betriebssystemebene. Hier hilft eine vollständige Dokumentation der installierten Pakete – idealerweise in Form eines Docker-Images oder einer ansible-Rolle, die die Umgebung reproduzierbar aufbaut.

Cloud und On-Premises: Unterschiede im DR-Ansatz

Immer mehr Unternehmen entscheiden sich für eine Nextcloud-Instanz in der Cloud – sei es bei einem spezialisierten Anbieter oder als selbst betriebene Instanz auf einer VM bei einem Cloud-hoster. Die DR-Strategie unterscheidet sich grundlegend von einer On-Premises-Umgebung. In der Cloud hat man in der Regel eine bessere Infrastruktur (Redundanz, Snapshots, Templates), aber auch weniger Kontrolle. Beispiel: Ein Snapshot eines Cloud-Storage-Volumes ist schnell erstellt, aber der Wiederherstellungsprozess hängt von der API des Anbieters ab. Wenn der Anbieter ausfällt (was selten, aber nicht unmöglich ist), bleibt nur die Hoffnung auf ein Backup, das außerhalb der Cloud liegt.

Die Empfehlung lautet daher: Für die Cloud gelten die gleichen Grundsätze wie für On-Premises – mindestens ein weiteres Ziel außerhalb des primären Ökosystems. Sei es ein Backup in eine andere Cloud-Region, auf externe Festplatten oder einen anderen Provider. Wer auf Nummer sicher gehen will, betreibt eine kleine On-Premises-Instanz als letzten Ausweg, auf die im Ernstfall die Daten aus der Cloud gespielt werden. Symmetrie ist nicht notwendig – das DR-System darf gerne schwächer dimensioniert sein, solange es die kritischen Daten kurzfristig verfügbar macht.

Bei der Wahl des Cloud-Anbieters sollte man auch auf die Exportmöglichkeiten achten. Manche Provider binden einen stark an ihre proprietäre API, sodass ein Exit schwierig wird. Nextcloud selbst ist herstellerunabhängig – die Daten liegen als flache Dateien vor. Ein Anbieter, der die Daten nur in einem eigenen Container-Format herausgibt, ist für DR-Zwecke ungeeignet. Gute Kriterien sind die Unterstützung von S3-Storage, die Möglichkeit, VM-Images zu exportieren, und die Offenheit der Backup-Tools.

Rechtliche Aspekte: DSGVO und andere Vorgaben

Disaster Recovery ist nicht nur ein technisches Thema. In Europa ist die DSGVO das Maß aller Dinge. Sie verlangt unter anderem, dass personenbezogene Daten vor Verlust geschützt werden (Art. 32 DSGVO) und dass die Wiederherstellbarkeit nach einem Zwischenfall gewährleistet ist. Das bedeutet: Die DR-Strategie muss dokumentiert sein, die Wiederherstellungszeit muss in einem Verhältnis zum Risiko stehen, und die Backups müssen selbst den Datenschutzanforderungen genügen – etwa durch Verschlüsselung. Sobald personenbezogene Daten in einem Backup landen, gelten die gleichen Vorschriften wie für die Live-Daten. Also: Backup-Verschlüsselung ist Pflicht, und der Schlüssel muss getrennt aufbewahrt werden.

Ein spezieller Fall sind die kalifornischen Regelungen (CCPA) oder die Vorgaben für Gesundheitsdaten (HIPAA), die in vielen Unternehmen eine Rolle spielen. Nextcloud bietet keine explizite Zertifizierung, aber die Architektur ist offen genug, um die erforderlichen Maßnahmen zu implementieren. Ein Audit der DR-Prozesse ist daher unvermeidlich, wenn die Instanz reguliert ist.

Praktische Erfahrungen: Was wirklich schiefgeht

Nach Jahren der Beratung und Administration von Nextcloud-Instanzen habe ich einige immer wiederkehrende Fehler beobachtet. Der Klassiker: Der Administrator sichert regelmäßig die Datenbank und das Dateisystem, vergisst aber die App-Daten von Talk oder der OnlyOffice-Integration. Diese Apps speichern Binärdateien in eigenen Pfaden, die nicht zum Standard-Backup-Pfad gehören. Bei der ersten Wiederherstellung stellen die Nutzer fest, dass ihre Chat-Verläufe leer sind oder Office-Dokumente nicht mehr geöffnet werden können. Die Lösung: Eine detaillierte Inventur aller App-spezifischer Speicherorte, die in das Backup-Skript integriert wird.

Ein anderer häufiger Fehler: Der Administrator nimmt an, dass ein Snapshot auf dem Storage-System ausreicht. Aber ein Snapshot ist kein Backup im eigentlichen Sinne – er schützt vor versehentlichen Löschungen, aber nicht vor Hardware-Defekten am gesamten Storage-System. Ein Stromausfall, der den Storage-Controller brät, kann den Snapshot mitnehmen. Ein Snapshot muss immer auf ein separates System kopiert werden, um als Backup zu gelten.

Und dann die Sache mit den Scripts: Viele setzen auf selbstgestrickte Bash-Skripte, die per Cron laufen. Das funktioniert jahrelang, bis eines Tages eine neue Version von Nextcloud eine Änderung in der Datenbankstruktur vornimmt, die das vorherige Backup-Skript nicht berücksichtigt. Der Dump wird zwar erstellt, aber die Wiederherstellung schlägt fehl, weil die Tabellen anders benannt sind. Die Lehre: Auch die Backup-Skripte müssen versioniert und getestet werden – genau wie die Software selbst.

Fazit: Der Weg zur entstörten Wolke

Disaster Recovery für Nextcloud ist kein Projekt, das man im Vorbeigehen erledigt. Es erfordert eine Analyse der Komponenten, eine durchdachte Backup-Strategie, automatisierte Tests und eine dokumentierte Prozedur, die im Ernstfall auch unter Stress funktioniert. Die gute Nachricht: Nextcloud ist ein offenes System, das sich gut in bestehende DR-Infrastrukturen integrieren lässt. Die schlechte Nachricht: Viele unterschätzen den Aufwand und stehen dann im Regen – im wahrsten Sinne des Wortes, wenn das Rechenzentrum überflutet ist.

Ein solider Plan umfasst mindestens drei Backup-Kopien: eine lokale (für schnelle Wiederherstellung), eine entfernte (für regionale Disaster) und eine offline (für Ransomware-Schutz). Der RPO sollte unter einem Tag liegen, der RTO unter vier Stunden – das sind realistische Werte für die meisten Unternehmen. Und der wichtigste Rat: Testen Sie den Ernstfall, solange noch kein Ernstfall eingetreten ist. Nichts ist beruhigender als das Gefühl, genau zu wissen, was zu tun ist, wenn die Alarmmeldung eingeht.

Die Nextcloud-Community und die Dokumentation bieten viele Anleitungen, aber letztendlich muss jeder Admin seine eigene Maßarbeit leisten. Wer die Zeit investiert, wird mit einer stabilen, wiederherstellbaren Umgebung belohnt – und mit der Gewissheit, dass die Daten der Nutzer in guten Händen sind, selbst wenn die Wolke mal stillsteht.