Nextcloud Datenexport der Schlüssel zur Datenhoheit

Die Datenhoheit liegt bei Ihnen: Ein pragmatischer Blick auf den Nextcloud-Datenexport

Es gibt eine Frage, die sich jeder Betreiber einer Nextcloud-Instanz irgendwann stellt – meist dann, wenn es darauf ankommt: Wie komme ich eigentlich an meine Daten heran, wenn ich die Umgebung wechseln, ein Backup einspielen oder einfach nur die Souveränität über meine Dateien behalten will? Die Antwort scheint trivial zu sein. Schließlich handelt es sich bei Nextcloud um eine Open-Source-Plattform, die auf Standards setzt. Dateien liegen im Dateisystem, die Datenbank speichert Metadaten, und mit ein paar Handgriffen sollte sich alles exportieren lassen. Die Praxis ist, wie so oft, etwas nuancierter.

Reden wir nicht um den heißen Brei herum: Der Datenexport ist das Rückgrat jeder ernsthaften Digitalisierungsstrategie – ob im Unternehmen, in der öffentlichen Verwaltung oder im eigenen Lab. Wer seine Infrastruktur auf eine Cloud-Lösung aufsetzt, muss jederzeit in der Lage sein, die Kontrolle über die eigenen Informationen zu behalten. Nextcloud hat diesen Anspruch von Beginn an in seiner DNA verankert. Der Datenexport ist nicht nur ein Feature, er ist ein Versprechen. Und wie bei jedem Versprechen kommt es auf die Details an.

Warum der Export so schnell zur Geduldsprobe werden kann

Nextcloud ist weit mehr als eine Dateiablage. In den vergangenen Jahren hat sich die Plattform zu einer föderierten Produktivitätssuite entwickelt. Kalender, Kontakte, E-Mails, Chat, Kollaboration an Dokumenten – das alles wird über Apps angebunden, die ihrerseits Daten in der Datenbank oder in eigenen Verzeichnissen ablegen. Ein simpler rsync auf das data-Verzeichnis greift zu kurz. Tatsächlich ist es genau diese App-Ökonomie, die den Export komplex macht. Ein Screenshot der Dateien wäre kein vollständiges Backup, weil die Verknüpfungen fehlen.

Ein Beispiel aus der Praxis: Ein mittelständisches Unternehmen betrieb eine Nextcloud-Instanz mit rund 500.000 Dateien, integrierter Kalendersynchronisation und einer benutzerdefinierten App für die Zeiterfassung. Als man auf eine neue Hardware umziehen wollte, stellte sich heraus, dass die Zeiterfassungsdaten nicht in den üblichen Tabellen lagen, sondern in einem eigenen Schema, das nur in der App-Dokumentation beschrieben war. Der Export scheiterte zunächst an einer fehlenden Datenbanktabelle, weil das Skript für den Backup-Prozess nicht alle App-Datenbanken berücksichtigt hatte. Ein Ärger, der sich hätte vermeiden lassen – mit einem systematischen Blick auf den Datenexport.

Die Architektur hinter den Kulissen

Um den Export wirklich zu verstehen, hilft ein Blick auf die drei Säulen, auf denen Nextcloud ruht: das Dateisystem, die relationale Datenbank und der Konfigurationsbaum. Im Normalfall liegen die Dateien der Benutzer im sogenannten data-Verzeichnis, das wiederum in Unterordner pro Benutzer unterteilt ist. Jede Datei ist dort physisch vorhanden, allerdings mit einem Hash-basierten Pfad, der eine direkte Zuordnung ohne die Datenbank erschwert. Die Metadaten – Ordnerstruktur, Freigaben, Versionsverlauf, Kommentare – stecken in der Datenbank, meist MariaDB oder PostgreSQL. Dazu kommen die Konfigurationsdateien in config/config.php, die App-Einstellungen und die Zertifikate.

Wer also einen Export durchführen möchte, muss alle drei Komponenten erfassen. Das ist der Grund, warum das manuelle Kopieren der Dateien allein nicht funktioniert. Es entstehen Inkonsistenzen, weil die Datenbank noch auf Dateien verweist, die längst woanders liegen, oder umgekehrt. Ein sauberer Export setzt voraus, dass entweder alle Komponenten im selben Zustand eingefroren werden – etwa durch einen temporären Wartungsmodus – oder dass ein Werkzeug eingesetzt wird, das die Konsistenz automatisch sicherstellt.

Manuelle Exportmethoden: rsync, SCP und der gute alte Download

Der natürlichste Reflex: Einfach per SCP auf den Server und das data-Verzeichnis herunterladen. Das funktioniert prinzipiell, aber nur mit Einschränkungen. Ohne die Datenbank bleibt der Datenexport eine Ansammlung von lose verbundenen Dateien, die keinen Kontext mehr haben. Die Ordnerstruktur, die der Benutzer in der Weboberfläche sieht, existiert im Dateisystem nicht als solche. Stattdessen findet man eine flache Liste von Dateien mit kryptischen Namen. Die Ordnernamen sind in der Datenbank gespeichert. Wer also nur die Dateien herunterlädt, bekommt Datenmüll, wenn er den Export später in eine andere Instanz importieren will.

Eine Alternative ist der Export über die Nextcloud-Weboberfläche selbst. Jeder Benutzer kann einen Ordner oder eine Datei herunterladen – bequem, aber bei vielen Daten zeitraubend. Ein Administrator kann über die Kommandozeile mit dem occ-Befehl arbeiten. Der Befehl occ files:export exportiert die Dateien eines Benutzers in einem strukturierten Format. Das ist ein erster Schritt in die richtige Richtung, aber auch hier gilt: Der Export umfasst nur die Dateien, nicht die Metadaten der Apps. Kalenderdaten etwa bleiben außen vor.

Automatisiert und robust: Der offizielle Backup- und Restore-Prozess

Nextcloud selbst empfiehlt einen mehrstufigen Prozess, den man im Administrationshandbuch findet, der aber oft übersehen wird. Das offizielle Backup besteht aus drei Teilen: der Datenbank, dem data-Verzeichnis und den Konfigurationsdateien. Dafür wird die Instanz in den Wartungsmodus versetzt, um Schreibzugriffe zu verhindern. Dann folgt ein mysqldump oder pg_dump der Datenbank, ein rsync des data-Verzeichnisses und ein separates Kopieren von config/. Dieser Prozess ist robust, aber nicht trivial. Vor allem der Restore will geübt sein. Es ist nicht ungewöhnlich, dass Admins nach einem Einspielen feststellen, dass die Datenbankversion nicht mehr zur Codebasis passt, weil sie versehentlich die Reihenfolge vertauscht haben.

In der Praxis hat sich bewährt, den Exportprozess in einem Skript zu kapseln und regelmäßig zu testen. Einmal im Vierteljahr einen Restore auf einem Testsystem durchführen – das klingt nach Aufwand, aber es ist der einzige Weg, um sicherzustellen, dass der Export tatsächlich funktioniert. Ich habe schon zu viele Fälle erlebt, in denen das Backup zwar regelmäßig lief, die Wiederherstellung aber scheiterte, weil irgendeine App ihre Datenbanktabellen nicht exportierte oder weil der Pfad im config-Array falsch war.

Die Rolle der Apps beim Datenexport

Ein Aspekt, der in vielen Artikeln untergeht, ist die Heterogenität der Apps. Nextcloud lebt von seinem Ökosystem. Die einen nutzen die Kalender-App, andere die Tabellen-App, und wieder andere haben eigene App-Entwicklungen im Haus. Jede App entscheidet selbst, wo sie ihre Daten ablegt: in der Datenbank, im Dateisystem oder in externen Speichern wie S3. Der offizielle Backup-Prozess erfasst nur das data-Verzeichnis der Nextcloud. Wenn eine App aber ihre Daten in einem Unterverzeichnis außerhalb des normalen Benutzerordners ablegt – was vorkommt –, dann gehen diese Daten im Export verloren.

Ein interessanter Fall ist die Nextcloud Files-App selbst. Sie speichert die Dateien im Benutzerordner, das ist klar. Aber was ist mit den Versionen und den gelöschten Dateien? Die liegen ebenfalls im data-Verzeichnis, aber in einem versteckten Ordner namens files_versions und files_trashbin. Ein rsync, der nicht diese versteckten Ordner mitnimmt, hinterlässt Lücken. Es ist also nicht nur eine Frage des „Was“, sondern auch des „Wie“. Ein Export bedeutet immer, Entscheidungen über Vollständigkeit zu treffen.

Datenbankexport: das Herz der Metadaten

Die relationale Datenbank ist das Gedächtnis der Nextcloud. Hier stehen die Verknüpfungen zwischen Dateien und Benutzern, die Freigaben, die Kommentare, die Aktivitäten und die App-Daten. Ein Datenexport ohne die Datenbank ist wie ein Buch ohne Inhaltsverzeichnis: Die Seiten sind da, aber man findet nichts wieder. Der mysqldump ist der Klassiker. Er erzeugt eine SQL-Datei, die alle Tabellen enthält. Aber Vorsicht: Die Tabellen sind nicht alle gleich. Die oc\_filecache-Tabelle ist groß, bei vielen Instanzen mehrere Gigabyte. Ein Dump kann lange dauern und den Server belasten. Besser ist es, den Dump mit Optionen wie --single-transaction zu versehen, um Inkonsistenzen während des Exports zu vermeiden.

Noch ein Detail: Die Datenbanktabellen enthalten auch den Inhalt von Apps, die keine eigenen Dateien anlegen, sondern alles in der Datenbank speichern – etwa die Notes-App oder die Passwords-App. Wer diese Daten exportiert, muss entweder die entsprechenden Tabellen separat sichern oder darauf vertrauen, dass sie im vollständigen Dump enthalten sind. Ein vollständiger Dump ist daher in der Regel die sichere Variante – vorausgesetzt, die Größe der Datenbank ist beherrschbar.

Wenn der Export zum Umzug wird: Migration auf eine neue Instanz

Der häufigste Grund für einen Datenexport ist der Wechsel auf eine neue Hardware oder eine andere Cloud-Umgebung. Oder der Umzug von einer gehosteten Nextcloud auf den eigenen Server. In solchen Fällen geht es nicht nur um den Export, sondern um die Migration der gesamten Instanz. Das bedeutet, die exportierten Daten müssen auf dem neuen System an der richtigen Stelle landen, und die Konfiguration muss angepasst werden – neue Domain, neuer Datenbankname, neuer Pfad. Ein typisches Problem: Die Datenbank enthält absolute Pfade (etwa zu externen Storage-Ordnern), die auf dem neuen System nicht vorhanden sind. Dann erscheinen Fehlermeldungen, und der Import scheitert.

Eine pragmatische Lösung: Vor dem Export alle externen Storage-Einträge temporär entfernen oder durch Platzhalter ersetzen. Nach dem Import müssen diese dann neu verknüpft werden. Das klingt aufwändig, ist aber in der Dokumentation beschrieben. Leider wird dieser Schritt oft übersehen. Ich habe selbst einen Umzug begleitet, bei dem der Admin eine Woche an der Nachjustierung gesessen hat, weil die Music-App ständig auf einen nicht vorhandenen Pfad verwies. Der Export war korrekt, der Import auch – aber die Konfiguration war nicht vollständig migriert.

Tools und Skripte aus der Community

Die Nextcloud-Community hat den Bedarf an einem sauberen Datenexport früh erkannt. Es gibt diverse Skripte auf GitHub, die den Prozess automatisieren. Manche setzen auf Borg oder Restic für das Backup, andere nutzen die Nextcloud API, um über das WebDAV-Interface einen vollständigen Dateiexport durchzuführen. Das hat den Vorteil, dass die Metaphorik stimmt: Die API liefert die Dateien genau so, wie sie der Benutzer sieht – mit Ordnern, Freigaben und allem. Allerdings skaliert die API nicht immer gut bei großen Datenmengen. Bei einer Instanz mit mehreren Terabyte kann der API-basierte Export mehrere Tage dauern und den Server parallel belasten.

Ein interessantes Werkzeug ist das „Nextcloud Backup Tool“ (ncp-backup), das auf der NextcloudPi Distribution basiert. Es kombiniert rsync mit Datenbank-Dumps und bietet eine Weboberfläche für den Restore. Für Homelabs und kleine Unternehmen ist das eine runde Sache, weil es den Export in ein portables Zip-Archiv verpackt. Aber Vorsicht: Auch dieses Tool ist nicht unfehlbar. Bei manchen App-Updates hat es mitunter Tabellen übersehen. Ein regelmäßiger Test-Restore ist auch hier die einzige Absicherung.

Export für den einzelnen Benutzer: Die unterschätzte Selbstbedienung

In Unternehmen wird der Datenexport oft aus der Perspektive des Administrators betrachtet. Dabei ist die Perspektive des Benutzers ebenso wichtig. Nextcloud bietet seit einigen Versionen einen persönlichen Datenexport in der Benutzeroberfläche an. Unter „Einstellungen“ kann der Benutzer einen Export anstoßen, der seine Dateien, Kalender, Kontakte und Einstellungen in eine herunterladbare Datei packt. Das ist ein wichtiges Feature für die Datenhoheit – und ein Hebel für die DSGVO-Compliance. Der Benutzer hat damit jederzeit die Möglichkeit, eine Kopie seiner Daten zu erhalten, ohne den Administrator belästigen zu müssen.

Allerdings hat auch dieser Export seine Tücken. Standardmäßig sind nur die Daten enthalten, die über die Nextcloud-Oberfläche zugänglich sind. Wenn die Firma zusätzlich eine App für Zeiterfassung oder Personalverwaltung betreibt, deren Daten nicht über die Standard-Personendaten im Dashboard liegen, dann bleiben diese außen vor. Aus Compliance-Sicht kann das ein Problem sein. Wer den persönlichen Datenexport als alleiniges Mittel zur Erfüllung von Auskunftspflichten einsetzt, sollte vorher prüfen, ob wirklich alle relevanten Daten integriert sind.

Die offene Flanke: Verschlüsselte Dateien

Nextcloud bietet eine server- und eine clientseitige Verschlüsselung an. Die serverseitige Verschlüsselung ist bequem zu verwalten, aber sie stellt den Export vor eine Herausforderung. Verschlüsselte Dateien liegen im Dateisystem als verschlüsselte Blöcke vor. Die Schlüssel befinden sich in der Datenbank. Beim Export werden beide benötigt – die verschlüsselten Blöcke und die Schlüssel. Ein reiner rsync der Dateien liefert unlesbare Daten. Wer die Dateien exportiert, ohne die Schlüssel zu sichern, macht den Export praktisch wertlos. Der offizielle Backup-Prozess ist darauf ausgelegt, die Schlüssel mitzusichern, aber es gibt Berichte über Konfigurationsfehler, bei denen die Schlüssel im Export fehlen und die Wiederherstellung scheitert.

Ein Tipp aus der Praxis: Vor dem Export die Verschlüsselung temporär deaktivieren, wenn das aus Sicherheitsgründen vertretbar ist. Oder noch besser: Die Verschlüsselung nur auf dem Client durchführen, dann liegt der Schlüssel lokal und der Server hat nur verschlüsselte Daten – der Export betrifft dann zwar die verschlüsselten Blöcke, aber der Benutzer kann die Daten auf dem Client entschlüsseln. Das verschiebt die Komplexität lediglich, aber es vermeidet das Problem der Schlüsselsynchronisation beim Export.

Große Datenmengen und der Faktor Zeit

Wenn die Nextcloud-Instanz mehrere Terabyte umfasst, wird der Datenexport zum logistischen Projekt. Ein rsync über das Netzwerk kann Tage dauern. Schon der mysqldump frisst bei großen Datenbanken Speicher und CPU. Und dann muss der Import auf der Zielinstanz ebenfalls durchgeführt werden. Viele Admins unterschätzen den Zeitaufwand und setzen den Export als Batch-Job an, der dann die Produktivität beeinträchtigt. Ein pragmatischer Ansatz ist der Einsatz von inkrementellen Exports, bei denen nur die Änderungen seit dem letzten Vollbackup übertragen werden. Das setzt voraus, dass man eine Backup-Strategie hat, die mehrstufig ist.

Ehrlich gesagt: In großen Umgebungen ist der Datenexport oft nicht das Problem, sondern der Import. Die Nextcloud-Instanz muss den Datenstrom verarbeiten, Indizes aufbauen, App-Daten einlesen – das kann je nach Hardware Stunden oder gar Tage dauern. Ein Import auf einer Produktivinstanz während des laufenden Betriebs ist fast nie ratsam. Wer einen Export zu Testzwecken durchführt, sollte die Zielinstanz ausreichend dimensionieren. Sonst endet der Datenexport in einer Sackgasse.

Externe Datenquellen und die Grenzen des Exports

Nextcloud kann externe Speicher einbinden – etwa ein NAS, S3-Buckets oder WebDAV. Diese externen Speicher sind beim Datenexport ein Sonderfall. Ein Backup des data-Verzeichnisses enthält nur die Metadaten der externen Dateien, nicht die Dateien selbst. Der Export muss entweder den externen Speicher separat sichern oder die Metadaten so behandeln, dass nach dem Import die Verbindung wiederhergestellt wird. Das ist nicht trivial, denn die Zugriffsdaten auf den externen Speicher sind in der Datenbank gespeichert. Ein Export, der die Datenbank sichert, hat sie dabei – aber die physikalischen Dateien liegen auf dem externen System, das nicht automatisch im Backup enthalten ist.

Eine interessante Lösung: Die externen Speicher über die Nextcloud-API exportieren. Dazu gibt es Skripte, die über das WebDAV-Interface auf die Dateien zugreifen und sie lokal speichern. Aber das ist nur bei kleineren Mengen praktikabel. Ein externer S3-Bucket mit mehreren hundert Gigabyte ließe sich besser über ein natives Tool wie s3cmd sichern. Die Herausforderung ist dann, die Verbindung zwischen den Metadaten und den physischen Dateien nach dem Import wiederherzustellen. Das ist kein Bug, sondern eine inhärente Eigenschaft verteilter Systeme.

Journalistische Einordnung: Warum der Export so selten wirklich getestet wird

Es mag überraschen, aber in vielen Unternehmen wird der Datenexport nicht regelmäßig getestet. Die Backup-Quote stimmt, das Backup läuft, aber der Restore wird nur im Notfall geprüft – und dann ist es zu spät. Nextcloud selbst bietet zwar ein Admin-Interface für die Überprüfung der Dateiintegrität, aber einen vollständigen Restore-Test muss man selbst organisieren. Die Gründe sind nachvollziehbar: Zeitmangel, fehlende Testumgebung, die Annahme, dass das Backup schon funktioniert. Aber das ist eine Illusion.

Ein Beispiel aus der eigenen Erfahrung: Ein Kunde betrieb eine Nextcloud mit 30 Benutzern und integrierter CRM-App. Das Backup lief mit einem Standard-Skript, das data, config und Datenbank dumpete. Als der Server nach einem Stromausfall defekt war, stellte sich beim Restore heraus, dass die CRM-App ihre Daten in einer eigenen SQLite-Datenbank innerhalb des appdata-Ordners ablegte, der nicht im data-rsync enthalten war. Der Export war in dem Sinne korrekt, als dass alle Nextcloud-Kernkomponenten vorhanden waren – aber die CRM-Daten waren verloren. Ein Test-Restore hätte das aufgedeckt.

Das ist kein Versagen von Nextcloud. Es ist ein strukturelles Problem: Die App-Entwickler sind nicht verpflichtet, ihre Daten an einem standardisierten Ort abzulegen. Und die Administratoren müssen wissen, wo die Daten der von ihnen eingesetzten Apps liegen. Ein Blick in die Dokumentation der Apps ist vor jedem Export Pflicht. Wer das nicht tut, spielt russisches Roulette mit den Unternehmensdaten.

Der Datenexport als Teil der Incident-Response

Ein Thema, das in der Diskussion um den Datenexport meist zu kurz kommt, ist der Sicherheitsaspekt. Mal angenommen, eine Nextcloud-Instanz wurde kompromittiert – ein Admin-Account übernommen, ungewöhnliche Logins, vielleicht sogar ein Ransomware-Angriff. In so einer Situation braucht man einen sauberen Datenexport, um die Daten zu retten und auf eine saubere Instanz zu migrieren. Aber der Export selbst kann die Bedrohung vergrößern, wenn er die Malware mit transportiert. Deshalb ist es wichtig, den Export auf einem System durchzuführen, das als vertrauenswürdig gilt – etwa mit einer Live-CD, die von außen auf die Daten zugreift.

Eine andere Situation: Der Export soll für ein Audit aufbereitet werden. Dann müssen die Daten in einem maschinenlesbaren Format vorliegen, das die Prüfer verarbeiten können. Nextcloud bietet zwar die Standardformate wie CSV für Benutzerdaten, aber für komplexe App-Daten ist das oft nicht ausreichend. Hier sind individuelle Skripte gefragt, die die Datenbankinhalte in lesbare Formate transformieren. Das ist aufwändig, aber für Compliance-Prüfungen unvermeidbar.

Ein Blick in die Zukunft: Was bringt die nächste Nextcloud-Generation?

Nextcloud entwickelt sich rasant weiter. Mit den Nextcloud Hubs kommen neue Funktionen wie Talk-Brücken, Data Rooms und Echtzeit-Kollaboration. Die Frage des Datenexports wird dadurch nicht einfacher. Im Gegenteil: Je mehr Daten an verschiedenen Orten fließen – in Chats, in gemeinsam bearbeiteten Dokumenten, in Videokonferenzaufzeichnungen – desto komplexer wird der Export. Nextcloud hat das erkannt und arbeitet an einem einheitlichen Export-Framework, das alle Datenquellen berücksichtigt. In der Community gibt es Vorschläge für ein standardisiertes Daten-Bundle, ähnlich wie das „Takeout“ von Google. Aber ob das kommt und wann, steht noch in den Sternen.

Bis dahin bleibt der Administrator in der Verantwortung. Der Datenexport ist eine Sorgfaltspflicht, die nicht delegiert werden kann. Ein Skript, das regelmäßig läuft, ist gut. Ein Skript, das regelmäßig getestet wird, ist besser. Und die Dokumentation aller Apps und ihrer Datenquellen ist das A und O. Klingt nach viel Arbeit? Ist es auch. Aber die Alternative – ein Datenverlust im Ernstfall – wiegt schwerer.

Am Ende des Tages geht es beim Datenexport nicht um Technik. Es geht um Vertrauen. Die Nutzer vertrauen darauf, dass ihre Daten sicher sind und dass sie sie jederzeit mitnehmen können. Der Administrator vertraut darauf, dass der Export funktioniert. Dieses Vertrauen ist nur durch Transparenz und Tests zu rechtfertigen. Nextcloud bietet die Grundlage – den Rest muss man selbst machen. Das ist lästig, aber es ist ein Preis, den man für die digitale Souveränität gern zahlt.