Zwischen Release-Takt, Upgrade-Pfaden und der Frage, wann man springt
Kaum ein Thema sorgt in Administratorenrunden für so verlässlichen Gesprächsbedarf wie die Frage, wann eine Nextcloud-Instanz auf die nächste Hauptversion gehoben werden sollte. Auf der einen Seite stehen Sicherheitsupdates, neue Funktionen und der Wunsch, nicht auf einem alten Stand festzusitzen. Auf der anderen Seite steht die nüchterne Erfahrung, dass ein misslungenes Upgrade einer gewachsenen Instanz schon manches Wochenende ruiniert hat. Wer schon einmal nachts vor einem System gesessen hat, das nach dem Sprung von einer Hauptversion auf die nächste nur noch eine weiße Seite ausliefert, weiß, wovon die Rede ist.
Dabei ist das Versionsmodell von Nextcloud alles andere als undurchsichtig – vorausgesetzt, man kennt die Spielregeln. Die folgenden Abschnitte versuchen, Ordnung in das Thema zu bringen: von der Bedeutung der Nummern über Release-Kanäle und Support-Zeiträume bis hin zum konkreten Ablauf eines Upgrades und den Stellen, an denen es typischerweise hakt.
Was die Zahlen tatsächlich bedeuten
Nextcloud nummeriert seine Server-Releases nach dem Schema Hauptversion.Punktstand.Patchlevel, also etwa 28.0.4 oder 29.0.2. Die erste Stelle ist die eigentliche Zäsur. Sie markiert einen neuen Entwicklungszweig mit neuen Funktionen, geänderten Abhängigkeiten und in aller Regel auch verschobenen Systemanforderungen. Die mittlere Stelle spielt in der Praxis kaum eine Rolle; sie steht bei Nextcloud traditionell auf Null, weil zwischen zwei Hauptversionen keine eigenen Feature-Releases eingeschoben werden. Die dritte Stelle schließlich ist die Wartungsziffer – jene Zahl, die man im Blick behalten sollte, weil sie Fehlerkorrekturen und Sicherheitsfixes bündelt, ohne das System grundlegend zu verändern.
Die Versionsnummer allein verrät allerdings wenig über den Funktionsumfang. Nextcloud vermarktet seine Releases seit einigen Jahren zusätzlich unter dem Namen „Hub“, und diese Hub-Zählung läuft nicht synchron zur technischen Nummerierung. Wer in einer Ausschreibung von „Nextcloud Hub“ liest, muss also nicht zwangsläufig dieselbe Version meinen wie der Techniker, der von „Version 28“ spricht. Das ist kein Drama, aber eine Quelle von Missverständnissen, die man im Projektalltag besser früh ausräumt.
Die installierte Version lässt sich an mehreren Stellen ablesen. Am schnellsten geht das über die Kommandozeile mit occ -V oder occ status, das neben der Version auch den Installationspfad, den Wartungsmodus und den Zustand der Datenbank ausgibt. Alternativ lohnt ein Blick in die Datei version.php im Installationsverzeichnis. In der Web-Oberfläche findet sich der Stand unter den administrativen Grundeinstellungen, genau dort, wo auch der Update-Kanal umgestellt wird.
Release-Kanäle: stable ist nicht gleich stable
Nextcloud kennt mehrere Update-Kanäle, und die Wahl des Kanals ist eine der wirkungsvollsten Stellschrauben überhaupt. Der Kanal stable liefert neue Hauptversionen, sobald sie offiziell freigegeben sind. Wer diesen Kanal nutzt, bekommt Neuerungen früh – und trägt ein gutes Stück des Risikos selbst. Der Kanal production ist bewusst konservativer: Er hält neue Hauptversionen zurück, bis erste Rückmeldungen aus der Breite vorliegen und die gröbsten Kinderkrankheiten ausgeräumt sind. Für Unternehmen, die eine Instanz mit ein paar hundert oder tausend Nutzern betreiben, ist das in der Regel die vernünftigere Wahl.
Daneben existieren die Kanäle beta und daily. Ersterer richtet sich an Tester, die neue Funktionen vor der Freigabe ausprobieren möchten, letzterer zieht Entwicklungsstände direkt aus dem Versionskontrollsystem. Beide haben in einer Produktivumgebung nichts verloren, auch wenn die Versuchung gerade bei kleinen, selbst betriebenen Instanzen manchmal groß ist. Ein Blick auf die Release Notes und das Änderungsprotokoll auf der Projektseite ersetzt in den meisten Fällen jedes Herumprobieren.
Der Update-Kanal wird in den administrativen Grundeinstellungen gewählt; technisch hinterlegt ist er als updater.release.channel in der Konfigurationsdatei. Wer den Kanal wechselt, sollte sich im Klaren darüber sein, dass ein Wechsel von stable auf production die Instanz nicht zurückstuft, sondern lediglich dafür sorgt, dass künftige Hauptversionen später angeboten werden. Der umgekehrte Weg kann dagegen dazu führen, dass ein Update wesentlich früher vorgeschlagen wird als geplant.
Support-Zeiträume und das Ende des Lebenszyklus
Nextcloud pflegt in der Regel die jeweils letzten drei Hauptversionen parallel. Das bedeutet: Jede Version erhält über einen Zeitraum von ungefähr zwölf Monaten Wartungsupdates mit Fehlerkorrekturen und Sicherheitsfixes. Danach endet die Versorgung, und wer dann noch auf dieser Version unterwegs ist, betreibt ein System ohne Sicherheitsupdates. Dass das auf Dauer keine gute Idee ist, muss man an dieser Stelle wohl nicht ausführlich begründen.
Für Kunden mit einem Enterprise-Abonnement gelten abweichende Regeln. Dort gibt es zusätzlich verlängerte Support-Zeiträume sowie speziell gepflegte Versionsstände, die sich nicht immer exakt an der öffentlichen Patch-Zählung orientieren. Wer eine solche Vereinbarung hat, sollte die Upgrade-Planung ohnehin mit dem Hersteller abstimmen und nicht allein nach dem öffentlichen Veröffentlichungsrhythmus entscheiden.
Ein interessanter Aspekt der Support-Politik: Nextcloud veröffentlicht pro Jahr zwei bis drei Hauptversionen, wodurch sich die unterstützten Zweige überlappen. Für Administratoren entsteht daraus ein Fenster, in dem man in Ruhe entscheiden kann, wann der Sprung erfolgt. Wer dieses Fenster nutzt und nicht bei jedem Release sofort springt, sondern jeweils auf den ersten oder zweiten Punktstand wartet, fährt in der Praxis deutlich entspannter.
Der eiserne Grundsatz: ein Schritt pro Hauptversion
Wer von Version 25 kommt und Version 28 anpeilt, kann nicht einfach direkt umsteigen. Nextcloud unterstützt ausschließlich den Sprung auf die jeweils unmittelbar folgende Hauptversion, und zwar von einem aktuellen Punktstand aus. Das heißt konkret: Von 25 muss man zunächst auf den letzten Patch von 26, dann auf den letzten Patch von 27 und erst danach auf 28. Jeder dieser Schritte ist ein eigenständiges Upgrade mit eigenen Datenbankmigrationen, eigenen Anpassungen an der Konfiguration und einem eigenen Satz möglicher Fehlerquellen.
Das mag umständlich wirken, hat aber einen guten Grund. Die Migrationen innerhalb einer Hauptversion setzen einen bestimmten Datenbankzustand voraus. Sie sind nicht darauf ausgelegt, einen Sprung über mehrere Generationen hinweg zu verkraften. Wer diese Regel umgeht – etwa durch manuelles Eingreifen in die Konfiguration oder durch Tricks in der Versionsprüfung –, handelt sich in der Regel Probleme ein, die sich deutlich schwerer eingrenzen lassen als ein regulärer, mehrstufiger Upgrade-Pfad.
Für eine über mehrere Jahre gewachsene Instanz bedeutet das eine ehrliche Planung. Wenn heute Version 24 läuft und die Zielversion 30 ist, stehen fünf Upgrades an, jedes mit mehrstündigem Zeitfenster, Testdurchlauf und Backup. Das ist keine Aufgabe für einen Freitagnachmittag im Nebensatz. Nicht zuletzt deshalb raten erfahrene Betreiber dazu, den Versionsabstand dauerhaft klein zu halten und nicht erst dann zu reagieren, wenn das System bereits mehrere Generationen zurückliegt.
Vor dem Sprung: Voraussetzungen prüfen
Bevor überhaupt ein Update angestoßen wird, gehört der Blick auf die technischen Rahmenbedingungen. Dazu zählen in erster Linie die unterstützte PHP-Version und die benötigten Erweiterungen. Mit Version 27 endete die Unterstützung für PHP 7.4; seither ist 8.1 die Untergrenze im Bestand, und die Obergrenze wandert mit nahezu jedem Release nach oben. Wer heute noch auf einer 7er-Version unterwegs ist, kommt über Version 26 nicht hinaus.
Auch bei der Datenbank sind die Untergrenzen in Bewegung. MariaDB ab 10.3, MySQL 8 und PostgreSQL ab Version 12 sind die groben Eckpunkte der vergangenen Releases, exakte Angaben liefern die Release Notes der jeweiligen Version. Wer eine anspruchsvolle Instanz betreibt, sollte außerdem prüfen, ob ein In-Memory-Cache für das Dateisperren-Handling konfiguriert ist. Ohne einen entsprechenden Dienst wie Redis läuft Nextcloud zwar, aber bei gleichzeitigen Zugriffen auf dieselben Dateien wird es ungemütlich. Ein Upgrade ist ein guter Moment, um solche Altlasten mitzuerledigen.
Der dritte große Block ist die App-Landschaft. Jede Anwendung deklariert in ihrer Beschreibung eine Unter- und Obergrenze der kompatiblen Server-Versionen. Ist die Obergrenze niedriger als die Zielversion, wird die App während des Updates deaktiviert oder blockiert den Vorgang. In der Praxis sind es fast immer Drittanbieter-Apps, die ein Upgrade zum Scheitern bringen – und nicht der Kern. Eine Liste der installierten Apps vor dem Update zu erstellen und deren Vereinbarkeit zu prüfen, gehört deshalb zum Pflichtprogramm.
Nicht vergessen werden sollte auch der Platz auf der Festplatte. Während des Updates werden Dateien entpackt, Datenbanktabellen kopiert und unter Umständen Sicherungskopien angelegt. Wer mit einer randvollen Partition in den Vorgang geht, produziert einen halbfertigen Zustand, der sich nur mühsam reparieren lässt. Gleiches gilt für das Arbeitsspeicherlimit von PHP: Ein zu niedriger Wert führt zu Abbrüchen mitten in der Migration.
Die Wege zum Update
Für das eigentliche Upgrade stehen mehrere Verfahren zur Verfügung, die sich in Komfort, Kontrolle und Fehleranfälligkeit deutlich unterscheiden.
Da ist zum einen der mitgelieferte Web-Updater. Das ist ein separates Skript, das im Installationsverzeichnis abgelegt und über die Kommandozeile mit php updater.phar gestartet wird. Es prüft den Systemzustand, lädt das neue Paket, sichert das alte und führt die Migration aus. Der Updater ist der Standardweg für Instanzen, die aus einem klassischen Tarball oder einem Webhosting-Paket entstanden sind, und er erzeugt vor jedem Schritt automatisch eine Sicherung des Programmverzeichnisses.
Zum anderen lässt sich das Upgrade vollständig über die Kommandozeile durchführen – die häufigste Variante bei professionell betriebenen Installationen. Nach dem Austausch des Programmverzeichnisses und einer eventuellen Anpassung der Konfiguration wird occ upgrade aufgerufen. Dieses Kommando übernimmt die Datenbankmigrationen, aktualisiert die Anwendungen und schaltet die Instanz anschließend wieder frei. Der Vorteil: Man sieht die Ausgaben unmittelbar, kann Abbrüche besser einordnen und den Vorgang in ein Skript einbetten. Bei sehr großen Instanzen ist das der einzige wirklich praktikable Weg.
Daneben gibt es die Verteilung über Containerdatenbanken und Betriebssystempakete. Die offiziellen Docker-Images erscheinen in einer Apache- und einer FPM-Variante und werden über Tags angesprochen. Wichtig zu wissen: Das Image aktualisiert sich nicht von selbst. Wer den Tag nicht festnagelt, sondern auf latest verweist, holt sich beim nächsten Neustart unter Umständen eine neue Hauptversion ins Haus – ein Verhalten, das in Produktivumgebungen eigentlich niemand möchte. Hier gehört zwingend ein konkretes Tag in die Konfiguration.
Das Snap-Paket und die Container-Lösung All-in-One gehen einen anderen Weg und aktualisieren sich weitgehend selbsttätig, jeweils innerhalb ihres eigenen Kanals. Das ist bequem und für kleinere Installationen durchaus attraktiv, nimmt einem aber ein Stück Kontrolle über den Zeitpunkt. Wer eine Instanz mit definierten Wartungsfenstern betreibt, wird damit nicht glücklich. Der interessanteste Nebeneffekt beider Varianten: Sie legen vor dem Sprung einen Zustand ab, zu dem sich im Fehlerfall zurückkehren lässt. Dazu weiter unten mehr.
Schließlich existieren Distributionspakete, die Nextcloud über die Paketverwaltung des Betriebssystems installieren. Diese Varianten hinken in aller Regel mehrere Wochen oder Monate hinterher und sollten nur eingesetzt werden, wenn man mit diesem Verzug leben kann. Für die Kombination aus Aktualität und Kontrolle ist der klassische, selbst verwaltete Betrieb nach wie vor die verlässlichste Basis.
Der Ablauf in der Praxis
Unabhängig vom gewählten Verfahren folgt ein gelungenes Upgrade einem wiederkehrenden Muster. Die folgenden Schritte haben sich in der Praxis bewährt:
- Wartungsfenster ankündigen und alle Nutzer informieren. Ein halbfertiges System während der Arbeit ist schlechter als ein geplantes Zeitfenster am Abend.
- Backup anlegen – und zwar vollständig. Dazu gehören das Datenverzeichnis, die Datenbank, die Konfigurationsdatei, das Anwendungsverzeichnis sowie gegebenenfalls eigene Themes und Anpassungen.
- Wartungsmodus aktivieren. Das verhindert Schreibzugriffe während der Sicherung und sorgt dafür, dass Datenbank und Dateien halbwegs konsistent bleiben.
- Programmdateien austauschen beziehungsweise das neue Paket einspielen.
- Konfiguration prüfen und bei gewechselter PHP- oder Datenbankversion anpassen.
- Migration ausführen und die Ausgabe vollständig auf Fehler durchsehen.
- Wartungsmodus deaktivieren und die Instanz einem Funktionstest unterziehen.
- Nacharbeiten erledigen und den Vorgang dokumentieren.
Der wichtigste Punkt ist der zweite. Ein Backup, das nur aus dem Datenverzeichnis besteht, ist wertlos, wenn die Datenbank fehlt. Umgekehrt nützt eine Datenbanksicherung wenig, wenn die zugehörigen Dateien nicht mitgesichert wurden. Bei verschlüsselten Instanzen kommen außerdem die Schlüsseldateien hinzu, die im Datenverzeichnis liegen – wer sie vergisst, kann die Sicherung später nicht mehr verwenden.
Für das Datenbankbackup hat sich bei MySQL und MariaDB der Aufruf mit der Option für konsistente Transaktionen etabliert, bei PostgreSQL das klassische Dump-Verfahren. Wer beides nicht beherrscht, sollte es vor dem nächsten Upgrade lernen – oder jemanden hinzuziehen, der es beherrscht.
Nach dem Upgrade ist vor dem Upgrade
Ist die Migration durchgelaufen, beginnt die Nacharbeit. Ein Blick in den Status zeigt, ob die Instanz sauber läuft. Fehlende Datenbankindizes und -spalten, die während des Updates nicht angelegt werden konnten, lassen sich mit den entsprechenden Reparaturbefehlen nachziehen. Bei Installationen, die über mehrere Jahre gewachsen sind, kann außerdem eine Umstellung der Zählertypen im Dateicache sinnvoll oder sogar nötig sein. Diese Schritte laufen im Hintergrund und können bei großen Instanzen durchaus eine halbe Stunde oder länger dauern.
Ein weiterer Punkt ist der Dateiindex. Wenn nach dem Update Dateien fehlen, obwohl sie auf der Platte liegen, ist in der Regel die Zuordnungstabelle nicht auf dem aktuellen Stand. Ein vollständiger Scan über alle Nutzerkonten bringt das wieder in Ordnung – kostet aber Zeit und Last. Bei Instanzen mit mehreren Millionen Dateien sollte man diesen Schritt bewusst einplanen und nicht nebenbei anstoßen.
Nicht zuletzt lohnt sich der Blick auf die deaktivierten Anwendungen. Nach einem Hauptversionssprung sind regelmäßig einige Apps abgeschaltet, weil ihre Kompatibilitätsangaben noch nicht aktualisiert wurden. Wer sie benötigt, sollte die verfügbaren Aktualisierungen einspielen und sie anschließend gezielt wieder aktivieren. Apps, die dauerhaft nicht mehr gepflegt werden, gehören an dieser Stelle ausgemustert.
Typische Stolperfallen
Ein wiederkehrendes Muster zeigt sich bei fast jedem fehlgeschlagenen Upgrade. An erster Stelle stehen inkompatible Anwendungen. An zweiter Stelle Ressourcengrenzen: zu wenig Arbeitsspeicher für PHP, eine zu kurze Laufzeitgrenze, ein nicht geleerter Skript-Cache. Gerade der letzte Punkt wird häufig übersehen. Nach dem Austausch der Codedateien kann es passieren, dass der Zwischenspeicher noch alte Pfade oder Klassen enthält und die Instanz deshalb merkwürdige Fehler produziert, obwohl das Upgrade technisch sauber durchgelaufen ist. Ein Neustart der entsprechenden Dienste schafft hier meist schnell Abhilfe.
Ein dritter Klassiker sind Zeitüberschreitungen während der Datenbankmigration. Bei großen Installationen mit umfangreicher Dateitabelle kann ein einzelner Migrationsschritt Minuten dauern. Läuft er in eine Zeitbegrenzung, weil ein Proxy, ein Datenbanktreiber oder das Webinterface dazwischenfunkt, bleibt der Vorgang in einem Zwischenzustand stehen. Deshalb gilt: Die Migration gehört auf die Kommandozeile, nicht in den Browser.
Häufig unterschätzt wird außerdem die Rolle einer vorgelagerten Proxy- oder Lastverteilungsschicht. Fehlerhafte Kopfzeilen, eine fehlende Vertrauensstellung für die Proxy-Adressen oder eine abweichende Basisadresse führen nach dem Upgrade zu Weiterleitungen, die ins Leere laufen. Wer seine Instanz hinter einem Reverse Proxy betreibt, sollte diese Einstellungen vor dem Sprung kontrollieren – und nicht erst danach.
Große Instanzen, Datenbanken und Verschlüsselung
Bei Datenbanken mit mehreren hundert Gigabyte lohnt sich eine gesonderte Betrachtung. Ein Hauptversionswechsel des Datenbanksystems selbst – etwa von PostgreSQL 13 auf 15 – ist kein Vorgang, den man nebenbei erledigt, sondern ein eigenständiges Projekt mit eigenem Testdurchlauf. Ein klassisches Dump-und-Restore-Verfahren ist dabei oft die sicherste Variante, auch wenn es länger dauert als ein In-Place-Upgrade.
Bei Verschlüsselung wird es noch heikler. Wer die serverseitige Verschlüsselung nutzt, muss nicht nur Daten und Datenbank sichern, sondern auch die Schlüsselmaterialien. Ohne sie lässt sich eine Sicherung nicht zurückspielen. Die Ende-zu-Ende-Verschlüsselung, die Nextcloud für bestimmte Anwendungsfälle anbietet, stellt Administratorinnen und Administratoren ohnehin vor eine andere Aufgabe: Dort liegen die Schlüssel beim Nutzer, und der Server kann im Fehlerfall nicht aushelfen.
Auch bei Cluster-Installationen mit mehreren Anwendungsservern und gemeinsamem Dateisystem gibt es Besonderheiten. Die Programmdateien müssen auf allen Knoten gleichzeitig auf denselben Stand gebracht werden; wird ein Knoten vergessen, arbeitet er mit einem anderen Codestand auf derselben Datenbank. Das ist eine Konstellation, die man besser nicht allzu lange betreiben sollte.
Warum es kein Zurück gibt
Ein Upgrade lässt sich nicht rückgängig machen. Nextcloud unterstützt kein Downgrade. Der Grund liegt in den Datenbankmigrationen: Sie verändern Schemata, verschieben Daten und löschen unter Umständen Spalten, die in der Vorgängerversion noch gebraucht wurden. Ein Zurück auf eine ältere Version führt in aller Regel zu einer nicht mehr funktionsfähigen Instanz. Der einzige verlässliche Weg zurück ist das Zurückspielen der Sicherung – mit allen Konsequenzen für Daten, die seit dem Upgrade hinzugekommen sind.
Es gibt allerdings zwei Ausnahmen, die genau deshalb so praktisch sind. Das Snap-Paket und die Container-Lösung All-in-One behalten nach einem Update die vorherige Fassung vor, sodass sich der Vorgang mit einem einzelnen Befehl beziehungsweise einem Knopfdruck zurückdrehen lässt. Das ändert nichts daran, dass die Datenbank dann auf dem alten Stand ist – aber es erspart im Fehlerfall oft die komplette Wiederherstellung.
Wer mit virtuellen Maschinen arbeitet, denkt an dieser Stelle gern an Snapshots. Die sind schnell und bequem, bergen aber ein Risiko: Ein Speicherabbild, das während laufender Datenbanktransaktionen erstellt wurde, ist nicht zwangsläufig konsistent. Sauberer ist es, die Instanz vorher in den Wartungsmodus zu versetzen oder Datenbank und Dateien getrennt zu sichern. Ein Snapshot ist eine gute Ergänzung, aber kein Ersatz für ein geprüftes Backup.
Testumgebung statt Bauchgefühl
Die vielleicht wirksamste Maßnahme überhaupt ist eine Testumgebung. Sie muss nicht identisch dimensioniert sein, aber sie sollte mit derselben Datenbankversion, derselben PHP-Version und einer Kopie der realen Daten arbeiten. Ein Durchlauf dort zeigt nicht nur, ob die Migration fehlerfrei läuft, sondern liefert auch eine belastbare Schätzung der Dauer – ein Wert, der bei der Planung des Wartungsfensters oft mehr wert ist als jede Dokumentation.
Der Aufwand für eine solche Umgebung ist überschaubar, wenn man ihn einmal etabliert hat. Wer eine Kopie der Datenbank und einen Zugriff auf die Daten über ein gemeinsam genutztes Verzeichnis oder einen schnellen Dateitransfer organisieren kann, hat innerhalb weniger Stunden eine belastbare Testinstanz. Der Nutzen ist unmittelbar: Fehler zeigen sich dort, wo sie niemanden stören. In größeren Häusern hat sich dafür ein Vorgehen etabliert, bei dem zwei Umgebungen abwechselnd die Produktivrolle übernehmen – die alte bleibt als Rückfallebene stehen, bis die neue sich bewährt hat.
Clients, Apps und die Kompatibilitätsfrage
Ein Aspekt, der bei der Planung leicht untergeht, ist die Client-Seite. Desktop-Clients und mobile Apps werden unabhängig vom Server entwickelt und gepflegt. Zwar achtet das Projekt darauf, ältere Clients nicht vorschnell auszusperren, doch irgendwann endet die Unterstützung. In den Systemeinstellungen lässt sich eine Mindestversion für Desktop-Clients festlegen; ist sie gesetzt, verweigern ältere Clients die Synchronisation. In Umgebungen mit zentral verwalteten Arbeitsplätzen sollte man diesen Punkt rechtzeitig mit der IT-Abteilung besprechen, sonst steht nach dem Serverupgrade die halbe Belegschaft mit Fehlermeldungen da.
Bei den Anwendungen gilt Ähnliches. Die Kompatibilitätsangabe einer App ist eine Erklärung des jeweiligen Entwicklers, keine Garantie. Wer auf Drittanbieter-Lösungen angewiesen ist, sollte vor dem Sprung beim Anbieter nachfragen oder in der Vorschauversion testen. Das gilt besonders für Anwendungen, die tief in die Datenstruktur eingreifen – etwa solche, die eigene Datenbanktabellen anlegen oder auf die Dateiverwaltung zugreifen.
Auch die integrierten Komponenten für Videokonferenzen und Office-Bearbeitung sind eigene Anwendungen mit eigenen Versionsständen. Wer Collabora oder OnlyOffice eingebunden hat, muss die Kompatibilität der jeweiligen Fassung mit der neuen Serverversion prüfen. Hier haben sich in der Vergangenheit immer wieder Überraschungen ergeben, die sich mit einem Blick in die Dokumentation vermeiden ließen.
Nicht verwechseln: die Versions-App für Dateien
Wo wir schon beim Thema sind – der Begriff „Versionen“ hat in Nextcloud noch eine zweite Bedeutung, die mit dem Server-Release nichts zu tun hat. Gemeint ist die Dateiversionsverwaltung: Jede Änderung an einer Datei legt eine ältere Fassung beiseite, sodass sich frühere Stände wiederherstellen lassen. Das ist eines der praktischsten Merkmale des Systems und gleichzeitig eine der unterschätzten Größen im Speicherverbrauch.
Wie viele Versionen aufbewahrt werden, regelt die Instanz über eine Aufbewahrungsrichtlinie. Grundsätzlich lässt sich einstellen, ob Versionen automatisch nach Zeit oder nach Anzahl gelöscht werden sollen. In der Praxis hat sich eine Mischung bewährt: kurzfristig viele Stände, langfristig wenige. Wer hier keine Vorgaben macht, findet nach ein paar Jahren einen Datenbestand vor, der zu einem erheblichen Teil aus Altversionen besteht.
Interessant ist der Zusammenhang mit dem Upgrade: Bei einem Versionssprung können Aufräumroutinen angestoßen werden, die alte Dateiversionen oder gelöschte Objekte entfernen. Wer den Speicherbedarf vorher grob kennt, kann hinterher besser einschätzen, ob die Zahlen plausibel sind. Für Administratoren gibt es Kommandos, um den Versionsbestand gezielt zu bereinigen – etwa beim Löschen eines Nutzerkontos oder beim Umzug auf einen anderen Speicher. Auch die Anbindung an Objektspeicher bringt eigene Regeln mit sich, weil dort unter Umständen eine zweite Ebene der Versionierung greift, die außerhalb von Nextcloud liegt. Wer beides kombiniert, sollte sich die resultierende Belegung genau ansehen.
Fazit: kleine Schritte, feste Zeiten, geprüfte Sicherungen
Die Versionsverwaltung von Nextcloud ist kein Buch mit sieben Siegeln, aber sie verlangt Disziplin. Wer den Abstand zwischen installierter und aktueller Version klein hält, muss nie mehrere Hauptversionen in einem Rutsch nachholen. Wer den Kanal production wählt, bekommt Neuerungen etwas später, dafür mit weniger Überraschungen. Wer vor jedem Sprung sichert, testet und die App-Landschaft prüft, wird die meisten Probleme vermeiden, die anderen den Sonntag verderben.
Und noch ein Punkt, der in technischen Diskussionen gern untergeht: Ein Update ist kein Selbstzweck. Neue Funktionen sind angenehm, aber der eigentliche Grund für regelmäßige Aktualisierungen sind Sicherheitskorrekturen. Eine Instanz, die zwei Jahre lang nicht angefasst wurde, ist kein stabiles System, sondern ein ungepflegtes. Die Frage ist also nicht, ob man upgradet, sondern wann – und mit welcher Vorbereitung.