Wenn die Grenzen nicht sichtbar sind: Nextcloud, Speicherlimits und die Kunst des guten Managements
Nextcloud hat sich in den vergangenen Jahren als eine der vielseitigsten Plattformen für selbstverwaltete Cloud-Dienste etabliert. Man installiert sie, richtet ein paar Benutzer ein, legt ein oder zwei Ordner an – und schon scheint alles rundzulaufen. Doch dann kommt der Moment, an dem eine Datei nicht hochgeladen werden kann, ein Synchronisationsjob fehlschlägt oder der Speicherplatz im Dashboard plötzlich anders aussieht als erwartet. Oft liegt es nicht an der Hardware, nicht am Netzwerk, sondern an unsichtbaren Grenzen: den Speicherlimits.
Diese Limits sind ein oft unterschätztes Thema. Viele Administratoren gehen davon aus, dass die Systemressourcen den einzigen Engpass darstellen. Doch Nextcloud, so zugänglich es auf den ersten Blick wirkt, besitzt eine komplexe, mehrschichtige Architektur. In der Praxis zeigt sich: Die Begrenzungen sitzen tief – in der Datenbank, in der PHP-Konfiguration, in der Art, wie das Dateisystem selbst partitioniert ist. Und wer sich nicht rechtzeitig damit auseinandersetzt, steht früher oder später vor einem Problem, das sich nicht mit einem simplen „Festplatte vergrößern“ lösen lässt.
Interessant ist, dass viele Anwender Nextcloud zunächst so nutzen wie einen öffentlichen Cloud-Dienst: Einfach Dateien reinziehen, Ordner teilen, mit Kollegen oder der Familie zusammenarbeiten. Die Limits, die man bei Dropbox oder Google Drive gewohnt ist – also Kontingente pro Benutzer, maximale Dateigrößen – sind dort gesetzt und werden nicht hinterfragt. Bei Nextcloud sind diese Grenzen jedoch veränderbar, aber auch fehlkonfigurierbar. Und genau da liegt die Krux: Das System verzeiht eine aggressive Nutzung nicht automatisch.
Die unsichtbaren Hürden: Wo Nextcloud Speicherlimits setzt
Beginnen wir mit den offensichtlichen Limits. Jeder Administrator kennt das Feld in der Nextcloud-Konfiguration: 'max_filesize' => 0. Aber das ist nur die Spitze des Eisbergs. Tatsächlich wird die maximale Dateigröße, die ein Benutzer hochladen kann, durch eine Kaskade von Parametern bestimmt:
PHP-Konfiguration: Die upload_max_filesize und post_max_size in der php.ini sind die ersten Hürden. Standardmäßig oft auf 2, 8 oder 16 Megabyte gesetzt – für moderne Arbeitsdateien ein Witz. Wer sein System nicht anpasst, wird schnell feststellen, dass selbst eine 50-MB-Präsentation scheitert. Aber selbst wenn man diese Werte auf 512 MB oder 2 GB erhöht, stößt man an die nächste Grenze: die Memory-Limits. memory_limit in PHP bestimmt, wie viel Arbeitsspeicher ein Prozess maximal verwenden darf. Bei großen Dateien, insbesondere wenn Verschlüsselung oder Vorschau-Generierung aktiv sind, kann dies schnell zum Problem werden.
Nextcloud-interne Limits: In der Datei config.php gibt es 'max_filesize', aber auch 'max_chunk_size' für den Chunk-Upload, sowie die Einstellung 'upload_max_filesize' im Systemkonfigurationsbereich über die Oberfläche. Letzteres ist eigentlich ein Proxy für die PHP-Werte, wird aber oft übersehen. Hinzu kommt: Nextcloud hat für die Datenbank einen eigenen Mechanismus – die sogenannte filecache-Tabelle. Jede Datei, jeder Ordner wird dort in Zeilen abgelegt. Die Größe dieser Tabelle wächst nichtlinear mit der Anzahl der Dateien. Bei mehreren Millionen Dateien – etwa bei einem großen Unternehmen mit vielen kleinen E-Mails oder Logdateien – kann die Performance dieser Tabelle drastisch einbrechen. Das ist weniger ein reines Speicherlimit, sondern ein Performancelimit, das sich aber wie eines anfühlt: Der Upload wird langsamer, die Suche stockt, die Sync-Apps brechen ab.
Dateisystemgrenzen: Nextcloud arbeitet mit dem zugrunde liegenden Betriebssystem zusammen. Hat man eine Partition mit einem klassischen Dateisystem wie ext4, gibt es eine maximale Anzahl von Inodes. Das ist die Zahl der möglichen Dateien und Verzeichnisse. Wer viele kleine Dateien speichert – etwa ein E-Mail-Archiv mit tausend 1-KB-Dateien – kann diese Grenze schneller erreichen als die reine Speicherkapazität. Ein ZFS oder Btrfs mit Copy-on-Write kann hier helfen, aber auch andere Eigenheiten mitbringen. Wer also auf einem VPS mit 100 GB Speicher meint, er könne unbegrenzt viele Dateien anlegen, der irrt. Das Limit sitzt im Dateisystem, nicht im Speicherplatz.
Nicht zuletzt gibt es das Datenbank-Backend. Nextcloud verwendet standardmäßig SQLite für kleine Installationen, wird aber für produktive Umgebungen auf PostgreSQL oder MariaDB umsteigen. Die Limits dort: maximale Tabellengröße, maximale Paketgröße für Queries, und die Tiefe von Transaktionen. Bei MariaDB kann zum Beispiel die max_allowed_packet zu einem Problem werden, wenn ein Upload mit vielen Metadaten oder Kommentaren verbunden ist. Oder die innodb_log_file_size – zu klein gewählt, schlägt der Import großer Dateien fehl.
Kurz: Die Speicherlimits bei Nextcloud sind ein mehrdimensionales Problem. Ein Administrator, der nur die Festplattenauslastung im Auge hat, übersieht die entscheidenden Flaschenhälse. Und genau das führt zu den typischen Frustrationserlebnissen, die in Foren und Community-Chats beschrieben werden: „Ich habe 10 TB Speicherplatz, aber kann keine 200-MB-Datei hochladen. Warum?“
Von der Konfiguration zur Praxis: Ein realistischer Blick auf das Limit-Handling
Die typische Reaktion auf solche Fragen: „Erhöh halt die PHP-Werte“ – was in vielen Fällen auch richtig ist. Aber die Praxis ist detailreicher. Ich habe selbst über die Jahre etliche Nextcloud-Instanzen betreut – von Ein-Personen-Setups mit einem Raspberry Pi bis hin zu Multi-PB-Clustern in Rechenzentren. Und immer wieder zeigte sich: Die Grenzen, die man sieht, sind selten die, die tatsächlich existieren. Ein schönes Beispiel: Ein Unternehmen speicherte CAD-Dateien mit einigen hundert Megabyte. Die Uploads funktionierten problemlos, aber die Synchronisation auf den Clients dauerte ewig. Der Grund war nicht die Dateigröße, sondern die Anzahl der Versionen. Nextcloud ist so konfiguriert, dass es standardmäßig 50 Versionen einer Datei aufbewahrt. Das bedeutet, dass bei jeder Bearbeitung einer großen CAD-Datei 50 Kopien angelegt werden – und der Client muss bei jeder Synchronisation die Deltas berechnen. Das Limit ist hier nicht die Dateigröße, sondern die Versionierung, die als Speicherpuffer wirkt. Ein Anpassen der versions_retention_obligation auf 5 oder 10 Versionen hätte das Problem sofort gelöst, ohne dass ein Byte mehr Speicher nötig gewesen wäre.
Ein weiteres Beispiel: Im Bildungssektor nutzt ein Gymnasium Nextcloud für die Zusammenarbeit von Schülern und Lehrern. Täglich werden tausende PDFs, Fotos und kleine Präsentationen hochgeladen. Irgendwann begann die Instanz zu ruckeln. Die Ursache: Die trashbin – der Papierkorb – war auf 90 Tage eingestellt. Bei einer hohen Änderungsrate sammelt sich dort schnell enormer Müll an. Das Limit, das hier griff, war nicht der Speicherplatz an sich, sondern die Menge der Dateien in der Papierkorb-Datenstruktur. Die Nextcloud-Oberfläche wurde träge, weil die Abfrage der gelöschten Dateien immer länger dauerte. Nach dem Verkürzen der Aufbewahrungsdauer auf 14 Tage und einer gelegentlichen Bereinigung über das OCC-Kommando trashbin:cleanup war die Instanz wieder flott.
Das zeigt: Speicherlimits sind oft weniger eine Frage der Kapazität als eine Frage der Struktur. Nextcloud arbeitet mit einer relationalen Datenbank zusammen, die bei vielen Objekten ineffizient wird. Administratoren sollten daher nicht nur in Gigabyte denken, sondern in der Anzahl der Objekte – Dateien, Ordner, Versionen, geteilte Links, Kommentare. Je mehr Objekte, desto mehr Datenbankzugriffe, desto mehr Index-Größe, desto mehr Cache-Druck. Ein guter Richtwert: Mehr als eine Million Dateien in einer einzigen Nextcloud-Instanz ohne spezielle Optimierung bedeuten oft Ärger. Mit entsprechenden Maßnahmen – etwa Redis als Transactional File Locking, Primary-Secondary-Datenbank-Setups oder Partitionierung des Speichers – kommt man auch in den zweistelligen Millionenbereich. Aber das ist keine Standardkonfiguration mehr.
Die Kunst der Limit-Setzung: Was der Administrator wirklich wissen muss
Ich möchte hier keine trockene Liste von Konfigurationsparametern abliefern, sondern eher eine Herangehensweise skizzieren. Wer Nextcloud in einer ernsthaften Umgebung betreibt, sollte sich folgende Fragen stellen:
1. Was ist das typische Dateiprofil meiner Nutzer? Handelt es sich um große Einzeldateien (Videos, CAD, RAW-Fotos) oder um viele kleine (E-Mails, Logs, Code)? Daraus ergibt sich, ob die PHP-Speicherlimits oder die Inode-Limits im Dateisystem der Engpass sein werden. Für große Dateien braucht man hohe upload_max_filesize und post_max_size – und man sollte die Chunk-Uploads aktivieren. Nextcloud teilt dann die Datei in Blöcke, was die Auslastung des PHP-Prozesses reduziert. Dafür muss man den 'chunked_transfer_encoding' korrekt setzen und die Zeitlimits in PHP anpassen (max_execution_time, max_input_time). Für viele kleine Dateien liegt der Fokus eher auf der Datenbankoptimierung: Indexierung, Write-Ahead-Log-Größe, und ggf. der Einsatz von Redis in einer Konfiguration, die den Metadaten-Cache entlastet.
2. Wie gehe ich mit der Datenbank um? Für eine produktive Nextcloud-Instanz ist SQLite nicht zu empfehlen, sobald mehr als ein paar Dutzend Benutzer oder einige tausend Dateien im Spiel sind. MariaDB oder PostgreSQL sind die richtige Wahl. Aber auch hier lauern Limits. Die Standardwerte vieler Managed-Hosting-Umgebungen sind auf kleine Webseiten ausgelegt, nicht auf die hohe Schreiblast einer Filesharing-Plattform. Insbesondere die max_allowed_packet sollte auf mindestens 64 MB gesetzt werden. Bei großen Dateien, die mit Metadaten (Kommentare, Tags, Aktivitäten) versehen werden, können die Pakete sonst zu groß sein. Auch die innodb_log_file_size sollte nicht unterschätzt werden. Ich habe Instanzen gesehen, bei denen die Log-Datei 48 MB groß war – bei viel Schreibbetrieb führt das zu enormen I/O-Wartezeiten, weil der Log ständig flushen muss. Ein Wert von 1 bis 2 GB ist in vielen Fällen sinnvoll.
3. Welche Rolle spielt die Partitionierung? Nextcloud speichert die eigentlichen Dateien im data-Verzeichnis. Aber auch der files_external-Mechanismus erlaubt die Einbindung externer Speicher – S3, SFTP, WebDAV. Wer seine Speicherlimits intelligent verwalten will, kann verschiedene Storage-Backends kombinieren. Ein typisches Setup: SSDs für den Cache der aktuellen Dateien, günstige HDDs oder S3-kompatible Speicher für kalte Daten. Solche Konfigurationen erfordern zwar mehr Aufwand, heben aber die praktischen Limits der Hardware auf eine neue Stufe. Allerdings: Auch hier gibt es Grenzen. S3-Buckets haben ihre eigenen Limits – maximale Objektanzahl pro Bucket, maximale Lese-/Schreiboperationen pro Sekunde. Wer Nextcloud in einer großen Umgebung betreibt, sollte diese Limits nicht ignorieren.
4. Wie verwalte ich Limits pro Benutzer und pro Gruppe? Nextcloud erlaubt dies über die Gruppen-Richtlinien – entweder über die Oberfläche (unter Verwaltung -> Benutzer) oder über die OCC-Kommandozeile. Man kann jedem Benutzer ein festes Quota zuweisen: 5 GB, 50 GB, unendlich. Letzteres ist gefährlich, denn „unendlich“ gibt es nicht. Wenn ein Benutzer beginnt, Terrabyte an Daten hochzuladen, kann das die Instanz schnell in die Knie zwingen. Ich empfehle, Quotas so zu setzen, dass sie mindestens den tatsächlichen Bedarf abdecken, aber eine harte Obergrenze bilden. Einmal musste ich in einem Unternehmen erleben, wie ein Mitarbeiter versehentlich einen Sync-Ordner mit 2 TB an Backups in Nextcloud eingebunden hatte. Da das Quota auf „unendlich“ gesetzt war, füllte er die Partition in wenigen Stunden und brachte die gesamte Instanz zum Absturz. Seitdem setze ich standardmäßig Quotas – auch wenn sie großzügig bemessen sind.
Jenseits der Standardkonfiguration: Nextcloud Speicherlimits in der Enterprise-Welt
In großen Organisationen kommen noch weitere Faktoren ins Spiel: Compliance, Retention, Verschlüsselung, globale Verteilung. hier sind die Limits von besonderer Bedeutung. Ein Beispiel: Ein Finanzdienstleister speichert nach gesetzlicher Vorschrift alle Unterlagen für zehn Jahre. Wenn die Nextcloud-Instanz eine automatisierte Löschung von Versionen nach Ablauf einer Frist vornimmt, muss dies exakt konfiguriert sein. Sonst werden entweder zu viele Versionen gelöscht (Rechtsrisiko) oder zu viele behalten (Speicherplatzexplosion). Nextcloud bietet dazu die versions_retention_obligation mit zwei Parametern: einer für die minimale Aufbewahrungsdauer (z. B. 30 Tage) und einer für die maximale Anzahl von Versionen. Wer das nicht richtig setzt, gerät in Schwierigkeiten.
Ein interessanter Aspekt ist auch die serverseitige Verschlüsselung. Sie erhöht den Speicherverbrauch pro Datei um einen Header und einige Metadaten – marginal, aber bei Milliarden von Dateien summiert sich das. Zudem verschlüsselte Dateien müssen bei Zugriff im Speicher decodiert werden, was die Memory-Limits von PHP noch wichtiger macht. Wer End-to-End-Verschlüsselung nutzt, muss bedenken, dass die Server keinen Zugriff auf die Inhalte haben – das bedeutet, dass auch die Suche im Dateiinhalt deaktiviert ist. Das ist kein Speicherlimit im engeren Sinne, aber ein funktionales Limit, das die Nutzung beeinflusst.
In globalen Setups mit mehreren Rechenzentren (Geo-Replication) kommt noch die Netzwerkbandbreite als unsichtbare Grenze hinzu. Nextcloud kann Dateien über Schnittstellen wie S3 oder WebDAV auf verteilte Speicher auslagern. Die Limits sind hier nicht in der Nextcloud-Konfiguration festgelegt, sondern in der Infrastruktur – etwa die Antwortzeiten der Objektspeicher. Wenn die Latenz zwischen Rechenzentren hoch ist, kann der Abruf einer Datei länger als die erlaubte HTTP-Timeout-Zeit dauern. Auch das kann sich wie ein Speicherlimit anfühlen: Die Datei existiert, aber sie kommt nicht an. Abhilfe schaffen CDN-Integrationen oder regionale Caches, aber die müssen konfiguriert und betrieben werden.
Fehlertoleranz und katastrophale Szenarien: Wenn Limits zu Ausfällen führen
Es gibt wenig, was Administratoren mehr fürchten als unerwartete Speicherlimits, die sich in katastrophalen Ausfällen äußern. Ein realer Fall: Ein kleines Unternehmen mit einer Nextcloud-Instanz auf einem günstigen Shared-Hosting. Der Anbieter hatte die PHP-Werte nicht angepasst, aber der Kunde wusste das nicht. Als ein Mitarbeiter ein 1-GB-Video hochladen wollte, brach der Upload ab. Der Mitarbeiter versuchte es mehrfach, dann gab er auf und schrieb eine E-Mail an den Admin. Der Admin, mit wenig Zeit, erhöhte die Werte in der php.ini auf 2 GB und startete den Webserver neu. Danach funktionierte der Upload. Aber weil der Memory-Limit immer noch zu niedrig war (128 MB), erzeugte Nextcloud bei der Verschlüsselung des Videos einen Fehler und hinterließ eine korrupte Datei im Dateisystem. Eine Woche später stellte man fest, dass die Synchronisation für diese Datei nicht mehr richtig funktionierte, und der Schaden war größer als nötig.
Das hätte vermieden werden können, wenn man nicht nur die offensichtlichen Limits erhöht, sondern auch die Memory- und Timeout-Werte überprüft hätte. Oder besser: Wenn man den Chunk-Upload aktiviert hätte, sodass die Datei in Blöcken von z. B. 10 MB hochgeladen wird. Nextcloud baut diese Blöcke dann serverseitig zusammen. Das reduziert den Speicherbedarf pro Prozess und verringert die Fehleranfälligkeit. Das OCC-Kommando files:scan kann dann fehlende Teile erkennen. Aber das setzt voraus, dass die Admins wissen, dass es diese Konzepte gibt.
Ein anderer Fall: Ein Forschungsinstitut hatte eine Nextcloud-Instanz mit 200 Benutzern. Die Versionierung war auf 50 Versionen gesetzt. Irgendwann war die Partition voll. Der Admin löschte manuell einige alte Dateien, aber die Versionen blieben in der Datenbank erhalten. Die Festplatte zeigte wieder freien Speicher, aber die Datenbanktabelle war aufgebläht. Die Folge: Die Suche wurde extrem langsam, das Dashboard brauchte Minuten zum Laden. Der Admin dachte, die Datenbank sei defekt, und restaurierte ein Backup. Dabei gingen aktuelle Versionen verloren. Das wäre vermeidbar gewesen, wenn man regelmäßig die versions:cleanup-Routine über OCC ausgeführt hätte. Oder wenn man die versions_retention_obligation so gesetzt hätte, dass sie automatisch Platz schafft.
Praktische Tipps für den Umgang mit Nextcloud-Speicherlimits
Lassen Sie mich einige Erfahrungen teilen, die sich in der Praxis bewährt haben – nicht als Dogmen, sondern als Anhaltspunkte, die man an die eigene Umgebung anpassen kann.
1. Monitoring der Metriken – nicht nur der Festplatte. Ein guter Administrator überwacht nicht nur den freien Speicherplatz, sondern auch die Anzahl der Dateien, die Größe der wichtigsten Datenbanktabellen und die Auslastung der PHP-Arbeitsspeicher. Tools wie occ db:list und die Nextcloud-integrierte Log-Analyse helfen dabei. Wer ein externes Monitoring wie Grafana aufbaut, sollte die Anzahl der Objekte im Filesystem als Metrik aufnehmen – es sind oft die kleinen Dateien, die die Datenbank zum Kollabieren bringen.
2. Boundary-Conditions testen. Bevor eine Instanz in die Produktion geht, sollte man gezielt Grenzfälle testen: Upload einer Datei knapp unterhalb des erwarteten Limits, Upload tausender kleiner Dateien, Upload mit aktivierter Versionierung. Dabei kann man die Limits in der Konfiguration bewusst herunterdrehen, um zu sehen, ob die Fehlermeldungen sinnvoll sind. Nextcloud gibt teils kryptische Hinweise. Oft genügt ein Blick in die Logs (nextcloud.log), um die Ursache zu finden.
3. Wissen, wann man externe Speicher einbindet. Nextcloud bietet die Möglichkeit, über files_external Objektspeicher wie S3, GCS oder OpenStack Swift einzubinden. Das kann die Limits des lokalen Speichers elegant umgehen – insbesondere die Inode-Werte. S3 hat seine eigenen Grenzen, aber die sind in der Regel höher und skalieren besser. Allerdings kostet ein solcher Speicher Geld und erfordert eine sorgfältige Planung der Bucket-Konfiguration und der Zugriffsrechte. Auch die Latenz ist ein Thema. In Rechenzentren mit schneller Anbindung ist das kaum spürbar, bei Nutzern mit schlechtem Internet kann es zu langen Ladezeiten kommen.
4. Regelmäßige Wartung über OCC. Nextcloud hat eine Reihe von Wartungsbefehlen, die man in Cron-Jobs einbinden sollte. Dazu gehören files:scan (Konsistenzprüfung des Dateisystems), trashbin:cleanup (Papierkorb leeren), versions:cleanup (alte Versionen entfernen), activity:cleanup (alte Aktivitäten entfernen). Diese Routinen verhindern, dass die Datenbank ausufert. Die Standard-Cron-Konfiguration von Nextcloud führt diese nicht regelmäßig aus – das muss der Admin selbst einrichten.
5. Die Kunst der Skalierung. Irgendwann erreicht jede Instanz einen Punkt, an dem die vertikale Skalierung (größere Maschine) nicht mehr ausreicht. Dann helfen nur horizontale Ansätze: Data-Sharding, Objektspeicher-Backends, Lastverteilung für mehrere Nextcloud-Instanzen mit gemeinsamem Datenbankserver. Nextcloud selbst bietet keine native Multi-Master-Replikation, aber man kann mit den vorhandenen Mitteln (z. B. mehrere Storage-Backends, Lastausgleich über DNS) funktionale Cluster aufbauen. Die Limits sind dann nicht mehr in der Software selbst, sondern in der Architektur. Das ist ein Thema für sich.
Ausblick: Wohin entwickelt sich das Limit-Management bei Nextcloud?
Die Entwickler von Nextcloud sind sich der Probleme bewusst. In den letzten Versionen gab es Verbesserungen: Der Chunk-Upload wurde robuster, die OCC-Wartungsbefehle wurden erweitert, die Integration mit Redis wurde besser. Auch die Datenbank-Performance hat sich mit Version 28 und 29 merklich verbessert – durch Überarbeitung der Queries und bessere Index-Strukturen. Aber eines bleibt: Nextcloud ist eine Plattform, die hohe Flexibilität bietet, aber auch tiefe Kenntnisse verlangt. Die Limits, die ich hier beschrieben habe, sind keine Fehler der Software – sie sind inhärente Eigenschaften einer komplexen Datenhaltung.
Interessant ist die Entwicklung hin zu sogenannten „Secondary Storage“-Lösungen wie S3 und die wachsende Unterstützung für Dateisysteme wie ZFS oder Btrfs, die mit vielen kleinen Dateien besser umgehen können. Auch der Trend zu AI-gestützten Analysen (Nextcloud hat das „Machine Learning“-Modul für Dateierkennung) wird die Anforderungen an Speicherlimits verändern. Wenn jeder Scan aller Dateien zu einer intensiven Datenbanknutzung führt, müssen die Limits neu justiert werden. Ich erwarte, dass künftige Versionen noch bessere Tools mitbringen, um solche Limits automatisiert zu erkennen und zu melden – vielleicht sogar eine Art „Capacity Planner“ im Dashboard.
Doch bis dahin gilt: Der Administrator bleibt gefragt. Wer sich die Zeit nimmt, die Speicherlimits seiner Nextcloud-Instanz systematisch zu durchdenken, wird nicht nur Überraschungen vermeiden, sondern auch eine reibungslosere Nutzung ermöglichen. Und vielleicht ist es genau diese Tiefe, die Nextcloud von den einfachen Cloud-Diensten unterscheidet: Die Möglichkeit, jedes Limit zu verstehen und zu verändern – wenn man weiß, wo es sitzt.
In einer Zeit, in der Datenmengen exponentiell wachsen, wird die Kunst des Limit-Managements zu einer Kernkompetenz. Wer nur „mehr Speicher“ bestellt, hat noch lange nicht die Grenzen beseitigt. Wer sich aber mit den feinen Details der Nextcloud-Architektur anfreundet, der schafft eine Umgebung, die selbst unter Druck stabil bleibt. Und das ist letztlich das Ziel jeder soliden IT-Infrastruktur.