Nextcloud mit S3 statt Festplatte

Ein Scan, 270 MB, ein ganzer Stapel Unterlagen in einem einzigen PDF. Ich tippe ihn in meiner Nextcloud an, und statt der ersten Seite kommt eine Meldung: „Datei zu groß“. Zu groß wofür? Und vor allem: Ist mit der Datei etwas nicht in Ordnung?

Bei den meisten würde man jetzt nachsehen, ob die Datei auf der Festplatte noch heil ist. Bei mir liegt sie auf keiner Festplatte in meinem Haus. Sie liegt in einem gemieteten Speicher in einem Rechenzentrum, und dort heißt sie nicht einmal „Scan“. Sie hat nur eine Nummer. Wie das funktioniert, warum ich es so gebaut habe und was es für die Sicherung bedeutet, erzähle ich hier, Schritt für Schritt und ohne Vorwissen.

Ein eigenes Dropbox zu Hause

Nextcloud ist so etwas wie Dropbox oder Google Drive, nur selbst betrieben. Auf Laptop und Handy gibt es einen Ordner, der sich mit einem Server abgleicht, dazu Kalender und Kontakte. Der Unterschied ist, dass dieser Server bei mir steht und bei keinem Konzern.

Genauer läuft Nextcloud bei mir in einer VM, einer virtuellen Maschine. Das ist ein Computer, den mein Server zu Hause nur nachspielt, mit eigenem Betriebssystem und eigener Festplatte, die in Wahrheit eine Datei auf dem Server ist. Auf diesem einen Server laufen so ein gutes Dutzend VMs nebeneinander, eine pro Dienst. Die für Nextcloud heißt nextcloud-01, und ihre Festplatte ist 40 GB groß.

40 GB sind für Fotos, Scans und alles andere ziemlich wenig. Trotzdem ist sie seit dem Einzug nicht vollgelaufen. Das liegt daran, wohin die Dateien tatsächlich gehen.

Ein Lagerabteil bei Hetzner

Hetzner ist ein deutscher Hoster, also eine Firma, die Server und Speicher in ihren Rechenzentren vermietet. Eines ihrer Angebote ist Speicher, den man über eine Schnittstelle namens S3 anspricht. Ich nenne ihn im Folgenden einfach S3-Speicher. Er funktioniert anders als eine Festplatte: Es gibt keine Ordner, man gibt eine Sache mit einem Namen ab und bekommt sie unter diesem Namen wieder.

Man kann sich das wie ein Lagerhaus vorstellen. Ich miete darin ein eigenes Abteil, das heißt bei S3 Bucket. In das Abteil stelle ich Kisten, die heißen Objekte. Jede Kiste hat ein Etikett, und mehr Ordnung als diese Etiketten gibt es nicht. Was in einer Kiste steckt, ist dem Lagerhaus egal.

Eine Datei, die nur eine Nummer ist

Nextcloud kann so ein Lagerabteil auf zwei Arten nutzen. Entweder als zusätzlichen Ordner neben den eigenen Dateien. Oder als Primärspeicher, das heißt: als den Ort, an dem alle Dateien landen, statt auf der Festplatte der VM. Ich nutze die zweite Variante.

Dann passiert bei jedem Upload Folgendes. Nextcloud schreibt den Namen der Datei, den Ordner, die Größe und den Besitzer in seine Datenbank, eine Art Karteikasten, in dem jede Datei eine Karte mit einer laufenden Nummer bekommt. Den Inhalt der Datei stellt es als Objekt in den Bucket, und auf dem Etikett steht nur diese Nummer, etwa urn:oid:4711. Das Bild zeigt den Weg einer Datei von links oben nach unten:

Aus Steuer/2025.pdf wird im Bucket also die Kiste 4711. Welche Kiste welche Datei ist, steht nur auf den Karteikarten in der Datenbank. Auf der VM bleiben dadurch nur Datenbank, Einstellungen und die Nextcloud-Programme selbst, beim Umzug im September zusammen etwa 3,3 GB. Im Bucket standen zur selben Zeit 565 Objekte mit gut 8 GB, und dieser Teil wächst, ohne dass die Festplatte der VM es merkt.

Merk dir den Karteikasten, er kommt wieder. Ohne ihn ist der Bucket nur ein Lager voller Kisten mit Nummern.

Was ich davon habe und was es kostet

Klingt umständlich. Warum nicht einfach eine große Festplatte? Die Abwägung passt in eine kleine Tabelle, links was ich gewinne, rechts was ich dafür bezahle:

Mein wichtigster Grund steht oben links. Alle VMs teilen sich die Festplatte meines Servers zu Hause. Würden die Nextcloud-Dateien dort wachsen, nähmen sie irgendwann allen anderen Diensten den Platz weg. So wächst der Bucket, und eine neue Platte muss ich dafür nicht kaufen. Nebenbei liegen die Dateien schon außer Haus. Geht der Server zu Hause kaputt, sind sie davon nicht betroffen.

Den Preis spürt man im Alltag als Umweg. Jede Datei geht vom Laptop zur VM und von dort ins Rechenzentrum, beim Öffnen denselben Weg zurück. Auch wenn ich auf dem Sofa sitze, verlässt also jede Datei einmal das Haus. Bei großen Dateien bestimmt der Upload meines Internetanschlusses das Tempo. Wie viel Wartezeit das genau kostet, habe ich ehrlich gesagt nie gemessen.

Der zweite Preis ist eine Entscheidung, die man nur einmal trifft. Den Primärspeicher legt man beim Einrichten fest, eine laufende Nextcloud lässt sich nicht einfach umschalten. Das Abteil zu wechseln geht dagegen erstaunlich leicht, wie sich beim Umzug gezeigt hat.

Der Umzug, bei dem keine Datei umzog

Bis September 2026 lief meine Nextcloud ohne eigene VM, direkt auf meinem Arbeitsrechner. Und zwar als Nextcloud AIO, kurz für All-in-One. Das ist ein Komplettpaket aus Containern. Ein Container ist ein Programm, das mit allem, was es braucht, in einer eigenen Kiste läuft, getrennt vom Rest des Rechners. Bei AIO sind es zehn solche Kisten: Nextcloud selbst, die Datenbank, ein Office-Editor namens EuroOffice und einige Helfer. Eine davon, der Mastercontainer, ist der Verwalter. Er startet und aktualisiert die anderen neun selbst.

Dafür braucht der Mastercontainer die volle Kontrolle über alle Container des Rechners. So einen Verwalter möchte ich nicht neben anderen Diensten haben, deshalb bekam Nextcloud beim Umzug eine VM für sich allein, eben nextcloud-01.

Am 8. September war es so weit. Die Datenordner der zehn Container, zusammen die erwähnten 3,3 GB, gingen gepackt über eine verschlüsselte Verbindung auf die neue VM. Ein Skript richtete dort den Mastercontainer ein, und danach meldete sich Nextcloud als installiert. Und die Dateien? Die sind nicht umgezogen. Sie standen ja schon im Bucket, und die neue VM fand sie genau dort, wo die alte sie hingestellt hatte. Da hat sich die ganze Konstruktion zum ersten Mal richtig gelohnt.

Ein eigenes Abteil in sechs Sekunden

Bis dahin teilte sich Nextcloud ihren Bucket mit anderen Daten aus meinem Homelab. Noch am selben Abend bekam sie einen eigenen. Dafür musste ich alle Objekte vom alten in den neuen Bucket kopieren. Das ging serverseitig, also innerhalb des Rechenzentrums, ohne dass ein Byte durch meine Leitung musste: 565 Objekte, gut 8 GB, sechs Sekunden.

Danach folgte der eigentliche Wechsel in vier Schritten, alle mit occ, dem Kommandozeilen-Werkzeug von Nextcloud:

1. Nextcloud in den Wartungsmodus schalten. Dann nimmt es keine Änderungen mehr an.
2. Noch einmal kopieren, nur was seit der ersten Kopie dazugekommen war.
3. In den Einstellungen den Namen des neuen Buckets eintragen.
4. Wartungsmodus aus.

Den alten Bucket mit seinen Objekten habe ich als Rückweg stehen lassen. Ganz selbstverständlich ist so eine schnelle Kopie übrigens nicht. Einen Tag später klappte sie zwischen einem älteren Bucket und einem neuen nicht, vermutlich weil die beiden in verschiedenen Teilen des Rechenzentrums stehen. Dann müssen alle Daten durch einen Rechner, der sie liest und wieder schreibt, bei diesen rund 50 GB in zwei Anläufen.

Wer darf hinein?

Die Dateien stehen also bei Hetzner, und der Karteikasten weiß, wie sie heißen. Bleibt die Frage, wer überhaupt an sie herankommt. Dafür nutze ich Single Sign-on: eine zentrale Anmeldung, wie ein Schlüssel, der zu mehreren Türen passt. Bei mir übernimmt das ein Dienst namens Authentik in seiner eigenen VM. Auf der Login-Seite von Nextcloud gibt es dafür den Knopf „Mit Authentik anmelden“, und hinein darf nur, wen ich in Authentik in die Gruppe für Nextcloud gesteckt habe.

Eine Einstellung dabei sieht nach einer Fußnote aus und ist doch die wichtigste. Nextcloud übernimmt meinen Benutzernamen aus Authentik eins zu eins. Das muss so sein, denn im Karteikasten gehört jede Datei einem Benutzernamen. Käme Authentik mit einem anderen, legte Nextcloud ein zweites, leeres Konto an, und meine Dateien wären scheinbar weg. Gelöscht wäre nichts, aber erklär das mal jemandem, der gerade vor einem leeren Ordner sitzt.

Einmal scheiterte jede Anmeldung, weil Authentik nach einem Update eine zusätzliche Einstellung verlangte; die Geschichte steht in Teil 2.

Was die Sicherung abdeckt

Zurück zur Frage vom Anfang, nur eine Nummer größer. Was, wenn nicht eine Datei klemmt, sondern der Karteikasten kaputt ist? Dann stehen 565 Kisten im Lager, und ich habe keine Ahnung, welche davon meine Steuererklärung ist. Die Datenbank ist deshalb das Wertvollste auf der VM, und so ist auch die Sicherung gebaut.

Zwei Begriffe brauche ich dafür. Der erste ist der Sicherungsserver: ein zweiter Server, ebenfalls bei Hetzner, auf den mein Server zu Hause jede Nacht alle VMs als Ganzes sichert. Der zweite ist die Versionierung, eine Einstellung des Buckets. Mit ihr bleibt ein überschriebenes oder gelöschtes Objekt als ältere Fassung erhalten, ähnlich wie ein Papierkorb mit Gedächtnis.

Damit lässt sich die Sicherung von nextcloud-01 in drei Zeilen beschreiben:

Das Bild zeigt dieselben drei Wege, und unten den, den es noch nicht gibt:

Für die Sicherung um 03:30 hält ein Skript alle AIO-Container außer dem Verwalter kurz an, damit sich während des Packens nichts ändert. Danach startet der Mastercontainer alles wieder. Wie dieses Skript mit allen anderen Diensten umgeht, erzählt der Deep Dive zu compose-backup.

Beim Zurückholen muss ich eines im Kopf behalten. Spiele ich den Karteikasten von letzter Nacht ein, kennt er die Dateien von heute nicht. Ihre Kisten stehen dann unbeschriftet im Lager. Umgekehrt kennt er Dateien, die ich seitdem gelöscht habe, und da hilft die Versionierung, weil die gelöschten Objekte noch als ältere Fassung da sind.

Eine Lücke bleibt, und die will ich nicht kleinreden. Die Versionierung schützt vor meinen eigenen Fehlern, gegen den Verlust des ganzen Buckets oder meines Kontos bei Hetzner hilft sie nicht. Die Sicherung des Karteikastens liegt sogar im selben Bucket wie die Dateien. Eine Kopie bei einem zweiten Anbieter gibt es bisher nicht. Außer Haus ist eben noch nicht dasselbe wie gesichert.

Aus der Praxis: Mitte Oktober schlug die Sicherung um 03:30 jede Nacht fehl. Der Grund war eine Sparmaßnahme. Mein Server kann einer VM Arbeitsspeicher wegnehmen, wenn er ihn woanders braucht, bis hinunter zu einem Minimum, das ich festlege. Für nextcloud-01 stand es auf 3 GB, und die VM lief zeitweise mit 2,8 GB. Um 03:30 kam das Kopierprogramm für den Upload mit rund 1 GB dazu. Danach las die VM ein bis zwei Stunden lang verzweifelt immer wieder dieselben Dateien von der Platte, bis das System das Kopierprogramm abwürgte. Ich habe das Minimum auf 4 GB gesetzt. In der nächsten Nacht lief der Upload durch, gut 5 GB in etwas mehr als einer Stunde. Seitdem denke ich bei jedem Minimum an die Nacht, nicht an den Tag.

Und der Scan?

Dem ging es die ganze Zeit gut. Nextcloud hatte keinen Fehler notiert, und occ holte die Datei ohne Murren aus dem Bucket. Das Antippen hatte das PDF in EuroOffice geöffnet, dem Office-Editor aus dem AIO-Paket, und der lehnt große Dateien ab. Seit PDFs im eingebauten PDF-Betrachter aufgehen, öffnet sich auch der dicke Scan.

Mitgenommen habe ich daraus vor allem eine Reihenfolge. Wenn bei einer Nextcloud mit S3-Speicher etwas klemmt, fällt der Verdacht schnell auf den Speicher, einfach weil man ihn nicht sieht. Erst prüfen, ob sich die Datei lesen lässt, dann suchen, wer sie nicht haben will. Und den Karteikasten behandle ich seitdem wie das, was er ist: das Einzige, was aus 565 Nummern meine Dateien macht.

Wie die Sicherung im ganzen Homelab funktioniert und wer nachts Bescheid sagt, wenn ein Lauf scheitert, steht in Teil 6: Sicherung und Überwachung.