Nextcloud und der Tanz mit dem externen Speicher zwischen Freiheit und Kontrollverlust

„`html

Nextcloud und der Tanz mit dem externen Speicher: Zwischen Freiheit und Kontrollverlust

Es beginnt oft mit einer rationalen Entscheidung. Die Cloud-Speicher der großen Anbieter sind bequem, keine Frage. Aber der Preis – Datenhoheit, monatliche Gebühren, schleichende Vendor-Lock-ins – wird für viele Unternehmen und öffentliche Einrichtungen zunehmend als zu hoch empfunden. Nextcloud, die quelloffene Plattform für Dateisynchronisation und -freigabe, schien lange die Antwort zu sein: Selbst gehostet, erweiterbar, unter eigener Kontrolle. Doch dann kommt die unangenehme Wahrheit ans Licht: Der Speicherplatz auf dem eigenen Server ist endlich. Oder die gewünschte Redundanz lässt sich mit ein paar Festplatten im Rechenzentrum nicht abbilden. Oder die existierende Storage-Infrastruktur – ein NAS von Synology, ein SAN von Dell, ein S3-kompatibler Objektspeicher – will einfach weiterverwendet werden, ohne dass man alles neu aufbaut. Genau hier beginnt die eigentlich spannende Reise: Nextcloud externer Speicher. Es klingt unspektakulär, ist aber ein Thema, das Administratoren und Entscheider gleichermaßen fordern kann – und manchmal auch in die Irre führt.

Nextcloud selbst ist ja bekanntlich mehr als nur ein simpler Filehost. Es bietet Kalender, Kontakte, Kollaboration, Talk und eine Unmenge an Apps. Der Kern bleibt aber die Dateiverwaltung. Und die muss sich nahtlos in die bestehende Storage-Landschaft einfügen. Die Entwickler haben das früh erkannt und mit der App „Externer Speicher“ (offiziell: External Storage Support) ein mächtiges Werkzeug geschaffen. Oder vielleicht ein zu mächtiges? Denn die Möglichkeiten sind schier unendlich: SMB/CIFS, NFS, FTP, SFTP, WebDAV, Amazon S3, OpenStack Swift, S3-kompatible wie MinIO oder Ceph, und sogar Google Drive oder Dropbox rückwärts anbinden. Klingt nach dem Schweizer Taschenmesser der Datenanbindung – und das ist es auch. Aber wie bei jedem Taschenmesser muss man wissen, welche Klinge scharf ist und wo man sich schneiden kann.

Der Charme der Heterogenität – oder warum man nicht alles anfassen sollte

Ein typisches Szenario: Ein mittelständisches Maschinenbauunternehmen, 500 Mitarbeiter, hat über Jahre seine Daten auf einem zentralen NAS mit SMB-Freigaben organisiert. Die IT will nun Nextcloud einführen, um mobiles Arbeiten und externe Zusammenarbeit zu ermöglichen. Die logische Konsequenz: Man bindet die bestehenden SMB-Freigaben als externe Speicher in Nextcloud ein. Schnell, einfach, keine Migration. Ein Traum, oder? In der Praxis zeigt sich schnell, dass die Performance leidet. Nextcloud muss für jeden Dateizugriff das SMB-Protokoll durchlaufen, was oft mit Latenz und ineffizienter Metadatenverarbeitung einhergeht. Dazu kommt, dass SMB nicht für die parallelisierte Nutzung durch viele Benutzer optimiert ist, wie sie in einer Cloud-Umgebung typisch ist. Die Folge: Langsame Dateilisten, Timeouts, ärgerliche Benutzer. Das hat nichts mit Nextcloud an sich zu tun, sondern mit der Architektur. Nextcloud agiert hier als Gateway – und jedes Gateway bremst.

Ein interessanter Punkt, der oft übersehen wird: Nextclouds externe Speicher werden standardmäßig nicht im eigenen Datenbank-Cache abgebildet. Die Dateiliste wird live vom externen System abgefragt. Für kleine Ordnerstrukturen mag das noch funktionieren, aber wenn jemand in einem Verzeichnis mit zehntausend Dateien navigiert, wird der Unterschied sofort spürbar. Nextcloud selbst ist darauf angewiesen, seine Metadaten (Größe, Änderungsdatum, Berechtigungen) schnell parsen zu können. Bei SMB oder gar FTP ist das einfach nicht gegeben. Nicht zuletzt aus diesem Grund empfiehlt Nextcloud für professionelle Einsätze oft die Nutzung von Objektspeichern als primärem Speicher, nicht als externe Anbindung. Aber dazu später mehr.

Manchmal fragt man sich: Wieso bieten die Entwickler überhaupt so viele Optionen an, wenn viele davon in der Praxis suboptimal sind? Die Antwort ist pragmatisch: Es geht um Interoperabilität. In einer heterogenen IT-Landschaft, in der Abteilungen ihre eigenen Dateiserver betreiben, ist die Anbindung als externer Speicher die einzige Möglichkeit, diese Daten überhaupt über Nextcloud zugänglich zu machen, ohne sie physisch zu verschieben. Es ist ein Kompromiss – und als solcher muss man ihn auch verstehen. Wer Nextcloud als zentralen Kollaborations-Hub sieht, der alle Dateninseln verbindet, der wird um diese Funktion kaum herumkommen. Aber der sollte die Fallstricke kennen.

Objekt speichern, glücklich sein? S3 als Schlüssel zur skalierbaren Nextcloud-Instanz

Wenn wir von Nextcloud und externem Speicher sprechen, dann geht es meist um die Anbindung von S3-kompatiblen Objektspeichern. Und hier wird die Sache richtig interessant. Denn Nextcloud kann S3 nicht nur als externen Speicher nutzen, sondern es ist tief in die Architektur integriert. Seit Version 20 oder so, ich hab den genauen Release nicht im Kopf, gibt es die Möglichkeit, den primären Datenspeicher auf S3 zu legen – über die Konfigurationsdatei config.php. Das ist ein fundamentaler Unterschied zur reinen External-Storage-App: Hier wird S3 zum internen Speicherbackend, das Nextcloud genauso behandelt wie lokale Verzeichnisse. Die Vorteile liegen auf der Hand: Skalierbarkeit, keine Limits bei der Dateigröße, integrierte Redundanz und oft geringere Kosten pro Gigabyte als bei teuren SANs.

Ich erinnere mich an ein Gespräch mit einem CTO einer großen Forschungseinrichtung. Die hatten Petabytes an Daten, die eigentlich für die Wissenschaft vorgehalten werden mussten, aber dennoch über Nextcloud kollaborativ zugänglich sein sollten. Die Lösung war ein Ceph-Cluster, der via S3 an Nextcloud angebunden wurde. Das funktioniert, wenn man die Architektur richtig plant. Wichtig ist, dass Nextcloud hier als „Metadata Layer“ fungiert: Die eigentlichen Dateien liegen im Objektspeicher, die Metadaten (Dateiname, Pfad, Versionen, Freigaben) verwaltet Nextcloud in seiner eigenen Datenbank. Diese Trennung erlaubt eine enorme Skalierung, denn der Objektspeicher kann horizontal wachsen, während die Nextcloud-Instanz selbst entlastet wird.

Ein Aspekt, der bei S3 häufig unterschätzt wird: Die Latenz. S3 ist per HTTP(S) angebunden, und jeder Dateizugriff erzeugt Netzwerkverkehr. Wenn der S3-Endpunkt weit entfernt liegt (z.B. in einer anderen Region), können selbst kleine Operationen spürbar langsam sein. Nextcloud versucht, durch Caching-Mechanismen (z.B. Redis, APCu) und Prefetching entgegenzuwirken, aber das grundlegende Problem bleibt. Die Lösung? Entweder man setzt einen lokalen S3-kompatiblen Speicher wie MinIO im gleichen Netzwerk ein oder man akzeptiert die Latenz und optimiert die Workflows entsprechend. Für große Dateien, die selten geändert werden (Archivdaten, ISO-Images), spielt die Latenz kaum eine Rolle. Für häufige Lese- und Schreibzugriffe auf kleine Dateien (z.B. Textdateien, Tabellen) kann sie jedoch den Unterschied zwischen akzeptabler und frustrierender Performance ausmachen.

Ein kleiner Tipp am Rande: Bei der Konfiguration von Nextcloud mit externem S3-Speicher sollte man unbedingt darauf achten, dass der Objektspeicher die Funktion „Object Versioning“ unterstützt. Die neueren Nextcloud-Versionen können das nutzen, um Dateiversionen effizient zu verwalten – ohne zusätzlichen Speicherverbrauch durch Kopien. Ein Feature, das leider viele übersehen und dann über den Speicherverbrauch klagen. Aber das führt uns zum nächsten Punkt.

Die Sicherheitsfrage: Wer kontrolliert die Kontrolleure?

Externer Speicher ist ein zweischneidiges Schwert für die Datensicherheit. Einerseits kann man bestehende, vielleicht zertifizierte Storage-Systeme (etwa mit GDPR-Compliance) weiter nutzen, ohne Daten in eine neue Umgebung zu migrieren. Andererseits öffnet man mit der Anbindung eines externen Speichers auch neue Angriffsvektoren. Nextcloud selbst ist gut abgesichert, aber die externe Verbindung – sei es über SMB, NFS oder S3 – muss ebenfalls sicher sein. Ein Klassiker: ein NAS mit SMB, das noch SMBv1 unterstützt. Oder ein FTP-Server ohne TLS. Die External-Storage-App erlaubt die Konfiguration von Protokollen, aber sie warnt nicht automatisch vor unsicheren Einstellungen. Das liegt in der Verantwortung des Administrators.

Ein interessanter Aspekt ist die Verschlüsselung. Nextcloud kann Dateien clientseitig verschlüsseln (Ende-zu-Ende-Verschlüsselung per App), aber das funktioniert nur für den internen Speicher. Bei externen Speichern, die über die App angebunden sind, greift diese Verschlüsselung nicht. Das ist eine wichtige Einschränkung: Wer also sensible Daten auf einem externen SMB-Share oder S3-Bucket ablegt, muss sich auf die Verschlüsselung des jeweiligen Systems verlassen. Bei S3 wäre das die serverseitige Verschlüsselung (SSE-S3, SSE-KMS) oder die clientseitige Verschlüsselung vor dem Hochladen. Nextcloud selbst bietet hier keine zusätzliche Sicherheit. Das ist in vielen Diskussionen mit Compliance-Beauftragten ein heißes Thema: „Wir haben Nextcloud, also sind die Daten verschlüsselt.“ Falsch. Nicht automatisch. Man muss es aktiv umsetzen.

Ein weiterer Sicherheitsaspekt: Die Berechtigungsverwaltung. Nextclouds eigene Sharing-Mechanismen mit Gruppen und Benutzern sind relativ granular. Wenn man aber externe Speicher anbindet, kann es zu Konflikten kommen. Ein Benutzer, der in Nextcloud Schreibzugriff auf einen Ordner hat, der auf einem externen SMB-Share liegt, benötigt auch auf der SMB-Ebene die entsprechenden Rechte. Das klingt trivial, ist aber in der Praxis eine der häufigsten Fehlerquellen. Der Admin richtet den Speicher ein, vergisst die SMB-Berechtigungen und wundert sich dann, warum die Datei nicht geschrieben werden kann. Die Fehlermeldungen, die Nextcloud liefert, sind in solchen Fällen oft wenig hilfreich. „Access denied“ – ja, aber wo genau? Liegt es an Nextcloud, am Betriebssystem, am Netzwerk oder am NAS? Eine Systemsicht ist hier unverzichtbar. Nicht zuletzt deswegen rate ich jedem, der mit Nextcloud externer Speicher arbeitet, sich mit den Logfiles auf allen Ebenen vertraut zu machen – und das meine ich ernst.

Performance und Caching: Das Drama der vielen kleinen Dateien

Ein Problem, das in Foren und Mailinglisten immer wieder auftaucht: Nextcloud ist langsam, wenn man viele tausend Dateien in einem Ordner hat. Das ist nicht primär ein Problem von Nextcloud, sondern eine Eigenheit von Dateisystemen und Netzwerkprotokollen. Aber Nextcloud macht es nicht unbedingt besser. Wenn der externe Speicher über SMB oder NFS angebunden ist, wird jeder Lese-/Schreibzugriff zu einem RPC-Aufruf. Die Latenz multipliziert sich mit der Anzahl der Dateien. Nextcloud versucht, mit einem internen Cache (das sogenannte „Preview Generation“, „Metadata Cache“) zu helfen, aber dieser Cache bezieht sich meist nur auf den primären Speicher, also das, was in datadirectory eingestellt ist. Bei externen Speichern, die per App angebunden sind, gibt es keinen vergleichbaren Metadaten-Cache auf Dateiebene. Es gibt einen „External Storage Cache“ in den Einstellungen, aber der ist sehr rudimentär und wird oft nicht aktiviert. Dabei kann er einen deutlichen Unterschied machen – vor allem, wenn der externe Speicher langsam ist.

Ein konkreter Fall: Eine Behörde nutzt Nextcloud mit einem NAS per NFS. Die IT hat den externen Speicher mit dem Label „Archiv“ versehen. In diesem Archiv liegen etwa 500.000 PDFs. Die Mitarbeiter klagen, dass die Ordneranzeige „endlos“ dauert. Die Lösung war: Cache einschalten. In der Konfiguration des externen Speichers gibt es die Option „Metadaten cachen“. Diese Option bewirkt, dass Nextcloud die Dateiliste lokal in der Datenbank zwischenspeichert und nur bei Änderungen aktualisiert. Das reduziert die Zugriffe auf das NAS drastisch. Nach dem Aktivieren – plus dem Setzen eines Cron-Jobs, der den Cache regelmäßig erneuert – war die Performance akzeptabel. Keine Wunder, aber es funktionierte. Man muss allerdings bedenken: Der Cache belegt Datenbankplatz und muss gewartet werden. Bei Änderungen außerhalb von Nextcloud (z.B. jemand löscht direkt per SMB eine Datei) wird der Cache inkonsistent. Nextcloud kann das nicht automatisch erkennen, es sei denn, man nutzt dateisystembasierte Watcher wie inotify – was bei NFS/CIFS nicht funktioniert. Also: Der Cache ist ein hilfreiches Werkzeug, aber kein Allheilmittel.

Ein weiterer Performance-Tipp: Wenn möglich, auf Objektspeicher setzen. S3-Anbieter wie Wasabi oder Backblaze bieten meist eine lineare Performance, unabhängig von der Anzahl der Dateien – zumindest bei den meisten Lastprofilen. Allerdings ist S3 nicht für viele kleine Dateien optimiert. Für Nextcloud, das Millionen von Mini-Dateien (nicht selten 1-10 KB) verwaltet, kann das zu Kosten führen, denn viele S3-Anbieter berechnen pro PUT/GET-Request. Das kann teuer werden, wenn jeder Dateizugriff einen Request auslöst. Nextcloud versucht, durch Batch-Operationen (z.B. Uploads als Multipart) die Anzahl der Requests zu reduzieren, aber ganz verhindern lässt es sich nicht. Für große Dateien (mehrere MB) ist S3 quasi perfekt. Für den Massenbetrieb mit vielen kleinen Dateien empfehle ich, den externen Speicher nur für Dateien zu nutzen, die selten geändert werden, und die aktiven Arbeitsbereiche intern zu halten. Oder, wenn das nicht geht, auf eine lokale SSD-basierte Lösung für den Primärspeicher plus S3 für Archivdaten zu setzen.

Die Qual der Wahl: Welches Protokoll für welchen Zweck?

Die External-Storage-App bietet eine lange Liste an Protokollen. Ich möchte ein paar davon kurz bewerten – aus der Erfahrung von mehreren Projekten, nicht aus dem Datenblatt.

SMB/CIFS: Der Klassiker für Windows-Umgebungen. In der Praxis oft das Protokoll, mit dem Nextcloud am schlechtesten harmoniert. Zu viele Fallstricke: Zeichensatzprobleme (Umlaute, Sonderzeichen), Performance-Einbußen bei vielen Dateien, keine Unterstützung für Sperrmechanismen (File Locking) in vielen Konfigurationen. Trotzdem: Es funktioniert für einfache Use Cases. Wer SMB nutzen muss, sollte auf SMB3 setzen und die Option „Dir Charset“ und „File Charset“ in der Konfiguration auf UTF-8 setzen. Und unbedingt die neueste Samba-Version verwenden.

NFS: Deutlich besser geeignet für Linux-umgebungen. Nextcloud kann NFSv4 mit Kerberos-Authentifizierung. Die Performance ist meist ok, solange die Netzwerklatenz gering ist. Achtung: Nextcloud erwartet, dass die Benutzer-IDs auf dem NFS-Server mit denen auf dem Nextcloud-Server übereinstimmen (UID-Mapping). Das ist ein häufiger Konfigurationsfehler. Wenn der Admin auf dem NAS eine andere UID für den Benutzer „data“ hat, klappt der Zugriff nicht. Fehlermeldung: „Permission denied“. Lösung: entweder UIDs angleichen oder mit nfs4_map_static oder ähnlichen Mechanismen arbeiten.

FTP/SFTP: Bitte nur als absolute Notlösung. FTP ist unverschlüsselt, SFTP ist besser, aber beide Protokolle sind nicht für die synchrone Nutzung durch viele Benutzer gedacht. Kein Metadaten-Cache, keine Sperrmechanismen, keine zuverlässige Änderungserkennung. Ich habe ein Projekt begleitet, bei dem ein Hoster unbedingt Nextcloud auf seinem Legacy-FTP-Server aufsetzen wollte. Es wurde ein Disaster: Dateien wurden doppelt hochgeladen, Ordnerstrukturen korrumpiert, Benutzer sahen veraltete Dateilisten. Nach zwei Monaten wurde auf S3 umgestellt. Der Kunde war glücklich, der Hoster zahlte Lehrgeld.

WebDAV: Ironischerweise ist das das Protokoll, das Nextcloud selbst für Client-Zugriffe verwendet. Externes WebDAV anzubinden ist möglich, macht aber meist nur Sinn, wenn man alte Dokumentenmanagementsysteme anbinden will, die nur WebDAV sprechen. Vorsicht: Nextcloud selbst interpretiert WebDAV anders als viele andere Systeme. Ich rate, WebDAV als externen Speicher nur mit spezifischen Systemen zu testen – nicht blind vertrauen.

S3 und S3-kompatible: Die Königsklasse. Hier gibt es spezielle Apps („S3 Storage“) oder die direkte Integration über die Konfiguration. Wer Nextcloud skalierbar und zukunftssicher betreiben will, kommt an S3 kaum vorbei. MinIO ist der heimliche Favorit unter Open-Source-Fans: einfach aufzusetzen, kompatibel, performant. Auch Ceph ist möglich, aber deutlich komplexer. Für Unternehmen, die keine Lust auf Selbstbetrieb haben, gibt es Wasabi, Backblaze B2 oder die S3-Angebote der großen Hyperscaler. Letztere sollten aber genau auf die Kosten pro Request geprüft werden.

Lizenz und Vendor-Lock: Ist externer Speicher die Rettung?

Ein interessanter Aspekt, der oft in der Diskussion um Open-Source-Software vernachlässigt wird: Die Lizenzpolitik von Nextcloud. Nextcloud selbst ist AGPL lizenziert, also frei. Aber die External-Storage-App ist Teil der Standarddistribution, also auch frei. Allerdings gibt es für die Enterprise-Version mit Support und zusätzlichen Features eine Bezahlschiene. Die Unterscheidung zwischen Community und Enterprise betrifft nicht die grundsätzliche Funktion des externen Speichers, wohl aber die Performance (z.B. verbesserte Caching-Mechanismen, parallele Uploads, S3 Multipart). Wer wirklich große Datenmengen verwaltet, wird um die Enterprise-Version kaum herumkommen – nicht wegen der Grundfunktion, sondern wegen der Stabilität und Geschwindigkeit. Ist das Vendor-Lock? Man könnte es so sehen. Andererseits finanziert Nextcloud damit die Weiterentwicklung. Und die Community-Version bleibt funktionstüchtig, auch wenn sie bei vielen Dateien ggf. langsamer ist.

Die Wahl des externen Speichers ist auch eine strategische Entscheidung gegen Vendor-Lock: Wer S3-Schnittstelle nutzt, kann jederzeit den Anbieter wechseln (Wasabi zu MinIO, MinIO zu Ceph, etc.). Das ist der große Vorteil von S3 gegenüber proprietären APIs. Auch NFS und SMB sind offene Standards – wenn auch plattformabhängig. Wer aber Nextcloud mit einer proprietären Storage-Lösung wie einem Dell EMC Isilon über NFS anbindet, tauscht den einen Vendor (Nextcloud) gegen einen anderen (Dell) ein. Solange beide offene Schnittstellen nutzen, ist das kein Problem. Aber die Gefahr, in einer proprietären Lösung gefangen zu sein, die nur mit bestimmten Protokollen funktioniert, ist real. Ich empfehle, bei der Storage-Wahl auf Standards zu setzen: S3, NFSv4, CIFS/SMB3 – das sind Protokolle, die auch nach einem Vendor-Wechsel funktionieren.

Migration und Datenkonsistenz: Der blinde Fleck

Ein Thema, das in keiner Projektplanung ausreichend diskutiert wird: Wie kommt der externe Speicher überhaupt sauber in Nextcloud? Nehmen wir an, auf dem NAS liegen bereits zehn Jahre alte Ordner mit einer chaotischen Struktur. Die External-Storage-App bindet sie ein und zeigt sie in Nextcloud an. Das Problem: Nextcloud erkennt keine Änderungen an den Dateien, die nicht durch Nextcloud getätigt wurden. Wenn ein Benutzer direkt per SMB eine Datei löscht, taucht sie in Nextcloud trotzdem noch auf – bis zum nächsten Cache-Update. Und umgekehrt: Wenn Nextcloud eine Datei speichert, kann es sein, dass sie auf dem NAS mit anderen Berechtigungen ankommt als erwartet. Das führt zu Inkonsistenzen, die schwer zu debuggen sind. Es gibt eine Kommandozeilen-Option occ files:scan, die den Dateibaum neu scannt. Das sollte man nach jeder größeren Änderung außerhalb von Nextcloud ausführen. Dieser Scan kann aber bei vielen Dateien sehr lange dauern und den Server belasten.

Ich habe mal einen Fall erlebt, da hat ein Admin einen externen Speicher aus Versehen mit doppelter Konfiguration eingebunden – einmal als SMB und einmal als S3 mit identischem Inhalt. Die Dateien wurden daraufhin in Nextcloud dupliziert angezeigt, die Benutzer waren verwirrt, die Datenbank wuchs explosionsartig. Solche Fehler sind schnell passiert, wenn man sich nicht genau notiert, was man konfiguriert hat. Die External-Storage-Oberfläche in Nextcloud ist gut, aber nicht aufräumt. Ein Tipp: Vor der Einrichtung eines externen Speichers immer einen Testordner anlegen und die Berechtigungen prüfen. Und alles dokumentieren. Klingt banal, wird aber in der Hektik oft vergessen.

Praxisbeispiel: Medienproduktion und externer Speicher

Ein spannendes Szenario: Medienschaffende, die mit Nextcloud arbeiten. Ein Filmproduktionsunternehmen hat Nextcloud im Einsatz, um auf die Rohmaterialien zuzugreifen. Die Dateien sind riesig – mehrere 100 GB pro Projekt. Ein lokaler Speicher wäre zu teuer, also wird ein S3-Bucket bei einem Provider in der gleichen Region gemietet. Nextcloud als Frontend, S3 als Backend. Die Herausforderung: Die Dateien sollen direkt über Nextcloud gestreamt werden können (z.B. für Preview), ohne dass sie komplett heruntergeladen werden müssen. Nextclouds Preview-Generator kann das nicht für alle Formate, aber für gängige Codecs wie H.264/265. Allerdings erzeugt der Preview-Generator bei externen Speichern eine hohe Netzwerklast, weil er die Originaldateien aus dem S3 lesen muss. Die Lösung war, einen lokalen Cache für Vorschaubilder auf einer SSD einzurichten und die Originals auf S3 zu belassen. Kombiniert mit einem CDN für die Auslieferung – das hat funktioniert. Wichtig war hier: Die External-Storage-App musste den S3-Speicher als primären Speicher markieren (für die Dateiverwaltung), aber die Preview-Generierung auf den Cache umleiten. Das geht nicht out-of-the-box, sondern erfordert ein wenig Handarbeit mit Redis und Custom-Configs. Aber es zeigt, dass Nextcloud mit externem Speicher sehr skalieren kann, wenn man bereit ist, in die Tiefe zu gehen.

Fazit: Freiräume schaffen, aber nicht blind vertrauen

Nextcloud und externer Speicher – das klingt nach der perfekten Symbiose: die Offenheit und Flexibilität von Nextcloud kombiniert mit der bestehenden Storage-Infrastruktur. Und in vielen Fällen ist es genau das. Aber es gibt kein kostenloses Mittagessen. Wer externe Speicher nutzt, muss sich mit den Eigenheiten der Protokolle auseinandersetzen, muss Caching-Konzepte verstehen und die Latenz im Auge behalten. Ich rate jedem, der diesen Weg geht, sich vorher klar zu machen: Ist der externe Speicher eine temporäre Brücke (bis zur Migration auf einen neuen Speicher) oder eine dauerhafte Lösung? Im zweiten Fall sollte man die Architektur von Grund auf planen – mit Objektspeicher als primärem Speicher und gegebenenfalls weiteren externen Speichern nur für spezielle Use Cases (z.B. Archiv, Backup). Und man sollte nie vergessen, dass Nextcloud selbst nur so gut ist wie das darunterliegende Speichersystem. Ein schneller Server mit langsamem NAS bleibt ein bottleneck.

Die Entwicklung von Nextcloud in den letzten Jahren zeigt, dass die Entwickler die Kritik ernst nehmen. Mit Version 28 kamen Verbesserungen bei der S3-Integration, unter anderem eine bessere Parallelisierung von Uploads und optimierte Caching-Strategien. Auch das „Storage Backend Framework“ wurde überarbeitet, sodass der externe Speicher nicht mehr nur eine App, sondern ein Kernfeature ist. Trotzdem: Die Verantwortung liegt beim Administrator. Nextcloud kann nur das anbieten, was die zugrunde liegende Infrastruktur hergibt. Wer das versteht, wird mit Nextcloud und externem Speicher wahrscheinlich glücklich. Wer glaubt, dass die Software alle Eigenheiten des Speichersystems magisch wegabstrahiert, wird enttäuscht werden. In diesem Sinne: Planen, testen, dokumentieren – und nicht einfach „irgendeinen Speicher“ anbinden. Dann klappt’s.

Ein letzter Gedanke: Open Source lebt von der Gemeinschaft. Wer auf Probleme mit Nextcloud externer Speicher stößt, sollte sie nicht nur in Foren posten, sondern auch einen Blick in die lib/private/Files/Storage/ werfen. Der Quellcode ist lesbar, und manchmal ist es einfacher, selbst einen Patch zu schreiben, als auf eine Antwort zu warten. So bleibt man nicht nur Konsument, sondern auch Gestalter der eigenen Infrastruktur. Und das ist doch der eigentliche Kern von Nextcloud – digitale Selbstbestimmung, bis auf die Speicherebene hinunter.

„`