Nextcloud-Architektur: Warum du Betriebssystem und Daten auf getrennten Disks betreiben MUSST
Veröffentlicht am 26. Februar 2026 – Ein Deep-Dive in die Server-Struktur
In meinem letzten Beitrag haben wir uns angesehen, wie man Proxmox auf einem 8-GB-System optimiert. Doch Hardware-Tuning ist nur die halbe Miete. Heute widmen wir uns der Software-Architektur, genauer gesagt: Deiner Nextcloud-Instanz. Viele Administratoren machen am Anfang den Fehler, Nextcloud einfach „out of the box“ zu installieren. Das Ergebnis ist eine einzige, riesige virtuelle Festplatte (z. B. 320 GB), auf der sowohl das Betriebssystem (Ubuntu/Debian) als auch die Nutzerdaten (Fotos, Dokumente, Datenbanken) liegen.
Das klingt erst einmal unproblematisch, ist aber in der Praxis eine strategische Sackgasse. In diesem Artikel erkläre ich dir, warum wir unseren Nextcloud-Datenordner auf eine separate virtuelle Festplatte (`scsi1`) migriert haben, welche massiven Vorteile das für dein Backup-Management hat und wie du diesen Umzug technisch absolut sicher über die Bühne bringst.
Das Problem der „monolithischen“ Festplatte
Wenn du alles auf einer Disk speicherst, baust du dir einen sogenannten Monolithen. Das bedeutet: Alles ist mit allem verknüpft. Wenn dein Betriebssystem aufgrund eines fehlerhaften apt upgrade, eines Kernel-Panics oder einer korrupten Systemdatei nicht mehr bootet, sind auch deine Daten erst einmal „gefangen“. Natürlich kannst du das gesamte 320-GB-Image aus einem Backup wiederherstellen, aber das dauert – je nach Geschwindigkeit deines Storages – Stunden.
Ein weiteres Problem ist die Fragmentierung der Ressourcen. Das Betriebssystem schreibt ständig Logfiles, temporäre Dateien und Cache-Daten. Gleichzeitig greifen Nutzer auf ihre Urlaubsfotos zu. Auf einer einzigen virtuellen Disk müssen sich diese I/O-Anfragen (Input/Output) in derselben Warteschlange anstellen. Das erhöht den sogenannten I/O Wait und macht deine Nextcloud träge.
Die strategischen Vorteile der Datentrennung
Durch die Trennung von System (`scsi0`) und Daten (`scsi1`) schaffen wir eine modulare Architektur, die im Enterprise-Umfeld Standard ist. Hier sind die drei wichtigsten Gründe, warum du das auch in deinem Homelab tun solltest:
1. Disaster Recovery (RTO & RPO)
Stell dir vor, dein Ubuntu-System ist zerschossen. Da deine Daten auf einer eigenen Disk liegen, kannst du in Proxmox einfach eine neue, saubere VM aufsetzen und die bestehende Daten-Disk (`scsi1`) mit zwei Klicks wieder einhängen. Dein Recovery Time Objective (RTO) sinkt von Stunden auf Minuten. Das Betriebssystem-Image bleibt mit ca. 15-20 GB winzig und lässt sich blitzschnell sichern.
2. Skalierbarkeit ohne Risiko
Dein Speicherplatz wird knapp? Bei einer monolithischen Disk müsstest du die Partition vergrößern, was oft das Hantieren mit gparted oder fdisk an der Boot-Partition erfordert. Ein Fehler hier, und das System bootet nicht mehr. Bei getrennten Disks vergrößerst du einfach die scsi1 in Proxmox und führst ein simples resize2fs in der VM aus. Die Boot-Partition bleibt unangetastet und sicher.
3. Backup-Effizienz
Hier greift unsere neue Backup-Strategie. Du kannst das System-Image (`scsi0`) täglich sichern, während du für die Daten-Disk (`scsi1`) vielleicht ein anderes Intervall oder sogar eine andere Kompressionsstufe wählst. Da das System-Image klein ist, verbraucht es kaum Platz in deinem Backup-Pool.
Der technische Umzug: Schritt-für-Schritt
Die Migration des Datenordners ist eine Operation am offenen Herzen, aber mit der richtigen Vorbereitung absolut sicher. Wir gehen davon aus, dass du bereits eine zweite Disk in Proxmox hinzugefügt hast (z. B. 150 GB auf scsi1).
Schritt 1: Vorbereitung des neuen Dateisystems
Zuerst müssen wir die neue „nackte“ Festplatte in der VM formatieren. Wir nutzen hierfür Ext4, da es stabil, schnell und journalsicher ist.
# Die neue Platte identifizieren (meist /dev/sdb)
lsblk
# Partitionieren und Formatieren
sudo mkfs.ext4 /dev/sdb
# Mountpoint erstellen
sudo mkdir /mnt/nc_data
sudo mount /dev/sdb /mnt/nc_data
Schritt 2: Der Datentransfer (rsync ist Pflicht)
Bevor wir kopieren, muss die Nextcloud in den Wartungsmodus versetzt werden, damit keine neuen Daten geschrieben werden, während wir umziehen. Danach nutzen wir rsync, um die Dateiberechtigungen (wichtig für den User www-data) exakt beizubehalten.
# Wartungsmodus aktivieren
sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on
# Daten kopieren
sudo rsync -avzP /var/www/nextcloud/data/ /mnt/nc_data/
# WICHTIG: Berechtigungen prüfen
sudo chown -R www-data:www-data /mnt/nc_data
sudo chmod -R 750 /mnt/nc_data
Schritt 3: Permanente Einbindung via fstab
Damit die Platte auch nach einem Neustart wieder unter /mnt/nc_data zur Verfügung steht, müssen wir die /etc/fstab anpassen. Nutze hierfür immer die UUID der Platte, da sich Bezeichnungen wie /dev/sdb ändern können.
# UUID herausfinden
blkid /dev/sdb
# Eintrag in /etc/fstab (Beispiel)
UUID=deine-uuid-hier /mnt/nc_data ext4 defaults,noatime,errors=remount-ro 0 2
Die Option noatime ist ein kleiner SEO-Geheimtipp für die Performance: Sie verhindert, dass das System bei jedem Lesezugriff die „Last Accessed“-Zeit schreibt, was unnötigen Disk-I/O spart.
Die Nextcloud-Konfiguration anpassen
Jetzt müssen wir Nextcloud nur noch sagen, wo sein neues Zuhause ist. Das geschieht in der zentralen Konfigurationsdatei config/config.php.
'datadirectory' => '/mnt/nc_data',
Nachdem du die Datei gespeichert hast, kannst du den Wartungsmodus wieder deaktivieren:
sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off
Ein kurzer Check im Browser: Wenn deine Fotos laden, hast du es geschafft! Deine Nextcloud ist nun modular aufgebaut.
Performance Deep Dive: I/O-Isolation
Warum fühlt sich die Nextcloud nach diesem Umzug oft „snappier“ an? Das liegt am Linux-Kernel-Scheduler. Wenn System-Logs und Nextcloud-Daten auf zwei verschiedenen virtuellen Geräten liegen, kann der Hypervisor (Proxmox) die Anfragen besser parallelisieren.
Stell dir vor, du hast zwei Kassen im Supermarkt statt einer. Selbst wenn beide Kassen auf dieselbe physische SSD zugreifen, erlaubt das VirtIO SCSI-Protokoll eine effizientere Verteilung der Befehlsketten (Queues). In Kombination mit unserem RAM-Tuning (ZFS ARC Limit) reduzieren wir die Latenz bei Datenbankabfragen massiv.
Die mathematische Annäherung an die Latenzverbesserung lässt sich oft so beschreiben: $$L_{total} = \frac{1}{n} \sum_{i=1}^{n} L_i$$ Durch die Trennung verteilen wir die Last $n$ auf mehrere Queues, was die durchschnittliche Latenz $L$ pro Anfrage senkt.
SEO und User Experience (UX)
Du fragst dich vielleicht: „Was hat das mit SEO zu tun?“ Die Antwort ist einfach: PageSpeed. Google nutzt die Core Web Vitals als Rankingfaktor. Wenn du öffentliche Dateien oder Galerien über deine Nextcloud teilst, zählt jede Millisekunde beim Laden der Previews. Ein optimiertes Disk-Subsystem sorgt für schnellere Time to First Byte (TTFB) Werte. Deine Nutzer freuen sich über eine flüssige Galerie, und die Suchmaschinen honorieren die technische Exzellenz deiner Infrastruktur.