File-Verwalter

von Heike Jurzik

Eine private Cloud als Speicherumgebung bringt diverse Herausforderungen mit sich. Viele davon liegen in der getrennten Lagerung von Daten und Metadaten oder in der Stabilität der Datenbank. OpenCloud will dafür sorgen, dass Backups auf Dateiebene einfach und zügig klappen und verbundene Netzlaufwerke ihre Daten sofort für alle User zur Verfügung stellen. Dazu liegen alle Daten direkt im Dateisystem – ohne Datenbank. Wie das Speichermanagement mit OpenCloud robuster und stressfreier wird, zeigt dieser Artikel. Er erklärt außerdem, wie Admins konsistente Backups erstellen und Fehler bei der Migration vermeiden.

Cloudspeicher stoßen mitunter an ihre Grenzen: Datenbankausfälle, inkonsistente Metadaten oder manuelle Scans sind nur eine Auswahl von Problemen, die in vielen Umgebungen Alltag sind. OpenCloud [1] will das besser machen, indem es auf Go-Microservices setzt und alle Daten direkt im POSIX-Dateisystem speichert – inklusive Metadaten. Änderungen erkennt das System in Echtzeit – ganz gleich, ob sie über die Weboberfläche, per Client oder direkt im Dateisystem erfolgen.

Was OpenCloud anders macht

Bei selbst betriebenen Cloudspeichern haben IT-Verantwortliche die Wahl zwischen mehreren bekannten Anwendungen. Die meisten davon basieren auf PHP, setzen auf klassische Webserver-Stacks und speichern ihre Metadaten in einer relationalen Datenbank. Was im Kleinen funktioniert, wird mit wachsender Nutzerzahl und steigendem Datenvolumen zunehmend zur Herausforderung: Wartung, Performance und Support geraten in Schieflage – und das System gleicht einer Dauerbaustelle.

OpenCloud verfolgt einen anderen Ansatz. Wie angesprochen basiert die Open-Source-Plattform auf modular aufgebauten Go-Microservices und kommt ohne relationale Datenbank aus. Stattdessen lagern alle Informationen – inklusive Metadaten – direkt im POSIX-Dateisystem, ohne SQL oder Object-Relational Mapping und ohne die Gefahr einer Split-Brain-Situation zwischen Speicher und Index. OpenCloud vermeidet dabei die klassische Zwei-Tier-Architektur aus Webserver und Datenbank und setzt auf eine klare Drei-Tier-Trennung mit Benutzeroberfläche, API-Schicht und direktem Dateizugriff. Das reduziert die Komplexität und eliminiert typische Fehlerquellen im Storage-Management. Ziel ist eine Plattform, die sich im Alltag einfach betreiben lässt – für Admins ebenso wie für Benutzer, die zuverlässig auf ihre Dateien zugreifen wollen.

Datenbank als Schwachstelle

Ein Großteil der Supportfälle für Dateien im Cloud-Storage hat denselben Ursprung: die Datenbank. Zwar ist die Trennung von Dateiinhalt (Blob) und Metadaten auf den ersten Blick nachvollziehbar, doch sie bringt erhebliche Risiken mit sich. Beim Upload einer Datei wie etwa einem Bild landet in der Regel nur der Blob direkt auf dem Speicher. Alle zugehörigen Metadaten wie Dateiname, Pfad, Freigaben, Änderungszeitpunkt oder Dateigröße lagern separat in der Datenbank. Fällt diese aus oder gerät sie durch ein Backup oder ein Update in einen inkonsistenten Zustand, ist die Datei zwar physisch vorhanden, aber für die Anwendung nicht mehr sicht- oder verwendbar. Der Sync bricht ab und Anwender sehen leere Ordner oder verwaiste Dateieinträge.

OpenCloud setzt auf ein anderes Modell und speichert Metadaten und Dateiinhalt gemeinsam im Dateisystem. Das Dateisystem selbst ist die einzige maßgebliche Quelle – eine Single Source of Truth. Damit entfällt nicht nur die gesamte Datenbankadministration, sondern auch eine der häufigsten Fehlerquellen. Gleichzeitig steigt die Zuverlässigkeit des Systems ebenso spürbar wie die Skalierbarkeit.

Transparenter Speicher

Ein zentrales Merkmal von OpenCloud ist die Transparenz der Dateistruktur. Der komplette Datenbestand liegt als POSIX-Tree im Dateisystem, alle Informationen sind direkt zugänglich und menschenlesbar. Greifen Sie per SSH auf den Server zu, finden Sie unterhalb von "/var/lib/opencloud/storage/" verschiedene Unterverzeichnisse für Benutzer, Spaces (persönliche oder gemeinsame Dateiablagen [2]), Uploads und Indizes.

Im Verzeichnis "users/" ist für jedes Benutzerkonto ein eigener Ordner mit einer UUID als Namen angelegt. Innerhalb dieser Struktur liegen die persönlichen Spaces der Benutzer. Auch der Papierkorb ist dort sichtbar. OpenCloud verwendet ".Trash"-Verzeichnisse gemäß der "Freedesktop.org Trash Specification" [3], um gelöschte Dateien systemkonform abzulegen. Die Plattform setzt für die Metadaten erweiterte Attribute (Extended Attributes, xattr) ein, die es direkt an Dateien und Verzeichnisse bindet. Mit dem Tool "getfattr" lassen sich diese Informationen auf der Kommandozeile einsehen.

Auch jede Datei und jedes Verzeichnis erhalten beim Anlegen eine eindeutige UUID, die unter anderem dem internen Abgleich und der Vererbung innerhalb des Baums dient. Dazu kommen Angaben zur aktuellen Größe (blobsize), zur Änderungszeit (mtime) oder zum Pfad (parentid). Für Admins sind die wichtigsten Felder sofort nachvollziehbar, während das System zusätzliche interne Flags wie "type" oder "dirty" zur Synchronisation und Statusverwaltung nutzt.

Backup und Restore mit Konzept

Backups lassen sich bei OpenCloud einfach auf Dateisystemebene durchführen – allerdings mit einer wichtigen Besonderheit: Die erweiterten Attribute (xattr) müssen Sie mitsichern, da sie unter anderem Informationen zu Freigaben, IDs und Änderungszeitpunkten enthalten. Ein schlichtes "cp" reicht nicht aus, stattdessen sollten Sie Befehle wie cp -ar oder rsync -a verwenden, um die Attribute vollständig zu übernehmen. Alternativ können Sie kommerzielle Backupprodukte verwenden, sofern diese mit erweiterten Dateiattributen umgehen können.

Werden diese Attribute nicht erfasst, lassen sich zwar die Dateien wiederherstellen, aber wichtige Kontextinformationen wie Shares fehlen anschließend. Wir empfehlen daher, ganze Spaces gezielt zu sichern, also zum Beispiel den persönlichen Bereich unter "storage/users/" oder Projekträume unter "storage/projects/". So bleibt der komplette logische Zusammenhang erhalten und die Daten lassen sich im Ernstfall vollständig und konsistent zurückspielen.

Die OpenCloud-Entwickler empfehlen, regelmäßig Snapshots zu erstellen [4]. Voraussetzung ist, dass das Storage-Verzeichnis der Cloud auf einem Medium liegt, das ein entsprechendes Dateisystem mit Snapshot-Unterstützung verwendet. Ist das der Fall, lassen sich damit nicht nur die Dateien, sondern auch alle erweiterten Attribute zuverlässig sichern. Das Backup bleibt ohne zusätzliche Tools, Dumps oder Konvertierungen konsistent. Auch eine Wiederherstellung einzelner Spaces aus einem Snapshot ist problemlos möglich.

Um Daten in OpenCloud wiederherzustellen, sollten Sie konsequent das gleiche Prinzip verfolgen wie beim Backup: immer ganze Spaces sichern und zurückspielen. Denn jeder davon enthält neben den eigentlichen Dateien auch ein verstecktes Verzeichnis namens ".oc-nodes". Darin speichert OpenCloud interne Strukturen wie Versionsstände und Verweise – sie sind essenziell für eine vollständige Wiederherstellung.

Einzelne Dateien oder Ordner lassen sich zwar theoretisch separat sichern, beim Zurückspielen fehlt dann aber oft die Verbindung zur Dateihistorie – insbesondere, wenn ".oc-nodes" nicht erfasst wurde. Die Folge: Die Datei selbst erscheint im System, frühere Versionen oder Referenzen auf Freigaben jedoch nicht.

Datenbestände übernehmen

Nehmen wir an, in Ihrer Organisation liegt ein alter NFS-Share mit historischen Daten und Sie möchten diese sauber in OpenCloud übernehmen. Technisch ist das kein Problem, denn die Dateien lassen sich einfach in den Storage-Bereich von OpenCloud kopieren. Doch damit sie auch in der Oberfläche auftauchen und mit Metadaten verknüpft sind, fehlt noch ein entscheidender Schritt.

Standardmäßig muss OpenCloud nach einem solchen Import den Speicher einmal vollständig scannen. Erst dabei liest das System alle Dateien ein, vergibt eindeutige IDs und ergänzt die erweiterten Attribute. Ohne diesen Scan – etwa nach einem Neustart – bleiben die Daten zwar vorhanden, sind im Frontend aber zunächst nicht sichtbar. Genau hier setzt der File Observer an.

Der File Observer überwacht den OpenCloud-Speicher in Echtzeit und erkennt automatisch, wenn sich etwas im Dateisystem ändert. Die ist unabhängig davon, ob die Änderung über das Web-UI, den Desktopclient oder direkt auf der Kommandozeile erfolgt. Wird beispielsweise im richtigen Verzeichnis eine neue Datei erstellt, erscheint sie unmittelbar in der Benutzeroberfläche – ganz ohne manuellen Scan.

Ermöglicht wird das durch die Kernel-Funktion "inotify", die Datei- und Verzeichnisänderungen als Ereignisse meldet. Im Gegensatz zu periodischem Pol- ling, bei dem das Dateisystem regelmäßig vollständig durchsucht werden müsste, reagiert der File Observer eventbasiert und sofort. Auf allen gängigen Linux-Dateisystemen ist das Feature direkt einsatzbereit [5]. In seiner Business-Variante unterstützt OpenCloud zusätzlich spezialisierte Cluster-Dateisysteme wie etwa CephFS (in bestimmten Ausführungen) und IBM Spectrum Scale (ehemals GPFS). Diese bieten eine vergleichbare Event-Mechanik für verteilte Infrastrukturen, erfordern jedoch eine Rücksprache mit dem jeweiligen Anbieter.

Sie aktivieren dies über die Umgebungsvariable "STORAGE_USERS_POSIX_ WATCH_FS". In Docker-Umgebungen setzen Sie diese Variable in der ENV-Datei und sie wird so an den OpenCloud-Container übergeben. Der entsprechende Abschnitt in der docker-compose.yml-Datei sieht folgendermaßen aus:

Um die Auslastung der inotify-Ressourcen im Blick zu behalten, werfen Sie regelmäßig einen Blick in die Logdateien von OpenCloud. Der folgende Befehl zeigt nur die relevanten Zeilen an:

OpenCloud meldet nun in regelmäßigen Abständen, wie viele inotify-Instanzen und Watches aktuell aktiv sind. Ein dauerhaft hoher Wert größer als 90 Prozent bei den Instanzen oder Watches weist auf ein Limit-Problem hin. In diesem Fall sollten Sie die Kernel-Parameter prüfen und gegebenenfalls anpassen. Bild 3 zeigt eine typische Ausgabe mit moderater Auslastung und nachträglich eingefärbten Werten für bessere Lesbarkeit.

Externe Zugriffe beachten

In bestimmten Szenarien greifen Prozesse oder Benutzer direkt auf das zugrundeliegende Dateisystem zu – etwa über Skripte, Netzwerkfreigaben oder automatisierte Dienste. Auch in solchen Fällen erkennt OpenCloud Dateiänderungen in Echtzeit, sofern Sie bestimmte Regeln beachten. Erstellen Sie neue Dateien und Ordner immer direkt im richtigen Zielpfad und vermeiden Sie symbolische Links. Diese werden nicht unterstützt, weil sie zu Speicherorten außerhalb des überwachten Baums führen können. Wenn Sie Dateien zwischen verschiedenen Spaces verschieben, kann OpenCloud das nicht korrekt erkennen – das führt zu Problemen. Auch wenn Sie viele Dateien auf einmal ändern oder löschen, kann das die interne Strukturberechnung aus dem Takt bringen.

Achten Sie außerdem darauf, dass alle Dateien mit den passenden Eigentümern und Rechten versehen sind. Nachträgliche Korrekturen funktionieren meist nicht zuverlässig, weil OpenCloud dann bereits mit der Verarbeitung begonnen hat.

Fazit

Im Vergleich zu anderen Systemen fällt auf, wie konsequent OpenCloud das Speichermanagement auf das Dateisystem verlagert. Das bringt zwar neue Anforderungen mit sich – etwa bei Backups oder beim Umgang mit externen Zugriffen – reduziert aber auch viele typische Fehlerquellen.

OpenCloud als Dateispeicher nutzen

File-Verwalter

Was OpenCloud anders macht

Was OpenCloud anders macht

Datenbank als Schwachstelle

Transparenter Speicher

Backup und Restore mit Konzept

Datenbestände übernehmen

Externe Zugriffe beachten

Fazit