Es ist ein vertrautes Bild in vielen IT-Abteilungen: Die Nextcloud-Instanz, einst als überschaubares Filesharing-Projekt gestartet, wächst und wächst. Plötzlich ist sie die zentrale Lebensader für Kollaboration geworden – und die Festplatten-LED blinkt ununterbrochen. Der verfügbare Speicher schmilzt dahin wie Schnee in der Frühlingssonne. An diesem Punkt stehen Administratoren vor einer grundlegenden Entscheidung: Wie erweitert man den Nextcloud-Speicher, ohne die Stabilität zu gefährden und ohne das Budget zu sprengen?

Dabei zeigt sich: Die Erweiterung des Speichers ist bei Nextcloud selten eine simple Frage eines größeren Laufwerks. Sie ist vielmehr eine Architekturfrage, die tief in die Schichten der Anwendung, der Datenbank und des darunterliegenden Dateisystems reicht. Eine falsche Entscheidung hier kann Performance-Einbrüche, Dateninkonsistenzen oder langfristige Skalierungsprobleme nach sich ziehen.

Grundlagen: Wie Nextcloud Speicher verwaltet

Bevor man an die Erweiterung geht, muss man verstehen, wie Nextcloud überhaupt mit Speicher umgeht. Nextcloud abstrahiert den physischen Speicher durch sein Storage Abstraction Layer. Dieses Konzept erlaubt es, verschiedene Speicherbackends nahtlos einzubinden – von der lokalen Festplatte über Netzwerkspeicher (NAS) bis hin zu Objektspeichern wie AWS S3 oder Wasabi.

Jeder Nutzer, jede Gruppe kann auf einen oder mehrere dieser sogenannten Speicher-Mounts zugreifen. Die Konfiguration erfolgt zentral in der config.php oder bequem über die Administrationsoberfläche unter „Externe Speicher“. Ein interessanter Aspekt ist, dass Nextcloud dabei zwischen primärem und sekundärem Speicher unterscheidet. Der primäre Speicher ist typischerweise das lokale Dateisystem, auf dem die Nextcloud-Instanz selbst läuft. Hier liegen nicht nur Nutzerdaten, sondern auch die Anwendungsdateien, die Datenbank und Konfiguration.

Die Anatomie des Datenwachstums

Wo geht der ganze Platz eigentlich hin? Neben den offensichtlichen Datei-Uploads fressen oft weniger beachtete Bereiche unerwartet viel Speicher:

• Versionierung: Jede Änderung an einer Datei erzeugt eine neue Version. Bei häufigen Änderungen an großen Dateien kann der Speicherbedarf dadurch schnell explodieren.
• Papierkorb: Gelöschte Dateien verweilen standardmäßig 30 Tage im Papierkorb – bequem für Nutzer, aber ein Speicherfresser.
• App-Daten: Apps wie Talk, Maps oder die Office-Integration legen ihre eigenen, oft umfangreichen Daten ab.
• Datenbank-Fragmentation: Die MySQL- oder PostgreSQL-Datenbank kann über die Zeit ineffizient werden und mehr Platz beanspruchen als nötig.
• Cache und temporäre Dateien: Besonders bei aktivierten Previews (Vorschaubilder) türmen sich temporäre Daten auf.

Lokale Erweiterung: Der klassische Ansatz

Die naheliegendste Lösung ist das Hinzufügen weiterer lokaler Festplatten. Für On-Premise-Installationen bedeutet das in der Regel:

1. Einfache Partitionierung

Bei virtuellen Maschinen erweitert man einfach die virtuelle Festplatte und vergrößert die Partition. Tools wie growpart unter Linux und resize2fs für ext4-Dateisysteme machen das vergleichsweise einfach. Allerdings: Diese Methode stößt schnell an Grenzen. Irgendwann ist die maximale Größe einer Partition erreicht, oder die Performance leidet unter der schieren Datenmenge auf einem einzelnen Dateisystem.

2. LVM – Der flexible Ansatz

Für mehr Flexibilität setzen erfahrene Administratoren auf das Logical Volume Manager (LVM). LVM erlaubt es, mehrere physische Festplatten zu einem Pool zusammenzufassen (Volume Group) und daraus flexible logische Partitionen (Logical Volumes) zu erstellen. Der Vorteil: Man kann Speicherplatz dynamisch zuweisen und erweitern, ohne Partitionen neu anlegen zu müssen.

Praktisch sieht das so aus: Eine neue Festplatte wird dem System hinzugefügt, als Physical Volume initialisiert und der bestehenden Volume Group hinzugefügt. Anschließend kann man das Logical Volume, auf dem Nextcloud liegt, online vergrößern – ohne Downtime. Nicht zuletzt bietet LVM die Möglichkeit von Snapshots, was für konsistente Backups unschätzbar wertvoll ist.

3. RAID-Systeme für Redundanz und Performance

Bei lokalen Servern sind RAID-Konfigurationen Standard. RAID 1 (Spiegelung) bietet Redundanz, RAID 5 oder RAID 6 eine gute Balance zwischen Platzausnutzung und Ausfallsicherheit. Moderne Administratoren setzen zunehmend auf RAID 10 (Striping über Spiegel), das sowohl hohe Performance als auch Redundanz bietet – allerdings auf Kosten der effektiven Speicherkapazität.

Ein oft übersehener Aspekt: Die Wahl des RAID-Levels hat direkte Auswirkungen auf die I/O-Performance, die gerade für Nextcloud mit vielen kleinen Dateien (Metadaten-Operationen) kritisch ist. Ein RAID 5 mit seiner „Parity-Berechnung“ kann hier zum Flaschenhals werden.

Netzwerkbasierte Speicherlösungen (NAS/SAN)

Wenn lokale Erweiterungen nicht mehr ausreichen oder die Anforderungen an Verfügbarkeit und Skalierbarkeit steigen, kommen netzwerkbasierte Speicher ins Spiel.

NFS – Der Klassiker

NFS (Network File System) ist die traditionelle Methode, um Speicher über das Netzwerk bereitzustellen. Die Einrichtung ist vergleichsweise simpel: Auf dem NAS/NFS-Server wird ein Export definiert, auf dem Nextcloud-Server wird dieser gemountet und in Nextcloud als externer Speicher konfiguriert.

Allerdings hat NFS einige Tücken. Die Performance kann bei vielen gleichzeitigen Zugriffen leiden, und die Dateisperr-Mechanismen (Locking) sind nicht immer optimal. Für kleinere Installationen oder für die Ablage von Archival-Daten ist NFS eine solide Wahl. Für hochfrequente Kollaboration hingegen weniger.

SMB/CIFS – Die Windows-Welt

In gemischten Umgebungen ist oft SMB/CIFS die naheliegende Wahl. Nextcloud kann problemlos auf SMB-Freigaben zugreifen. Die Integration erfolgt über die „Externe Speicher“-App, die das smbclient-Paket voraussetzt. Ein Vorteil von SMB ist die gute Integration in Active Directory-Umgebungen, was die Berechtigungsverwaltung vereinfachen kann.

Performance-technisch hat SMB in den letzten Jahren stark aufgeholt, besonders mit der Version 3.0 und den Verbesserungen in SMB 3.1.1. Für viele mittelgroße Unternehmen, die bereits Windows-Server im Einsatz haben, ist dies ein pragmatischer Weg.

GlusterFS und Ceph – Skalierung auf Dateisystem-Ebene

Für wirklich große Installationen lohnen sich verteilte Dateisysteme. GlusterFS und Ceph sind die prominentesten Vertreter. Beide erlauben es, Speicherkapazität und Performance horizontal zu skalieren, indem man einfach weitere Knoten hinzufügt.

GlusterFS ist etwas einfacher zu konfigurieren und eignet sich gut für Dateispeicher. Ceph ist mächtiger, aber auch komplexer; es bietet nicht nur Dateispeicher (CephFS), sondern auch Block- und Objektspeicher in einem integrierten System. Beide Lösungen erfordern allerdings erhebliche Expertise in der Administration und sind für kleine Teams oft überdimensioniert.

Der Paradigmenwechsel: Objektspeicher als Primärspeicher

Die vielleicht wichtigste Innovation für die Skalierung von Nextcloud-Speicher in den letzten Jahren war die native Integration von Objektspeicher (Object Storage). Während traditionelle Dateisysteme Daten in einer Hierarchie von Verzeichnissen organisieren, speichern Objektspeicher wie AWS S3, Google Cloud Storage oder MinIO Daten als flache Sammlung von Objekten in „Buckets“.

Vorteile des Objektspeichers

Warum lohnt der Umstieg? Objektspeicher skaliert nahezu unbegrenzt und kosteneffizient. Man zahlt typischerweise nur für die tatsächlich genutzte Menge. Die Verfügbarkeit ist extrem hoch, und die Daten sind redundant über mehrere Verfügbarkeitszonen oder Rechenzentren gespeichert.

Für Nextcloud bedeutet das: Die eigentlichen Dateien werden aus dem lokalen Dateisystem ausgelagert und im Objektspeicher abgelegt. Nextcloud selbst verwaltet dann nur noch die Metadaten (Dateiname, Berechtigungen, etc.) in der Datenbank und im lokalen Dateisystem. Das entlastet das lokale System erheblich und macht die gesamte Architektur wesentlich skalierbarer.

Konfiguration von S3-kompatiblem Speicher

Die Konfiguration ist überraschend einfach. In der config.php ergänzt man einen Abschnitt wie diesen:

'objectstore' => array(
    'class' => '\\OC\\Files\\ObjectStore\\S3',
    'arguments' => array(
        'bucket' => 'nextcloud-bucket',
        'autocreate' => true,
        'key' => 'IhreAccessKey',
        'secret' => 'IhrGeheimerSchlüssel',
        'hostname' => 's3.eu-central-1.amazonaws.com',
        'port' => 443,
        'use_ssl' => true,
        'region' => 'eu-central-1'
    ),
),

Wichtig: Nach der Umstellung müssen vorhandene Dateien migriert werden. Dafür bietet Nextcloud das Kommandozeilen-Tool occ files:scan --all, das alle Dateien erneut einliest und in den Objektspeicher überträgt. Dieser Prozess kann bei großen Datenmengen sehr lange dauern.

MinIO – Objektspeicher für On-Premise

Wer die Cloud scheut, kann auf On-Premise-Lösungen wie MinIO setzen. MinIO ist ein S3-kompatibler Objektspeicher, den man auf der eigenen Infrastruktur betreiben kann. Die Performance ist hervorragend, und die Administration vergleichsweise einfach. MinIO lässt sich ebenfalls horizontal skalieren, was es zu einer ausgezeichneten Wahl für größere Nextcloud-Installationen macht.

Performance-Optimierung bei großen Speichersystemen

Mehr Speicher allein löst nicht alle Probleme. Im Gegenteil: Mit wachsender Datenmenge können Performance-Probleme auftreten, die die Benutzbarkeit beeinträchtigen.

Caching-Schichten einfügen

Ein mehrstufiges Caching-Konzept kann Wunder wirken. Auf Dateisystem-Ebene kann Redis als Transaktions-File-Locking und für die Zwischenspeicherung von Metadaten dienen. In der config.php konfiguriert man:

'memcache.local' => '\\OC\\Memcache\\Redis',
'redis' => array(
    'host' => 'localhost',
    'port' => 6379,
),

Zusätzlich kann APCu für Opcode-Caching und lokales Caching eingesetzt werden. Für die Datenbank empfiehlt sich ein Query-Cache, sofern unterstützt.

PHP-Optimierungen

Nextcloud läuft auf PHP, und die Standard-PHP-Konfiguration ist oft nicht für große Dateimengen ausgelegt. Kritische Parameter in der php.ini sind:

• memory_limit: Sollte für große Installationen bei mindestens 512M liegen
• max_execution_time: Bei großen Uploads möglicherweise erhöhen
• opcache.enable: Unbedingt aktivieren für bessere Performance

Datenbank-Tuning

Die Datenbank ist das Herzstück jeder Nextcloud-Instanz. Bei wachsender Datenmenge sollte man regelmäßig:

• Die Indizes optimieren (OPTIMIZE TABLE)
• Die Datenbank-Einstellungen anpassen (Puffer-Größen, Connection-Limits)
• Bei MySQL/MariaDB auf den Storage Engine achten (InnoDB ist Pflicht)

Sicherheit und Datenschutz bei erweitertem Speicher

Mit der Erweiterung des Speichers vergrößert sich auch die Angriffsfläche. Besonders bei externen Speicherlösungen sind zusätzliche Sicherheitsmaßnahmen erforderlich.

Verschlüsselung

Nextcloud bietet zwei Arten der Verschlüsselung: Server-seitige Verschlüsselung (SSE) und Client-seitige End-to-End-Verschlüsselung (E2EE). Die server-seitige Verschlüsselung ist einfacher zu handhaben und transparent für die Nutzer. Sie schützt Daten auf externen Speichersystemen, insbesondere in der Cloud.

Die End-to-End-Verschlüsselung ist sicherer, aber auch mit Einschränkungen verbunden: Funktionen wie die serverseitige Textsuche, Vorschaubilder oder die Kollaboration mit OnlyOffice funktionieren dann nicht mehr. Für die meisten Unternehmen ist die server-seitige Verschlüsselung in Kombination mit einer sicheren Übertragung (TLS) der praktikablere Weg.

Zugriffskontrollen und Berechtigungen

Bei komplexen Speicherarchitekturen wird die Berechtigungsverwaltung zur Herausforderung. Nextclouds interne Berechtigungssysteme arbeiten unabhängig von den darunterliegenden Speichersystemen. Das kann zu Inkonsistenzen führen, wenn beispielsweise auf NAS-Ebene andere Berechtigungen gesetzt sind als in Nextcloud.

Eine bewährte Praxis ist es, Nextcloud als alleinigen Gatekeeper für Dateizugriffe zu etablieren und die unterliegenden Speichersysteme mit minimalen, einheitlichen Berechtigungen zu konfigurieren.

Praktische Fallbeispiele

Fall 1: Mittelständisches Unternehmen mit 150 Nutzern

Ausgangslage: Nextcloud läuft auf einem virtuellen Server mit 500 GB Speicher, der zu 90% voll ist. Die Performance lässt nach.

Lösungsansatz: Migration zu einem hybriden Modell. Ein lokaler NAS (NFS) wird für aktive Projektdaten eingerichtet, während ein S3-kompatibler Objektspeicher (MinIO auf einem separaten Server) für ältere, weniger frequently accessed Daten genutzt wird. Die Einrichtung erfolgt schrittweise: Zuerst wird der Objektspeicher für neue Dateien aktiviert, dann werden bestehende Daten migriert.

Ergebnis: Die lokale Entlastung führt zu spürbar besserer Performance. Die Skalierbarkeit ist für die nächsten Jahre gesichert.

Fall 2: Forschungsinstitut mit hohen Anforderungen an Datenschutz

Ausgangslage: 2 TB sensible Forschungsdaten, die aus Compliance-Gründen in der EU bleiben müssen. Cloud-Lösungen scheiden aus.

Lösungsansatz: Aufbau einer Ceph-Cluster-Lösung mit drei Knoten. Die Daten werden dreifach repliziert, was sowohl Redundanz als auch Performance bietet. Nextcloud wird so konfiguriert, dass CephFS als primärer Speicher dient.

Ergebnis: Hochverfügbarer, skalierbarer Speicher, der den Compliance-Anforderungen genügt. Die Gesamtkosten liegen dennoch unter einer Enterprise-Cloud-Lösung.

Monitoring und Wartung

Ein erweiterter Speicher will überwacht werden. Nextcloud bietet eingebaute Monitoring-Tools unter „Administration → Übersicht“. Wichtige Metriken sind:

• Speicherbelegung nach Nutzern und Gruppen
• Performance der Datenbank-Abfragen
• Auslastung des PHP Opcache

Für die zugrundeliegenden Speichersysteme sollte man zusätzliche Monitoring-Tools wie Prometheus (mit Grafana für Visualisierungen) oder die herstellereigenen Lösungen der Storage-Anbieter einsetzen.

Zukunftsperspektiven

Die Entwicklung von Nextcloud geht klar in Richtung besserer Skalierbarkeit. Interessant ist die wachsende Unterstützung für dezentrale Speichermodelle – ähnlich wie bei einem Content Delivery Network (CDN). Dabei könnten Dateien geografisch näher an den Nutzern gespeichert werden, während Nextcloud die globale Konsistenz verwaltet.

Ein weiterer Trend ist die Intelligente Daten-Tiering: Nextcloud könnte automatisch entscheiden, welche Daten auf schnellem (teurem) Speicher und welche auf langsameren (günstigeren) Ebenen liegen sollten, basierend auf Zugriffsmustern.

Fazit

Die Erweiterung des Nextcloud-Speichers ist heute kein rein technisches Problem mehr, sondern eine strategische Entscheidung. Die Bandbreite reicht von simplen lokalen Erweiterungen bis hin zu komplexen, hybriden Architekturen mit Objektspeicher.

Für die meisten Organisationen wird ein mehrstufiger Ansatz am sinnvollsten sein: Schneller lokaler Speicher für aktive Daten, gepaart mit skalierbarem Objektspeicher für Backups und Archivdaten. Wichtig ist, dass die gewählte Lösung nicht nur das aktuelle Platzproblem löst, sondern auch langfristig skalierbar, sicher und wirtschaftlich betreibbar bleibt.

Letztlich zeigt sich: Eine gut geplante Speicherarchitektur ist keine Kostenstelle, sondern eine Investition in die Zukunftsfähigkeit der gesamten Kollaborations-Infrastruktur. Sie bildet das Fundament, auf dem moderne, datenintensive Arbeitsweisen erst möglich werden.