Die trügerische Sicherheit der RAID-Festplatte

Ein häufiges Missverständnis in IT-Abteilungen ist die Gleichsetzung von Redundanz mit Backup. Ein RAID-Array schützt vor einem physischen Plattenausfall, das ist korrekt. Es schützt jedoch nicht vor logischer Zerstörung. Ein fehlerhaftes Skript, ein Ransomware-Angriff, der durch eine Schadsoftware auf Client-Seite Synchronisationszugriff erhält, oder der berüchtigte „rm -rf“ im falschen Verzeichnis – all diese Szenarien repliziert das RAID ebenso zuverlässig wie Ihre eigentlichen Daten. Das Backup ist hier die letzte Verteidigungslinie, die zeitlich zurückspringen kann. Ein interessanter Aspekt ist, dass gerade die Komplexität einer Nextcloud mit ihrem externen Speicher, ihren verschlüsselten Datenbankeinträgen und den vielfältigen Apps ein einfaches Dateisystem-Backup oft unzureichend macht.

Die drei Schichten der Nextcloud: Was wirklich gesichert werden muss

Um eine Nextcloud-Instanz vollständig wiederherstellen zu können, muss man ihre Architektur verstehen. Vereinfacht gesagt, besteht sie aus drei kritischen Schichten, die in ihrer Gesamtheit betrachtet werden müssen.

1. Die Dateien selbst

Der offensichtlichste Teil: die Nutzerdateien im `data/`-Verzeichnis. Doch Vorsicht: Bei standardmäßiger Konfiguration liegen diese in einer komplexen Verzeichnisstruktur, die mittels `occ files:scan` mit der Datenbank abgeglichen werden muss. Bei der Nutzung von External Storage wie S3, FTP oder anderen Nextcloud-Instanzen verschärft sich die Lage. Diese Dateien liegen physisch nicht im `data/`-Ordner. Ihr Backup muss separat und konsistent zum Zeitpunkt der Nextcloud-Sicherung erfolgen, sonst entstehen beim Wiederherstellen inkonsistente Referenzen.

2. Die Datenbank – das Herzstück

Hier residieren alle Metadaten: Dateiberechtigungen, Freigabe-Links, Versionsinformationen, Aktivitätsstreams, Kalender, Kontakte, Tasks. Ein Verlust der Datenbank bei erhaltenden Dateien resultiert in einer unbrauchbaren Instanz. Die Dateien wären zwar da, aber Nextcloud weiß nicht mehr, wem sie gehören, welche Version die aktuelle ist oder wer Zugriff hat. Das Backup der Datenbank (ob MySQL/MariaDB, PostgreSQL oder SQLite) erfordert einen transaktionskonsistenten Export. Ein einfacher Dateicopy der Datenbankdateien während des Betriebs führt fast garantiert zu einer beschädigten Sicherung.

3. Die Konfiguration und das Application Framework

Das `config/`-Verzeichnis mit der zentralen `config.php` ist essenziell. Hier stehen Datenbankzugangsdaten, Secret Keys für Verschlüsselung und Cookie-Sicherheit, sowie Konfigurationen für externe Dienste. Ohne sie kommt die Instanz nicht hoch. Ebenso wichtig ist der gesamte Codebaum der Nextcloud selbst inklusive aller installierten Third-Party-Apps. Eine Differenz zwischen gesichertem Code und der laufenden Datenbank kann nach einem Update zu schwerwiegenden Fehlern führen. Nicht zuletzt gehören hierzu auch Session-Daten und Caches, die jedoch meist nicht gesichert werden müssen.

Strategien: Vom simplen Snapshot zum verteilten 3-2-1-Konzept

Die einfachste Methode ist ein dateibasiertes Backup aller drei Schichten auf ein anderes Laufwerk. Tools wie `rsync` mit Hardlinks (z.B. mittels `rsnapshot`) ermöglichen hier platzsparende, versionierte Sicherungen. Das ist für kleine, private Instanzen oft ausreichend. Im professionellen Umfeld stößt dieses Vorgehen jedoch schnell an Grenzen, insbesondere bei großen Datenmengen und der Notwendigkeit kurzer Recovery Time Objectives (RTO).

Die Königsdisziplin ist das 3-2-1-Backup-Prinzip: Drei Kopien der Daten, auf zwei verschiedenen Medien, von denen eine offsite gelagert wird. Für Nextcloud könnte das so aussehen:

• Kopie 1: Die produktive Nextcloud-Instanz.
• Kopie 2: Ein lokales, versioniertes Backup auf einem dedizierten NAS oder Server.
• Kopie 3: Eine verschlüsselte Sicherung in einem anderen Rechenzentrum oder einem Cloud-Speicher wie AWS S3 Glacier, Backblaze B2 oder einem anderen Nextcloud-Server.

Dabei zeigt sich eine praktische Stärke von Nextcloud: Sie kann durch ihre External Storage-Funktionalität selbst Bestandteil einer solchen Strategie sein, indem sie als Ziel für die Offsite-Sicherung anderer Systeme dient.

Die Snapshots-Falle bei virtuellen Maschinen

Viele Administratoren verlassen sich auf VM-Snapshots ihres Hypervisors. Diese sind schnell erstellt und scheinen komfortabel. Sie ersetzen aber kein applicatonskonsistentes Backup. Ein Snapshot friert den Zustand der Festplatte ein, nicht jedoch den Zustand der Datenbank. Wird der Snapshot einer laufenden Nextcloud-VM zurückgespult, ist die Datenbank sehr wahrscheinlich beschädigt. Für eine saubere Sicherung muss die Nextcloud vor dem Snapshot in einen konsistenten Zustand versetzt werden – etwa durch einen `occ maintenance:mode –on` Befehl und einen korrekten Datenbank-Dump.

Werkzeuge und Praktische Umsetzung

Die Wahl des richtigen Werkzeugs hängt stark von der Größe und den Anforderungen ab. Die Nextcloud-Community bietet hier verschiedene Ansätze.

Der manuelle Weg mit Occ und Rsync

Für Puristen und kleine Installationen bleibt die manuelle Skriptierung eine robuste Option. Ein typisches Skript würde folgende Schritte umfassen:

1. Aktivieren des Wartungsmodus: sudo -u www-data php occ maintenance:mode --on
2. Export der Datenbank mittels `mysqldump` oder `pg_dump`.
3. Sicherung des `config/`-Verzeichnisses und des gesamten Nextcloud-Codebaums.
4. Deaktivieren des Wartungsmodus.
5. Parallele Sicherung des `data/`-Verzeichnisses mittels `rsync` (dies kann im laufenden Betrieb erfolgen, da Dateien sich nun nicht mehr ändern sollten).

Der Vorteil: volle Kontrolle. Der Nachteil: Operational Overhead und die Gefahr, dass sich Fehler im selbstgeschriebenen Skript einschleichen.

BorgBackup & Restic: Deduplizierung für Effizienz

Bei großen Instanzen mit vielen Datei-Versionen werden deduplizierende Backup-Tools unverzichtbar. BorgBackup und Restic komprimieren und deduplizieren Daten, sparen also enorm Speicherplatz. Beide können verschlüsselte Backups auf remote-Systeme übertragen und sind perfekt für die 3-2-1-Strategie. Die Herausforderung: Auch hier muss für Applikationskonsistenz gesorgt werden. Oft wird ein Skript die Nextcloud in den Wartungsmodus versetzen, einen Datenbank-Dump erstellen, und diesen Dump dann zusammen mit den Dateien in das Borg/Restic-Repository packen.

Spezialisierte Nextcloud-Backup-Apps: Bequemlichkeit vs. Kontrolle

Im Nextcloud App Store finden sich Tools wie „Backup“ oder „Snapshot“. Diese Apps erstellen oft komplette, komprimierte Archiv aus dem Nextcloud-Verzeichnis und der Datenbank. Ihre große Stärke ist die Benutzerfreundlichkeit und Integration in die Nextcloud-Oberfläche. Für mittelgroße Instanzen sind sie eine exzellente Wahl. Bei Terabyte-großen Installationen oder bei der Notwendigkeit, Backups in spezifische, bestehende Infrastrukturen zu integrieren, können sie an ihre Grenzen stoßen. Zudem bindet man sich an ein weiteres Stück Software innerhalb des Systems, das man sichern möchte – ein klassisches Henne-Ei-Problem bei der Wiederherstellung.

Der System-Container-Ansatz: Docker-Volumes und Backups

Immer mehr Nextcloud-Instanzen laufen in Docker- oder Podman-Containern. Hier vereinfacht sich das Backup theoretisch, indem man einfach die persistenten Volumes sichert. In der Praxis gilt aber auch hier: Die Datenbank benötigt einen konsistenten Dump. Ein einfaches Archivieren des MySQL-Data-Volumes während des Containerbetriebs ist riskant. Besser ist es, innerhalb des Datenbank-Containers einen `mysqldump` auszuführen und das Ergebnis in ein Volume zu schreiben, das dann vom Host-System gesichert wird. Tools wie `docker-compose` erlauben es, solche Abläufe sauber zu orchestrieren.

Die Gretchenfrage: Verschlüsselung vor oder nach dem Backup?

Nextcloud bietet eine serverseitige Verschlüsselung an. Diese schützt Daten vor dem Zugriff durch Hosting-Provider oder bei Diebstahl der Festplatten. Für Backups ergeben sich jedoch Komplikationen. Ist die Verschlüsselung aktiv, werden die Dateien im `data/`-Verzeichnis bereits verschlüsselt gespeichert. Das Backup enthält also nur Chiffrat. Das ist sicher, macht aber eine dateibasierte Deduplizierung unmöglich und verhindert das Wiederherstellen einzelner Dateien ohne die Nextcloud-Instanz und ihren Master-Key. Viele Administratoren entscheiden sich daher, auf die interne Verschlüsselung zu verzichten und stattdessen das gesamte Backup-Repository mit Tools wie Borg oder Restic zu verschlüsseln. Das bietet mehr Flexibilität und Kontrolle über den Schlüssel. Ein interessanter Aspekt ist, dass die Nextcloud-Verschlüsselung vor allem den *Storage* schützt, nicht aber den Zugriff durch Administratoren der Nextcloud selbst – eine feine, aber wichtige Unterscheidung.

Die Wiederherstellung: Der eigentliche Test

Ein Backup, das nicht getestet wurde, existiert faktisch nicht. Die DR-Übung (Disaster Recovery) ist Pflicht. Dabei sollte mindestens jährlich das komplette Wiederherstellen auf einem Testsystem geprobt werden. Interessant ist hier die Frage der Granularität: Muss die ganze Instanz zurück, oder reicht es, einen gelöschten Benutzerordner wiederherzustellen?

Für eine Full-Restore Prozedur benötigt man in der Regel: 1) Eine frische Server-Installation mit gleicher PHP-Version und Datenbank, 2) den gesicherten Nextcloud-Codebaum, 3) den gesicherten `config/`-Ordner, 4) den Datenbank-Dump und 5) das `data/`-Verzeichnis. Nach dem Kopieren der Dateien und dem Import des Datenbank-Dumps muss häufig `occ maintenance:repair` ausgeführt und ein `occ files:scan –all` initiiert werden.

Für die Wiederherstellung einzelner Dateien oder Benutzer ist ein dateibasiertes, versioniertes Backup vorteilhaft. Noch eleganter lösen das Nextclouds interne Dateiversionen in Kombination mit dem gelöscht-Ordner. Für echte Punkt-in-Zeit-Wiederherstellungen, etwa nach einer Ransomware-Infektion, die über die Synchronisierung verteilt wurde, reicht das jedoch nicht aus. Hier ist ein externes, versioniertes Backup das einzig verlässliche Mittel.

Automatisierung und Monitoring: Damit der Mensch nicht nachdenken muss

Ein Backup-Job, der fehlschlägt und es niemand merkt, ist das Schlimmste. Daher gehört zu jedem Konzept zwingend ein Monitoring. Das kann einfach ein Skript sein, das nach jedem Backup-Lauf eine E-Mail mit dem Log oder eine Erfolgsmeldung an einen Monitoring-Dienst wie Nagios/Icinga sendet. Noch besser: regelmäßige Prüfungen, ob die Backup-Dateien lesbar sind. Ein kleiner Trick ist das automatische Einspielen des Datenbank-Dumps in eine Test-Datenbank, um die Integrität zu validieren.

Die Automatisierung mittels Cronjobs oder Systemd-Timers ist Standard. Wichtig ist, die Auslastung im Auge zu behalten. Ein volles Backup während der Hauptgeschäftszeit kann die Nextcloud-Performance durch hohe I/O-Last spürbar beeinträchtigen. Intelligente Backup-Tools können hier nach einer initialen Vollsicherung mit inkrementellen Sicherungen arbeiten, die nur Änderungen übertragen.

Cloud-Backup vs. On-Premise: Eine philosophische Frage

Die Entscheidung, Backups in die Public Cloud zu verlagern, ist auch eine Kosten- und Vertrauensfrage. Dienste wie AWS S3, Wasabi oder Backblaze B2 bieten extrem günstigen, ausfallsicheren Speicher. Die Herausforderung sind die egress-Kosten bei einer notwendigen Wiederherstellung und die Latenz. Ein vollständiger Restore über eine 100 Mbit/s-Leitung kann bei Terabyte-Daten Wochen dauern. Hybrid-Modelle sind hier sinnvoll: aktuelle Backups lokal halten für schnelle RTO, ältere Versionen und eine Sicherungskopie in die Cloud für den katastrophalen Fall (Feuer, Überschwemmung).

Nextcloud selbst kann in dieser Architektur eine interessante Doppelrolle einnehmen: als produktive Plattform und als Backup-Ziel für andere Systeme, die ihre Sicherungen via WebDAV in die Nextcloud legen. So entsteht ein verteiltes, resilientes System.

Fazit: Backup als integraler Bestandteil der Nextcloud-Architektur

Ein Nextcloud-Backup ist kein nachträglicher Gedanke, den man irgendwann implementiert, wenn Zeit ist. Es ist eine Kernanforderung, die von Beginn an in die Planung einfließen muss. Die Komplexität der Plattform mit Datenbank, Dateien, Konfiguration und Apps erfordert ein durchdachtes, mehrschichtiges Vorgehen, das auf die individuellen Anforderungen an Recovery Time und Recovery Point abgestimmt ist.

Die Werkzeugwahl reicht von simplen Skripten bis zu hochkomplexen, deduplizierenden Enterprise-Backup-Systemen. Entscheidend ist nicht die Komplexität der Methode, sondern ihre Verlässlichkeit und regelmäßige Überprüfung. Letztlich schützt man mit einem soliden Backup-Konzept nicht nur Bits und Bytes, sondern die Arbeitsfähigkeit von Teams und die Kontinuität von Prozessen, die auf Nextcloud aufbauen. In einer Welt, in der Daten der zentrale Wertschöpfungsfaktor sind, ist diese Investition in die Resilienz unerlässlich. Oder, um es mit den Worten eines alten Sysadmins zu sagen: Es gibt zwei Arten von Menschen – die, die bereits ein Backup gemacht haben, und die, die es in Zukunft tun werden.