Nextcloud 34 vermessen: Ressourcen, Transfer und ein Restore in drei Anläufen

Kurz gesagt: Nextcloud 34 ist genügsamer als sein Ruf — 168 MiB RAM im Leerlauf, unter 20 Sekunden bis zur laufenden Instanz. Zwei Dinge sind unangenehm: Der Grundzoll auf der Platte liegt bei rund 4 GB, bevor die erste eigene Datei da ist, und bei vielen kleinen Dateien bricht der Durchsatz auf 3,24 Dateien pro Sekunde ein. Der Restore-Test war der eigentliche Gewinn: Er hat drei Anläufe gebraucht.

Warum diese Messung #

Für den Guide Nextcloud selbst hosten war die Frage offen, was Nextcloud tatsächlich kostet. Die eigene Produktivinstanz taugt dafür nicht — sie ist über Monate gewachsen und beantwortet weder die Frage nach dem Installationsaufwand noch die nach dem Grundverbrauch.

Also eine eigene Testinstanz: zweiter Compose-Stack neben der produktiven, eigene Volumes, eigenes Netz, eigener Port, eigene Zugangsdaten. Nach den Messungen restlos zurückgebaut. Die Produktivinstanz war zu keinem Zeitpunkt beteiligt.

Der Teststand #

Vier Dienste: Nextcloud 34 (Apache-Variante), PostgreSQL 16, Redis 8 und ein Cron-Container. Host ist ein 6-Kern-x86-Desktop mit 35 W TDP, 16 GB RAM und NVMe-SSD unter Debian 13.6, Docker 29.7.2 mit Compose 5.5.0.

Testdaten waren durchgehend Zufallsdaten aus /dev/urandom — nicht komprimierbar, damit Größenangaben nicht durch Kompression geschönt werden.

Einschränkungen, damit die Zahlen richtig gelesen werden:

• Die Transfermessungen liefen über Loopback gegen 127.0.0.1. Sie beschreiben Server- und Speicherleistung, nicht was ein Client im LAN erreicht.
• Die Messung mit vielen kleinen Dateien lief sequentiell, ein eigener curl-Aufruf mit eigener Verbindung und eigener Anmeldung pro Datei. Ein echter Desktop-Client parallelisiert.
• Die Images lagen bereits lokal vor. Die Startzeiten enthalten keinen Registry-Download.
• Je ein Lauf pro Messwert, keine Mittelung über mehrere Durchgänge.

Was am meisten überrascht hat #

Die Installation ist trivial. docker compose up -d in 0,81 Sekunden, nach 7,95 Sekunden antwortet HTTP, die Installation selbst dauert 11,76 Sekunden. Zusammen keine 20 Sekunden.

Die Grundkonfiguration ist besser als ihr Ruf. Von vier Warnungen ließen sich drei mit je einem Befehl erledigen. Redis musste überhaupt nicht konfiguriert werden — das offizielle Image setzt memcache.distributed und memcache.locking allein aufgrund der Umgebungsvariable für den Redis-Host. Die einzige Warnung, die stehen blieb, war die zu fehlenden HTTP-Sicherheitsheadern: Die braucht HTTPS und damit einen Reverse Proxy.

Viele kleine Dateien sind die Schwäche. 1000 Dateien à 10 KB — zusammen 12 MB — brauchten 308 Sekunden. Dieselbe Instanz nimmt 1 GB am Stück in 7,3 Sekunden entgegen. Jede Datei ist eine eigene HTTP-Anfrage mit eigener Anmeldung, eigener Sperre und eigener Datenbanktransaktion. Wer Nextcloud an einem Quellcode-Baum misst, bekommt ein völlig anderes Bild als bei Videos.

Die Datenbank wächst kaum mit. Nach 1067 Dateien war sie von 15 auf 17 MB gewachsen. Zum Vergleich die Produktivinstanz: 7592 Dateien, 46 MB.

Der Restore-Test #

Der Teil, der sich am meisten gelohnt hat. Backup aus der Testinstanz, Restore in eine dritte, komplett leere Instanz. Er hat im dritten Anlauf funktioniert.

Anlauf 1 — HTTP 500. Der Nextcloud-Installer legt eine eigene Datenbankrolle an und trägt sie in die config.php ein. Rollen sind in PostgreSQL aber Cluster-Objekte und stecken nicht im pg_dump einer einzelnen Datenbank. Im frischen Zielcontainer existierte nur die aus der Compose-Datei erzeugte Rolle. Es fehlten 583 Bytes, die ein pg_dumpall --roles-only in 0,11 Sekunden mitsichert.

Anlauf 2 — permission denied for table oc_appconfig. Die Rollen waren jetzt da, aber nach dem Schema eingespielt. Der Dump enthält zwar ALTER TABLE … OWNER TO-Anweisungen, die liefen aber ins Leere, weil die Rolle zu diesem Zeitpunkt noch nicht existierte. Alle 131 Tabellen gehörten danach dem falschen Benutzer. Richtige Reihenfolge: erst Rollen, dann Datenbank mit korrekter Eigentümer-Rolle anlegen, dann den Dump einspielen.

Anlauf 3 — Wartungsmodus. Die wiederhergestellte Instanz meldete maintenance: true, WebDAV antwortete mit 503. Kein Fehler, sondern Logik: Das Backup war korrekt im Wartungsmodus erstellt worden, also stand der Zustand in der gesicherten config.php und kam mit zurück. occ maintenance:mode --off gehört in die Restore-Checkliste.

Verifiziert wurde über MD5-Prüfsummen zweier Dateien, vor dem Backup notiert und nach dem Restore erneut gebildet — einmal direkt und einmal nach einem Download über WebDAV.

Fazit #

Ein Backup, das nur pg_dump nextcloud macht, ist bei Nextcloud nicht wiederherstellbar — und man merkt es erst im Ernstfall. Das ist der Befund, der aus dieser Messreihe hängen bleibt, nicht die Durchsatzwerte.

Für die Hardwarefrage: Nextcloud 34 läuft mit unter 170 MB RAM im Leerlauf auf jedem Mini-PC. Die Plattenkosten liegen nicht bei den Nutzdaten, sondern beim Rahmen — rund 3 GB Images plus 935 MB Installation, davon 573 MB Apps, die man überwiegend nicht benutzt.

Wie das praktisch aufgesetzt wird, steht im Guide Nextcloud selbst hosten.