Speicher macht’s aus
Nextcloud ist mehr als nur ein weiterer File-Server. Im Kern ist die Software eine Plattform, die Daten, Termine, Kontakte und kollaboratives Arbeiten zusammenführt – und je länger man sie betreibt, desto mehr dreht sich das Gespräch um dieselbe Frage: Wo legen wir das alles ab, und wie bekommen wir mehr Platz? Die gute Nachricht: Nextcloud ist flexibel. Die schlechte: Diese Flexibilität verführt dazu, mit einer Ad-hoc-Lösung zu starten, die später wehtut. Speicher ist in der Cloud eine scheinbar unendliche Ressource, beim Selbsthosting jedoch ein knappes Gut, das sich mit Benutzerzahlen, Synchronisationsmustern und Dateigrößen ändert. Wer einmal eine Nextcloud-Instanz betreut hat, kennt die Situation, wenn die Warnmeldung des Dateisystems auftaucht: „No space left on device“ – da hilft keine schnelle Festplatte im Vorbeigehen.
Dieser Artikel ist eine Tour durch die Speicherfrage. Es geht darum, wie sich der Platz erweitern lässt, welche Methoden sauber sind, wo Fallstricke lauern, und was man bereits beim Einrichten beachten sollte. Ein Schwerpunkt liegt auf den verschiedenen Wegen, den Speicher zu vergrößern: vom simplen Einbau einer neuen Platte über das Verlegen des Datenverzeichnisses bis hin zum Anbinden externer Speicher wie NFS oder S3-kompatiblen Objektspeichern. Wir werden uns auch die Konfiguration ansehen – die Datei config.php, das Kommandozeilenwerkzeug occ und die Frage, welche Rolle Quotas im Alltag spielen. Das ist kein Anfängerkurs, sondern ein praxisorientierter Leitfaden für alle, die eine bestehende Installation verwalten oder ein neues Projekt planen.
Ein kurzer Blick auf die Architektur
Bevor man an den Speicher denkt, muss man verstehen, wie Nextcloud Daten organisiert. Das gesamte Dateisystem der Anwendung liegt in einem Verzeichnis, das data directory genannt wird. Dort befinden sich die Benutzerordner, Zertifikate, Cache-Dateien und die Datenbank – nicht zu verwechseln mit MySQL- oder PostgreSQL-Daten, die normalerweise separat liegen. Aus Sicht des Betriebssystems ist das schlicht ein Pfad, häufig /var/www/nextcloud/data oder /srv/nextcloud, der ausreichend Platz bieten muss. Wenn eine Nextcloud-Instanz wächst, dann wächst typischerweise genau dieser Ordner.
Die Datenbank speichert Metadaten: Dateinamen, Pfade, Größen, Versionsstände und Freigaben. Die eigentlichen Inhalte liegen auf dem Dateisystem. Dieses getrennte Modell hat einen praktischen Vorteil: Man kann den Datenspeicher an nahezu jede Infrastruktur anbinden, die ein Betriebssystem als Dateisystem kennt. Das kann eine physische Platte im Server sein, ein NAS per NFS, ein Windows-Share per SMB, ein SSHFS-Mount oder ein S3-kompatibler Objektspeicher. Nextcloud behandelt diesen Speicher in der Standardkonfiguration als einen einzigen Ort. Man muss also nicht unbedingt im laufenden Betrieb große Migrationen durchführen, sondern kann das Zielverzeichnis verändern – mit der richtigen Vorbereitung und den richtigen Werkzeugen.
Über den Daumen gepeilt: Was nimmt eigentlich Platz weg?
Es gibt nicht die eine typische Nextcloud-Installation. Eine kleine Firma mit zehn Angestellten hat andere Anforderungen als eine Universität mit tausenden Nutzern. Dennoch lassen sich Muster beobachten. Dateien, die synchronisiert werden, führen oft zu mehrfachem Platzverbrauch, weil Nextcloud umfangreiche Versionsverwaltung und Papierkorb-Funktionen mitbringt. Standardmäßig werden 50 Versionen einer Datei aufgehoben, der Papierkorb bleibt für 30 Tage erhalten. Zwei Accounts, die dieselbe Datei in getrennte Ordner kopieren, verdoppeln den Speicherplatz. Dazu kommen Systemdateien, die Datenbank, temporäre Daten beim Upload und die Logdateien, die bei Problemlage Gigabyte groß werden können.
Eine einfache Faustregel lautet: Wer eine Nextcloud mit Online-Office, Collabora oder OnlyOffice betreibt, sollte den Platzbedarf der Dokumente mit dem Faktor 1,5 bis 2 kalkulieren, wenn er die Standardeinstellungen nicht ändert. Als praktischer Satz: Es lohnt sich, frühzeitig ein Monitoring einzurichten, das nicht nur die Gesamtbelegung der Partition meldet, sondern auch das Wachstum des Nextcloud-Datenverzeichnisses über die Zeit protokolliert. Wer das versäumt, steht irgendwann vor einem Berg von Daten und keiner Ahnung, wann die Party begonnen hat.
Die erste Rettung: Mehr Festplatte, größere Partition
Der klassische Weg, um Speicher zu erweitern, ist eine größere Festplatte oder eine zusätzliche Platte im Server. Unter Linux bedeutet das, eine neue Partition anzulegen, sie ins Dateisystem einzuhängen und das Datenverzeichnis dorthin zu verlegen. Klingt simpel, ist es aber nur, wenn man vorher das Dateisystem umgestellt oder logische Volumes eingeplant hat. Ohne LVM bleibt man auf die Größe einer Partition festgelegt und muss mit resize2fs oder xfs_growfs arbeiten, sofern genügend freier Platz auf der zugrunde liegenden Platte oder dem RAID-Verbund vorhanden ist.
Deshalb eine Empfehlung, die fast schon als Grundsatz gelten sollte: Bei Neuinstallationen von Nextcloud auf eigenen Servern ist LVM (Logical Volume Manager) oder zumindest ein Btrfs-Dateisystem mit Subvolumes eine Investition in die Zukunft. LVM erlaubt es, eine Partition um andere physische Volumes zu erweitern, ohne lange Ausfallzeiten. Wächst die Firma, wird eine zweite Platte eingebaut, als Physical Volume hinzugefügt, das Logical Volume und anschließend das Dateisystem vergrößert. Das Ganze ist in Minuten erledigt, die Nextcloud-Instanz kann währenddessen laufen – zumindest bei ext4 mit Online-Resize. Das ist ein Unterschied zu der klassischen Mühsal, einen Dienst zu stoppen, Daten zu kopieren, die Partition umzubauen und wieder zu starten.
Wie verlegt man das Datenverzeichnis auf einen neuen Mount? Zuerst muss die Nextcloud-Instanz in den Wartungsmodus versetzt werden: occ maintenance:mode --on. Dann kopiert man die Dateien mit rsync an den neuen Ort, wobei Metadaten wie Ownership und Zeitstempel erhalten bleiben müssen. Wer hier nur cp -R verwendet, riskiert, dass am Ende die Berechtigungen nicht stimmen. Nach dem Kopieren wird der Eintrag 'datadirectory' in der config.php geändert. Im Anschluss werden die Datei-Caches neu aufgebaut, denn in der Datenbank stehen noch die alten Pfade: occ files:scan --all. Dieser Befehl durchsucht das neue Verzeichnis und aktualisiert die Datenbank. Bei großen Installationen kann das dauern und sollte in einem Screen- oder tmux-Session laufen, da sonst ein SSH-Timeout den Vorgang abbricht. Danach den Wartungsmodus abschalten und die Logs beobachten.
Kein Spaß hingegen ist das Umstellen, wenn die Daten auf einem Dateisystem liegen, das keine volle Unterstützung für alle Funktionen bietet. Nextcloud macht etwa bestimmte Annahmen über Längen von Dateinamen, Groß- und Kleinschreibung oder die Möglichkeit, symbolische Links anzulegen. Ein FAT32-USB-Stick ist als Datenverzeichnis keine gute Idee, das sollte klar sein. Wer einen Server betreibt, wird sowieso ein Linux-Dateisystem verwenden. Dennoch geistern im Forum immer wieder Konfigurationen herum, bei denen Nextcloud auf einem Samba-Share mit einer Windows-Art der Pfadauflösung hängt. Das funktioniert eine Weile, aber spätestens beim Speicher-grenzenlos-Erweitern wird es ungemütlich.
Dateisysteme: ext4, Btrfs, XFS – was wählt man für Nextcloud?
Die Frage nach dem richtigen Dateisystem ist nicht nur eine religiöse. Ext4 ist der Allrounder: stabil, schnell, gut untersucht. XFS bietet eine hohe Skalierbarkeit bei einem einzelnen großen Verzeichnisbaum, was bei Nextcloud mit vielen Millionen Dateien eine Rolle spielen kann – gleichzeitig kann man XFS nicht einfach verkleinern, also bitte von Anfang an großzügig dimensionieren. Btrfs hat den Charme von Snapshots und integriertem Subvolume, verkompliziert aber auch manche Operationen. Für eine reine Nextcloud-Installation mit einem einzelnen Server ist ext4 auf einem LVM-Volume immer noch der sicherste Hafen.
Eine häufige Fehlkonfiguration ist die Inode-Erschöpfung. Nextcloud legt viele kleine Dateien an, Caches, Sessions, temporäre Dateien. Wird das Dateisystem mit zu wenigen Inodes erstellt, ist die Platte noch halb leer, aber das System meldet „Kein Speicherplatz mehr übrig“. Das passiert vor allem dann, wenn man das Datenverzeichnis auf einer kleinen Partition mit Standardwerten eingerichtet hat. Ein Check mit df -i bringt Klarheit. Bei der Erweiterung mit LVM und einer Vergrößerung des Dateisystems wächst die Inode-Zahl bei ext4 normalerweise mit. Wenn nicht, kann man mit mkfs.ext4 -O metadata_csum oder einer passenden Inode-Ratio von vornherein gegensteuern – vorausgesetzt, man ist noch in der Planungsphase.
Externe Speicher anbinden: NFS, SMB, SFTP
Wer nicht am einzelnen Server arbeiten will oder mehrere Nextcloud-Instanzen mit einem gemeinsamen Speicher versorgen möchte, bindet externe Dateisysteme per NFS oder SMB an. Das ist kein Hexenwerk, aber es gibt ein paar Besonderheiten. Nextcloud kann die externen Mounts entweder systemweit über das Betriebssystem anbinden oder benutzerbezogen in der Anwendung konfigurieren. In der Administrationsoberfläche existiert die App „Externe Speicher“ (External Storage). Damit lassen sich Speicherorte hinzufügen, die für einzelne Benutzer, Gruppen oder alle einsehbar sind. Unterstützt werden unter anderem SMB, NFS, SFTP, S3, OpenStack Swift und WebDAV.
Der Vorteil dieser Herangehensweise liegt auf der Hand: Man kann vorhandene NAS-Laufwerke, Windows-Shares oder Cloud-Speicher einbinden, ohne sie physisch in den Nextcloud-Server hängen zu müssen. Aber: Die Performance leidet deutlich, wenn viele Benutzer gleichzeitig auf ein SMB-Share im Büro zugreifen. Die Latenzen sind höher, die Locking-Mechanismen von SMB vertragen sich nicht immer mit den Erwartungen von Nextcloud. NFS ist da besser, aber auch dort muss man auf die Mount-Optionen achten. Empfehlenswert sind Optionen wie rsize=1048576, wsize=1048576, hard, noatime und, falls möglich, vers=4.2. Letzteres kann für bessere Performance und stabileres Verhalten sorgen, gerade wenn der Server viele kleine Dateien anfasst.
Ein wichtiges Detail: Nextcloud verwendet für das Datenverzeichnis selbst keine SMB-/NFS-Anbindung als Primärspeicher. Das Datenverzeichnis sollte immer lokal sein oder zumindest auf einem sehr performanten Objektspeicher liegen. Die externen Speicher sind eine Ergänzung und nicht das Fundament. Wenn beide Welten kombiniert werden, muss man auch über das Ende einer Datei nachdenken, die in einem externen Speicher liegt und in der Datenbank aufscheint. Beim Löschen einer Datei wird sie zunächst in den Papierkorb verschoben, egal ob der Speicher intern oder extern liegt. Die Versionsverwaltung arbeitet bei externen Speichern nur eingeschränkt, je nachdem, welcher Storage-Typ dahintersteht.
Dabei zeigt sich ein grundsätzliches Spannungsfeld: Nextclouds Macht liegt in den Funktionen darüber, also Freigaben, Kollaboration, Mobile Sync. Doch die Basis ist ein Dateisystem, das diese Feature-Dichte tragen muss. Externe Speicher sind oft eine pragmatische Lösung, kein Ideal. Man sollte immer prüfen, ob die angebundenen Netzlaufwerke für den Alltag mit Nextcloud überhaupt geeignet sind. Wenn ein Windows-Share mit tausenden kleinen Dateien über WAN angebunden ist, werden Synchronisationsvorgänge zu einem Abenteuer mit Timeouts.
Objektstorage: Die modernere Speicherwelt
In den letzten Jahren hat sich ein anderes Modell etabliert: Nextcloud direkt auf einem S3-kompatiblen Objektspeicher abzulegen. Das können Amazon Web Services, was sonst, aber auch Self-hosted-Lösungen wie MinIO, Ceph, OpenStack Swift oder SeaweedFS sein. Das Primary Object Storage wird dabei zum Datenverzeichnis selbst – Nextcloud speichert dann alle Dateien als Objekte in einem Bucket, organisiert in einem verborgenen Schema. Die Datenbank bleibt weiterhin lokal und hält die Zuordnung zu Benutzern und Ordnern.
Dafür gibt es gute Gründe: Objektspeicher skalieren nahezu unbegrenzt, bieten von sich aus Redundanz und sind deutlich besser für verteilte Architekturen geeignet. Wenn die Nextcloud-Instanz dann noch hinter einem Load Balancer mit mehreren App-Servern hängt, ist der Objektspeicher der zentrale gemeinsame Datenknoten. Das ist die modernere, aber auch anspruchsvollere Art, den Speicher zu erweitern. In the long run kann sie große Vorteile bringen – gerade bei typischen „Nextcloud Speicher erweitern“-Anfragen, weil das Vergrößern des Buckets meist das Erhöhen eines Limits in der Admin-Konsole ist, ohne dass am Server selbst Schrauben gedreht werden.
Wer Nextcloud mit S3 als Primärspeicher einrichtet, sollte jedoch den deutlichen administrativen Mehraufwand nicht unterschätzen. Der Betrieb einer MinIO- oder Ceph-Umgebung erfordert Fachwissen. Die Performance hängt von der Anbindung und der Geschwindigkeit des Objektspeichers ab. Zwar kann Nextcloud mit S3 umgehen, als sei es ein lokales Dateisystem, aber die Latenz für jeden einzelnen Zugriff liegt immer ein Stück höher. Das macht sich bemerkbar, wenn Services wie die Vorschau-Generierung von Fotos und Videos aufgerufen werden. Eine gute Lösung ist die Kombination mit einem Redis-Cache und einem leistungsfähigen Dateizugriff – aber auch eine clevere Cache-Einstellung in Nextcloud selbst.
Ein interessanter Aspekt ist die Migration zu einem S3-Objektstorage. Sie ist nicht trivial, denn die im lokalen Dateisystem gespeicherten Daten müssen auf die neue Objektstruktur übertragen werden. Nextcloud bringt dafür das Tool occ s3:create-bucket und einige Migrationshilfen mit, aber der Weg ist nicht ohne Stolpersteine. In der Praxis verwenden viele Teams eine der vier folgenden Strategien: Sie nehmen die Datenverzeichnis-Wanderung per rsync zu einem gemounteten S3-Dateisystem wie s3fs, sie synchronisieren einmalig über die Nextcloud-Sync-Clients auf einen neuen Account, sie nutzen ein Migration-Skript auf Datenbankebene oder sie starten in einer Übergangsphase mit zwei Instanzen. Die sauberste Lösung ist, von Beginn an auf einem Objektspeicher zu planen, wenn man langfristig mit vielen Terabytes rechnet.
S3 mit MinIO lokal
MinIO hat sich als schlanker, S3-kompatibler Speicher im Selfhosting-Bereich etabliert. Ein einzelner MinIO-Server mit ein paar Platten lässt sich zügig aufsetzen, und Nextcloud verbindet sich über die Primary-Storage-Konfiguration direkt mit ihm. Die config.php enthält dann Einträge wie 'objectstore' => [ 'class' => 'OC\\Files\\ObjectStore\\S3', 'arguments' => [...] ]. Das wirkt auf den ersten Blick sehr technokratisch, ist aber eine bewährte Variante. Was viele unterschätzen: MinIO benötigt nicht nur Festplatten, sondern auch eine saubere Netzwerkperformance und ein Monitoring. Ein MinIO-Bucket ist kein NAS-Freigabe-Laufwerk, wo man einfach ein Verzeichnis anlegt. Er ist ein Objektspeicher, der über HTTP/REST kommuniziert. Wenn dort die Latenz steigt, hängt die Nextcloud-Synchronisation.
Wer S3 nicht extern, sondern komplett intern nutzt, muss sich um die Erreichbarkeit und die Durchsatzraten kümmern. Abhängig von der Anzahl der Instanzen und der Netzwerkgeschwindigkeit zwischen App-Server und Objektspeicher kann das ein Flaschenhals werden. Das Schöne an MinIO ist allerdings, dass es als einzelner Prozess läuft, eine Konsole mit Grafiken bietet und sich unkompliziert an ein Systemd-Service-Unit hängen lässt. Ein MinIO-Server mit mehreren NVMe-Platten und einem guten 10-Gbit-Netz ist für die meisten Nextcloud-Installationen mehrere Größenordnungen schneller, als ein klassisches NFS. Die Technik hat also durchaus ihre Berechtigung, wenn man über das reine NAS hinausdenken will.
Die Kommandozentrale: occ und config.php
Kein Artikel über das Erweitern des Speichers ohne einen Blick auf die beiden zentralen Stellschrauben. occ ist das Kommandozeilenwerkzeug von Nextcloud, zu erreichen über die PHP-CLI, zum Beispiel mit sudo -u www-data php occ im Verzeichnis der Installation. Es gibt hier eine Reihe von Unterbefehlen, die relevant sind, wenn sich der Speicher ändert. Da wäre zum einen files:scan, um die Dateisystem-Datenbank mit dem tatsächlichen Zustand abzugleichen. Nach einer Speichererweiterung oder einer Migration sollte man das ausführen. Es hilft aber auch, wenn Dateien auf dem Weg von externen Mounts „verschwunden“ sind.
Dann gibt es files:cleanup, um Fehlstellen zu bereinigen, und app:disable, wenn eine App zu viel Platz wegnimmt – zum Beispiel Überbleibsel von Deleted-Files. Besonders wichtig ist, nach einer Migration auch die Einträge der Benutzer zu überprüfen. Mit occ user:list und occ user:info [Benutzer] lässt sich feststellen, welche Daten einem Benutzer zugeordnet sind. Wer eine Quota setzen will, macht das entweder in der Web-Oberfläche oder über die Config-Datei: 'quota_include_external_storage' => false ist eine Option, die festlegt, ob externer Speicher auf das Limit angerechnet wird.
Die Datei config.php ist die zentrale Konfigurationsdatei. Hier stehen die Datenbank-Daten, der Speicherort und viele weitere Werte. Wer sie direkt bearbeitet, muss vorsichtig sein: Syntaxfehler führen oft dazu, dass die gesamte Instanz nicht mehr startet. Ein Backup vor solchen Änderungen ist keine Kür, sondern ein Muss. Neben datadirectory gibt es den Wert default_quota. Welchen Einfluss dieser Wert hat, wird häufig unterschätzt. Ein Benutzer, der seine Sync-Clients auf mehrere Geräte verteilt, braucht unter Umständen mehr Platz, als die Quota erlaubt – und die Synchronisation fällt dann aus. Das Quota-Konzept von Nextcloud ist einigermaßen gut umgesetzt, aber es ist kein Ersatz für eine echte Speicherplanung.
Quotas: Segen und Fluch
Quotas sind das tägliche Brot des Administrators. Sie verhindern das unkontrollierte Wachstum und geben den Benutzern eine klare Grenze. Doch wehe, man setzt sie zu eng. Wenn ein Team Videos synchronisiert, sind fünf Gigabyte pro User schnell aufgebraucht. Und anders als bei Google Drive und Co. gibt es bei Nextcloud kein Aufstocken per Kreditkarte, sondern eine Management-Entscheidung, einen neuen Server oder eine neue Platte. Deshalb ist die Frage, wie viel Speicher man den Benutzern zubilligt, eine Frage, die man nicht im Web-Admin, sondern vorher im Betriebsrat oder mit den Fachabteilungen klären sollte.
Was bei Quotas gerne übersehen wird: Nextcloud zählt bei manchen Dateioperationen anders, als es der Nutzer erwartet. Server-seitige Kopien innerhalb desselben Speicherorts verbrauchen bei S3-Objektspeichern oft nicht doppelt Platz, da der Objektspeicher durch Hardlinks oder deduplizierende Verfahren sparsam umgehen kann. Bei klassischen Dateisystemen führt eine Kopie zu doppeltem Platzverbrauch, auch wenn es sich um dieselben Inhalte handelt. Das ist keine Nextcloud-Besonderheit, aber es ist eine häufige Quelle von Missverständnissen. Wer mit Quotas hantiert, sollte deshalb in der Dokumentation des eigenen Setups festhalten, welche Einstellungen gelten und wie externe Speicher in die Quota einbezogen werden.
Eine Auswertung des tatsächlichen Verbrauchs kann über die Datenbank oder über die Nextcloud-API erfolgen. Es gibt auch kleine Skripte, die per occ auf die Metadaten zugreifen. Was man tun kann, wenn ein Benutzer seine Quota erreicht hat und keine Dateien löschen will, ist eine andere Frage. In der Praxis hilft es, nicht sofort die Grenze zu erhöhen, sondern zunächst die Versionen und Papierkorbgrößen zu prüfen, die oft den größten Anteil ausmachen. In der Administration kann man die Anzahl der Versionen global einschränken: Die Option 'versions_retention_obligation' => 'auto, 30' begrenzt die Speicherung von Dateiversionen. Das entlastet den Speicher, ohne dass der Benutzer aktiv etwas ändern muss.
Cache, Redis und das vernachlässigte Leistungsproblem
Nextcloud funktioniert nicht allein mit einem massiven Speicher. Eine Weile beschäftigt sich jeder mit dem Platz, aber die Performance wird ebenso von Caching, Locking und Datenbank-Operationen bestimmt. Um Verzeichnislisten schnell darzustellen und den Speicher nicht zu strapazieren, empfiehlt sich ein Memory-Cache wie Redis oder APCu. Die genauen Einstellungen finden sich in der Administrationsdokumentation. Wer viel mit großen Dateien arbeitet, kann davon profitieren, das Transactional File Locking auf Redis zu verlagern. Das ist nicht direkt das Thema Speicher, aber es beeinflusst, wie sich Speicher anfühlt.
Wenn Nextcloud langsam wird, greifen viele zuerst zum Platz, nicht zur Cache-Konfiguration. Dabei ist gerade bei S3- und NFS-Setups der Cache oft der entscheidende Faktor. Ein ordentlich konfigurierter Redis-Cache reduziert die Anzahl der Dateisystemzugriffe erheblich. Die Einstellung 'memcache.local', 'memcache.distributed' und 'memcache.locking' sollte von jedem Administrator überprüft werden. Nicht zuletzt gilt: Der Speicher kann noch so groß sein – wenn die Verbindung zwischen Nextcloud und Speichersystem nicht abgestimmt ist, bringt das wenig.
Dabei hilft ein Blick auf ein typisches Szenario: Eine Nextcloud auf einem älteren Server mit einer SATA-Platte, die zu 90 Prozent voll ist. Sobald sie auf 60 Prozent geleert oder durch eine größere SSD ersetzt wird, verdoppelt sich das gefühlte Tempo. Das hat weniger mit Nextcloud zu tun als mit den grundlegenden Gesetzen von Dateisystemen: Je voller die Platte, desto größer die Fragmentierung, desto mehr Aufwand für Schreiboperationen. Das gilt insbesondere für klassische Festplatten. Ein Umzug auf ein neues, halb leeres Dateisystem wirkt oft wie ein Wunder. Wer also den einen Tipp für mehr Leistung sucht: die alten Daten aufräumen und auf eine moderne SSD legen – bevor man über komplexe Objektspeicher-Lösungen nachdenkt. Ist die Platte aber erstmal groß, kann man sich der mentaleren Frage widmen: Wie strukturiere ich den Speicher nachhaltig?
Verschiebungen, Migrationen, Container
Nextcloud läuft heute nicht nur auf nackten Linux-Servern, sondern häufig als Docker-Container oder auf Kubernetes. Das bringt eine neue Perspektive auf den Speicher mit sich. Container sind schnell ersetzbar, aber die Daten müssen persistent außerhalb liegen. Ein Docker-Volume kann problemlos an einen anderen Host verschoben werden, wenn man es als Volume deklariert hat. Das Erweitern eines Docker-Volumes ist dagegen ein klassischer Fall von Abhängigkeiten. Wenn das Volume auf einer Logischen Partition liegt, kann man es mit LVM vergrößern, sofern der Host das zulässt. Wenn es aber ein Verzeichnis im Dateisystem ist, stößt man an die Grenzen der Container-Welt.
In Docker-Compose-Dateien wird häufig ein sogenanntes Named Volume für das Datenverzeichnis verwendet. Ein Beispiel für die Wartung: Um das Volume zu vergrößern, muss man den Container stoppen, das Volume kopieren oder verschieben und die Compose-Datei gegebenenfalls anpassen. Es ist nicht umsonst, dass Nextcloud selbst empfiehlt, bei Docker-Installationen die Datenverzeichnisse auf Host-Pfade zu mounten, also zum Beispiel mit -v /srv/nextcloud/data:/var/www/html/data zu arbeiten. So behält man die Kontrolle und kann mit rsync und den gleichen Methoden wie auf einem klassischen Server arbeiten.
Bei Kubernetes wird der Speicher meist über PersistentVolumes und PersistentVolumeClaims abgebildet. Die Erweiterung erfolgt dann häufig über die Speicherklasse, etwa indem man den Anspruch auf einen größeren Schreib-Block erhöht oder auf eine schnelle SSD-StorageClass umstellt. Das klingt flexibel, ist es in der Praxis aber nur, wenn der zugrunde liegende Storage-Provider das Online-Wachstum unterstützt. Ein klassisches NFS-Volume in Kubernetes kann nicht so ohne weiteres live wachsen, wenn es als ReadWriteMany genutzt wird. Eine Nextcloud auf Kubernetes ist generell funktionsfähig, aber man sollte wissen, dass die offizielle Unterstützung und die Dokumentation für klassische Installationen deutlich besser ausgebaut sind. Wer Speicher erweitern muss, hat es auf einem einzelnen, gut konfigurierten Server meist leichter als in einem Container-Cluster.
Migration zwischen Servern ist eine andere, aber verwandte Geschichte. Wenn ein nextcloud-Speicher von einem alten Server auf einen neuen umziehen soll, bietet sich rsync an. Vorher alles in den Wartungsmodus, dann die Datenbank kopieren, Datenverzeichnis rüberschieben, konfigurieren. Der Clou ist, dass nach dem Verschieben die Datenbank nicht unbedingt geändert werden muss, wenn der relative Pfad gleich bleibt. Ändert sich der Datenverzeichnis-Pfad, ist ein occ files:scan erforderlich. Bei Quota-Änderungen muss man nicht alle Benutzer manuell anpassen, aber es schadet nicht, die Einträge in der Datenbank zu prüfen. Wer sehr viele Dateien hat, kann bei der Migration einen Teil der Datenbank mitnehmen und per occ files:scan den Rest abgleichen; das spart Zeit. Das Verfahren ist in der Nextcloud-Dokumentation beschrieben und funktioniert in den meisten Fällen zuverlässig – wenn man sich Zeit lässt und nicht während der Migration an der Config herumfummelt.
Backup – die unverzichtbare Grundlage
An dieser Stelle sei ein Wort zum Backup gesagt, auch wenn es vom Thema Speichererweiterung scheinbar wegführt. Tatsächlich ist es untrennbar verbunden. Jede Speichermigration, jede Änderung an der Partition, jeder Umzug in einen Objektspeicher erfolgt ohne Risiko nur, wenn zuvor ein verifiziertes Backup erstellt wurde. Wer das nicht macht, spielt russisches Roulette mit den Unternehmensdaten. Und: Ein Backup ist nur so gut wie seine Wiederherstellung. Das gilt insbesondere bei Nextcloud, denn die Dateien allein sind ohne die Datenbank weitgehend nutzlos. Die Datenbank enthält die Ordnung, die Verknüpfungen, die Freigaben und die Benutzerkonten. Ein Backup des Datenverzeichnisses ohne Datenbank ist nur ein Haufen Bytes. Ein Backup der Datenbank ohne das Datenverzeichnis ist ein Verzeichnis von Phantom-Einträgen.
Für die Speicherplanung heißt das: Die Kapazität für Backups muss mit eingeplant werden. Wenn Nextcloud 250 Gigabyte an Nutzerdaten hat, dürfte der Backup-Platzbedarf eher bei dem Doppelten liegen, je nach Aufbewahrungsfristen und Retentionspolitik. Eine Notlösung wie Borg oder restic kann die Datenbank inklusive Datenverzeichnis komprimieren und inkrementell sichern, was den Platzbedarf reduziert. Aber auch dann muss der Zielspeicher existieren und überwacht werden. Es gibt also ein implizites Argument dafür, den Nextcloud-Speicher zu erweitern: nicht nur für die Produktivdaten, sondern für das gesamte Datenökosystem. Eine Platte, die zu 80 Prozent voll ist, lässt kaum noch Platz für Backups oder Snapshots. Btrfs-Snapshots können zwar auf demselben Dateisystem liegen, benötigen aber auch Platz und werden nicht besser, wenn die Platte randvoll ist.
Verschlüsselung: Sicherheit kostet Platz
Ein weiterer Punkt, der bei der Speichererweiterung eine Rolle spielt, ist die Verschlüsselung. Nextcloud bietet eine serverseitige Verschlüsselung an, die die Dateien im Datenverzeichnis transparent verschlüsselt. Diese Funktion sollte mit Bedacht eingesetzt werden: Sie schützt die Daten auf dem Datenträger, aber sie hat in der Vergangenheit für Probleme bei Migrationen gesorgt. Der Schlüssel liegt nämlich nicht nur auf dem Server, sondern in einem speziellen Schlüsselverzeichnis innerhalb des Datenverzeichnisses. Wenn dieses Verzeichnis verloren geht oder bei einem Umzug nicht mitwandert, sind alle Daten unlesbar. Ein Backup des Schlüsselbunds ist daher genauso wichtig wie das Backup der Daten selbst.
Wer serverseitige Verschlüsselung aktiviert, muss mit einem gewissen Overhead an Speicher rechnen – wie hoch der ist, hängt von der Verschlüsselungsmethode ab, in der Regel ein paar Prozent. Die noch wichtigere Frage ist die Performance: Jeder Dateizugriff wird zusätzlich durch Verschlüsselungsroutinen geschickt. Bei einer ohnehin angespannten Speicher- und CPU-Last kann das den Unterschied zwischen flüssigem Betrieb und Ruckeln bedeuten. Es gibt immer wieder Diskussionen in der Nextcloud-Community, ob die serverseitige Verschlüsselung den Aufwand rechtfertigt. Letztlich hängt es vom Bedrohungsmodell ab: Wenn der Server in einem Rechenzentrum steht und der Betreiber nicht in die Daten schauen soll, ist sie eine Option. Wenn die Platten bei einem Hosting-Anbieter aber bereits verschlüsselt sind, bringt die Nextcloud-Verschlüsselung wenig zusätzlichen Sicherheitsgewinn.
Ein Hinweis am Rande: Die Ende-zu-Ende-Verschlüsselung, die in Nextcloud für einzelne Ordner verfügbar ist, funktioniert bekanntermaßen nur auf den Clients und nicht auf dem Server. Sie hat in der Praxis manchmal zu Datenverlusten geführt und sollte erst nach sorgfältigen Tests aktiviert werden. In einem Business-Umfeld ist sie eher ein Sonderfall als die Regel. Von der Speicherplanung her gilt: Verschlüsselte Ordner brauchen etwas mehr Platz, aber nicht signifikant. Wichtiger ist, dass man den Schlüssel-Ordner files_encryption nicht versehentlich von der Migration ausschließt.
Wenn der Platz trotzdem knapp wird: Aufräumen und Optimieren
Es gibt Momente, da ist die Speichererweiterung kurzfristig nicht möglich. Der Server steht im Homeoffice, die bestellte SSD ist noch unterwegs, oder das Budget für das größere NAS wurde gestrichen. Dann hilft nur eines: den vorhandenen Platz besser ausnutzen. Dabei geht es nicht darum, heimlich Daten zu löschen, sondern die Konfiguration zu optimieren. Die Versionsverwaltung und der Papierkorb sind die Haupttäter. In der config.php können Sie die Aufbewahrungsdauer reduzieren: 'trashbin_retention_obligation' => '30, 30' oder auf einen bestimmten Tag wie '7'. Die Versionen können Sie ebenfalls limitieren. Dazu gibt es die Möglichkeit, occ trashbin:cleanup und occ versions:cleanup auszuführen. Das entfernt alte Einträge und gibt teilweise beachtlichen Platz frei.
Was auch häufig übersehen wird: Die Vorschaubilder von Bildern und Videos liegen ebenfalls im Datenverzeichnis. Nextcloud generiert für jede Vorschau mehrere Größen, die im Unterordner appdata_* gespeichert werden. Bei vielen Fotos kann das mehrere Gigabyte ausmachen. Die Vorschauen lassen sich durch einen occ-Befehl neu aufbauen, aber auch gezielt löschen, wenn man wissen will, wie viel Platz sie belegen. Ein bekanntes Skript dazu ist occ preview:generate-all, das die Vorschauen neu erzeugt, doch das Erzeugen ist Arbeit. Ein besserer Ansatz ist es, die Vorschau-Größen in der Konfiguration zu begrenzen, statt sie vollständig zu generieren. Die Optionen enable_previews und preview_max_x bzw. preview_max_y finden sich in der config.php.
Ein weiteres Puzzlestück ist die Aufräumarbeit bei gelöschten Dateien. Bei einer Synchronisation wird eine Datei am Client gelöscht, aber sie wandert in den Papierkorb. Der Benutzer sieht sie nicht mehr, der Admin vielleicht schon. Nach einer Weile kommen dann Fragen: „Kannst du mir die Datei aus dem Papierkorb wiederherstellen?“ – Und genau dafür gibt es den Papierkorb. Wer den Papierkorb aggressiver leert, spart Speicher, schafft aber auch Support-Probleme. Ein Mittelding ist die Begrenzung der Papierkorbgröße: Der Server löscht automatisch, wenn die Aufbewahrungsfrist überschritten wird. Das funktioniert in der Praxis gut, wenn die Einstellungen sauber dokumentiert sind.
Deduplizierung und Kompression: Die Mythen
Immer wieder taucht die Frage auf, ob Nextcloud Dateien komprimiert oder dedupliziert. Die Antwort lautet: Nein, nicht von Haus aus. Nextcloud kopiert ganze Dateien, ohne Inhalte zu kennen. Es gibt keine Datei-Kompression auf Serverebene, keine automatische Erkennung von Duplikaten und keine intelligente Verschiebung. Das ist bewusst so designt, weil die Metadaten sonst ungleich komplexer würden. Es gibt zwar Drittanbieter-Tools, die im Dateisystem deduplizieren – zum Beispiel auf ZFS mit Dedup –, aber das ist ein Speicher-Feature und hat mit Nextcloud nichts zu tun. Der Platzbedarf einer Nextcloud-Instanz ist insofern immer der Platzbedarf der logischen Dateien plus der Overhead für Versionen, Papierkorb und Vorschauen.
Diese Eigenschaft führt zu einer einfachen Konsequenz: Wer viele identische Dateien hat, zum Beispiel dieselbe PDF im Projektordner und in der Freigabe, sollte sie organisatorisch zusammenlegen. Nextcloud kann Links einbetten und geteilte Ordner erlauben mehrere Zugriffe auf denselben Datensatz. Anstatt Dateien zu duplizieren, kann man auf Gruppen-Order oder Freigaben setzen. Das ist nicht nur speicherschonend, sondern auch konsistenter, weil Änderungen nicht an mehreren Stellen vorgenommen werden. Ein Aspekt, der in diesem Zusammenhang oft übersehen wird: Die Web-Oberfläche von Nextcloud erlaubt es nicht, echte Hardlinks zu erzeugen. Die Datenbank referenziert Dateien immer über den dateisystem-basierten Pfad. Wer also Hardlinks oder Reflinks unterhalb der Haube nutzt, kann die Datenmenge reduzieren, muss aber die Konsistenz des Datenverzeichnisses im Auge behalten.
Monitoring: der Administrator als Hellseher
Am Ende beginnt jede gute Speichererweiterung mit einem Blick auf den Zustand der Systeme. Ein Administrator, der nicht weiß, wie schnell der Speicher verbraucht wird, kann nicht sinnvoll planen. Neben den bekannten Tools wie df, du und der Grafana-Sammlung ist die Nextcloud-Statusübersicht hilfreich: Unter Administration – Überblick wird der belegte Speicherplatz für Datenverzeichnis, Datenbank und temporäre Dateien angezeigt. Das ist ein guter Indikator, aber keine detaillierte Analyse. Für präzisere Einblicke in große Verzeichnisse hilft ncdu, das interaktive Festplattenplatz-Analysewerkzeug.
Eine kluge Idee ist es, die Speichernutzung pro Benutzer in regelmässigen Abständen zu erfassen und an einem zentralen Ort auszuwerten. Beispielsweise kann man per Cron-Job occ user:list durchgehen und die Speicherangaben in eine Datei schreiben. Mit einem kleinen Grafana-Dashboard lässt sich so das Wachstum über die Zeit ablesen. Wer das nicht einrichten will, muss zumindest alle paar Wochen manuell nachsehen. Auch das ist besser als nichts. Der Grund für diese Analyse ist nicht Neugierde, sondern die Vorhersage: Wenn der Speicherverbrauch linear wächst, kann man berechnen, wann die Platte voll ist – und ob eine Erweiterung überhaupt noch Sinn ergibt.
Bei der Kapazitätsplanung spielt auch die Anzahl der Dateien eine größere Rolle als die reine Größe. Eine Nextcloud mit 100.000 Dateien und 200 Gigabyte Datenvolumen kann träger sein als eine mit 50.000 Dateien und zwei Terabyte, je nach Dateigröße und Dateisystem. Die Metadaten-Operationen in der Datenbank wachsen mit der Dateianzahl. Ein Wechsel auf ein schnelleres Dateisystem oder einen effizienteren Storage-Backend hilft hier mehr als ein größeres Volume. Daher sollte die Planung immer zweigleisig fahren: Kapazität in Bytes und Kapazität in Inodes oder Datei-Objekten.
Migration Schritt für Schritt – eine kurze Checkliste
Für alle, die jetzt nicht den ganzen Artikel überfliegen, sondern konkret den Speicher erweitern wollen, hier die komprimierte Vorgehensweise. Es ist keine vollständige Anleitung, aber eine Orientierung, an der man sich entlanghangeln kann:
Als erstes die «Ist-Analyse»: Wo liegt das Nextcloud-Datenverzeichnis? Wie groß ist es, wie viel Platz ist noch frei? Läuft die Instanz in einem Docker-Container, auf einem NAS, auf einem einzelnen Server? Danach die Frage des Zielsystems:
Wenn die Partition voll ist und auf dem System noch Platz auf ungenutzten Platten vorhanden ist, ist LVM der erste Kandidat. Ein Logical Volume lässt sich erweitern, das Dateisystem im Anschluss vergrößern. Bei Nextcloud kann das im Live-Betrieb geschehen, zumindest mit ext4. Danach ist der Platz da, ohne dass eine Migration nötig ist.
Wenn das System keine LVM-Unterstützung hat und die Platte physisch getauscht werden muss, ist der Aufwand höher. Der Ablauf lautet: Wartungsmodus an, Daten mit rsync auf ein temporäres Laufwerk kopieren, neue Platte einbauen, Dateisystem anlegen, Daten zurückspielen, Pfad in der config.php kontrollieren, Wartungsmodus aus. Das ist in ein paar Stunden erledigt, verlangt aber volle Konzentration.
Wenn Sie zu einem anderen Speichertyp wechseln, zum Beispiel von einer lokalen Platte zu S3 oder von NFS zu einem schnellen lokalen Dateisystem, ist die Reihenfolge ähnlich. Allerdings kann ein Wechsel des Speichertyps auch Anpassungen an der Datenbank erfordern. In diesem Fall ist es sinnvoll, die offizielle Dokumentation zu Rate zu ziehen und auf einem Testsystem zu proben. Nextcloud unterstützt zwar den Betrieb mit S3 als Primärspeicher, aber ein Wechsel im laufenden Betrieb ist kein Fall für den schnellen Griff in die Kiste.
Nach der Migration immer: occ maintenance:mode --off, occ files:scan --all, Logdateien prüfen und ein Backup der neuen Konfiguration anfertigen. Gerade das letzte Backup ist wichtig, denn niemand möchte nach einer mehrstündigen Migration feststellen, dass die alte Konfiguration überschrieben wurde und der Zugriff nicht mehr funktioniert. Diese Fälle gibt es häufiger, als man denkt.
Nextcloud als Plattform: Speicher ist nur ein Teil
Wer viel Zeit mit Nextcloud verbringt, lernt schnell: Die eigentliche Kunst liegt nicht in der Installation, sondern in der Betreuung über Jahre hinweg. Speicher ist eine Ressource, die man in einem gut gepflegten System fast wie etwas Selbstverständliches behandelt. Man wirft einen Blick auf die Anzeige, legt eine neue Platte ein oder erweitert einen Bucket, und das System läuft weiter. Aber wenn die Speicherverwaltung nicht durchdacht ist, wird sie zum Dauerbrenner im Ticketsystem. Der Admin ist dann nicht mehr Architekt, sondern Feuerwehrmann.
Die Wahl, wie der Speicher erweitert wird, ist also auch eine Wahl über künftige Flexibilität. Ein Server mit LVM und ausreichend Platz im Gehäuse lässt sich problemlos skalieren. Ein NAS mit SMB-Anbindung ist eine schnelle Lösung für den Anfang, aber sie wird zum Flaschenhals, wenn tausende kleine Dateien synchronisiert werden. Ein Objektspeicher ist die robusteste Lösung, verlangt aber mehr Know-how und ein anderes Betriebsmodell. Und schließlich gibt es noch die Sache mit der Cloud: Nextcloud kann man extern bei Dienstleistern betreiben, die selbst Speicher vorhalten, oder man mietet bei einem Anbieter ein S3-Bucket. Das verschiebt das Speicherproblem in die Verantwortung des Providers – kann aber im Zweifel teuer werden, wenn das Datenvolumen unbegrenzt wächst.
Ein weiterer Punkt, der in der Praxis oft zu Diskussionen führt, ist die Erreichbarkeit der Daten. Wer seinen Speicher auf einem NAS zu Hause hat und von unterwegs darauf zugreift, der merkt schnell, dass die Upload-Geschwindigkeit des eigenen Internetanschlusses der Flaschenhals ist. Bei Nextcloud-Instanzen in Rechenzentren ist das weniger ein Problem, aber auch dort gilt: Speicher ist nicht gleich Speicher. Ein günstiges S3-Archiv ist gut für Backup-Daten, aber weniger gut, wenn Nextcloud täglich große Videodateien über das Netz streamen soll. Die Speicherklassifizierung ist eine wichtiges Thema: heiße Daten auf SSDs, lauwarme Daten auf klassischen Festplatten, kalte Daten im Archivspeicher. Nextcloud kann das nicht vollständig selbst abbilden, aber mit externen Speichern und entsprechenden Regeln lässt sich vieles erreichen.
Wie sieht eine sinnvolle Kombination aus? Ein kleiner Server mit einer schnellen NVMe-Platte für das Nextcloud-Datenverzeichnis, ein zweiter Server mit einer großen HDD für Backups und langfristige Archive, und optional eine S3-Storage-Class für verschlüsselte Offsite-Backups. Eine solche Konstellation bietet Performance und Sicherheit, ohne dass ein einzelnes System zum Single Point of Failure wird. Die Konfiguration dieser Speicherpfade ist in Nextcloud gut dokumentiert – von der externen Speicher-App bis zum Primary-Objectstorage. Es erfordert nur die Bereitschaft, sich einmal grundlegend mit dem Thema zu beschäftigen.
Ausblick: Wohin geht die Reise?
Nextcloud entwickelt sich stetig weiter. In den letzten Jahren kamen viele Funktionen hinzu, die den Speicher betreffen: Gruppenordner mit eingebauten Quoten, der S3-Objectstore wurde verbessert, und die Administration der Speicherorte wurde übersichtlicher. Dennoch bleibt die Aufgabe des Administrators die gleiche wie bei klassischen Systemen: Er muss den Speicher überwachen, vorausschauend planen und die richtige Balance zwischen Kosten, Performance und Datenhaltung finden. Daran ändert auch die beste Cloud-Plattform nichts.
Spannend wird die zukünftige Entwicklung von globalen Speicher-Clustern und der Integration mit dezentralen Systemen. Wer weiß, vielleicht sind die klassischen Storage-Silos bald Vergangenheit. Bis dahin gilt für Nextcloud-Betreiber: Nicht nur den aktuellen Speicherbedarf sehen, sondern die Trends erkennen. Das Wachstum der Datenmenge in Unternehmen ist ungebremst, und die Erwartungen der Benutzer steigen ebenfalls. Der Speicher ist dabei keine statische Größe, sondern ein dynamischer Bestandteil der Infrastruktur. Er ist vergleichbar mit dem Fundament eines Hauses: Man kann es nicht einfach nachträglich verschieben, ohne dass das Gebäude Risse bekommt.
Deshalb die vielleicht wichtigste Erkenntnis aus diesem Artikel: Speichererweiterung beginnt nicht erst, wenn die Platte voll ist, sondern bei der Planung der Systemarchitektur. Wer die Weichen richtig stellt – mit skalierbaren Dateisystemen, durchdachten Konfigurationsdateien und einem Monitoring, das nicht nur den Raum auf der Platte, sondern auch das Dateiwachstum im Auge behält –, der wird die nächsten Jahre entspannt überstehen. Und der nächste Anruf im Support lautet dann nicht: „Der Speicher ist voll“, sondern vielleicht: „Wie viel Platz haben wir eigentlich noch?“ – und das ist eine viel bessere Frage.
Also, packen Sie es an: Schauen Sie nach df -h, df -i, prüfen Sie die Größe des Datenverzeichnisses, werfen Sie einen Blick auf die config.php, und überlegen Sie, welche Strategie zu Ihrer Infrastruktur passt. Eine kleine Investition von ein paar Stunden spart später Tage – und das ist bei Nextcloud-Speicher genauso wie bei jeder anderen IT-Disziplin. Wenn dann alles läuft, können Sie die Ruhe genießen, die eine gut geölte Speicher-Architektur mit sich bringt. Zumindest, bis der nächste Hype um eine datenintensive Anwendung die Infrastruktur wieder auf die Probe stellt. Aber das ist eine andere Geschichte.