Wer eine Nextcloud betreibt, kennt das Ritual: Erst die Nachricht von einer neuen Version, dann das kurze Aufatmen, weil es wieder Sicherheitsupdates gibt – und schließlich die leise Sorge, ob der Update-Prozess diesmal reibungslos durchläuft. Die meisten Admins haben irgendwann ein Skript gebaut, das die nächste Version herunterlädt, entpackt und den Update-Befehl anstößt. Andere verlassen sich auf die manuelle Update-Seite im Admin-Panel. Beides funktioniert, keine Frage. Aber es gibt einen Unterschied zwischen „funktioniert“ und „läuft zuverlässig im Hintergrund“. Genau darum geht es hier: Wie bekommt man Nextcloud Updates automatisch erledigt, ohne dass man nachts um drei geweckt wird?
Die Frage ist nicht neu, aber sie hat in den letzten Jahren an Dringlichkeit gewonnen. Nextcloud ist längst kein einfaches File-Sharing-System mehr, sondern eine Plattform für Kollaboration, Videokonferenzen, Groupware und sogar Office-Alternativen. Je mehr Erweiterungen und Apps in einer Instanz stecken, desto komplexer wird der Update-Prozess. Ein Blindflug ist dann keine Option mehr. Automatisierung ist also keine Spielerei, sondern ein Stück Betriebsdisziplin.
Warum Updates bei Nextcloud so kritisch sind
Nextcloud-Veröffentlichungen folgen einem festen Rhythmus. Alle paar Monate erscheint eine neue Minor-Version, dazwischen gibt es Sicherheits-Releases. Das klingt nach einem normalen Software-Lebenszyklus. Aber die Praxis zeigt: Gerade bei Nextcloud hängt vieles daran, dass Updates rechtzeitig und vor allem in der richtigen Reihenfolge eingespielt werden. Wer eine Version überspringt, der steht schnell vor dem nächsten Update mit einer Mauer aus Fehlermeldungen. Das Update-Skript von Nextcloud verweist dann gern auf die Notwendigkeit, zunächst die Zwischenstände zu installieren.
Das ist einer der Gründe, warum sich Automatisierung nicht nur auf das Einspielen der neuesten Dateien beschränken sollte. Ein automatisches Update muss auch den Pfad kennen: von der installierten Version über alle notwendigen Zwischenstände bis zur Zielversion. Genau hier scheitern viele selbstgebaute Skripte, weil sie nur das aktuelle Release herunterladen und darauf hoffen, dass die Datenbank-Migration schon irgendwie klappt. Tut sie manchmal nicht.
Hinzu kommt die Sicherheitsfrage. Die Nextcloud-Community ist groß, das Interesse von Angreifern ebenfalls. Immer wieder tauchen Schwachstellen auf, die in der öffentlich zugänglichen Versionsgeschichte nachvollzogen werden können. Wer seine Instanz nicht zeitnah aktualisiert, schließt die digitale Tür nicht nur einen Spaltbreit, sondern lässt sie im schlimmsten Fall sperrangelweit offen. Automatische Updates sind deshalb kein Komfort, sondern eine Frage der Hygiene im Netz.
Der Update-Mechanismus im Inneren
Um Automatisierung sinnvoll zu planen, sollte man verstehen, was beim Update eigentlich passiert. Nextcloud bringt eigene Werkzeuge mit, zentral ist der occ-Kommandozeilenbefehl. Über den werden Datenbank-Migrationen angestoßen, App-Updates durchgeführt und der Upgrade-Zustand geprüft. Das Web-Interface nutzt im Kern dieselben Mechanismen, nur eben mit ein paar Klicks drumherum.
Ein klassisches manuelles Update sieht so aus: Web-Server im Wartungsmodus, alte Version durch neue ersetzen, Berechtigungen prüfen, occ upgrade ausführen, Apps aktualisieren, Wartungsmodus wieder beenden. Das ist nicht sonderlich kompliziert, aber es gibt erstaunlich viele Stellschrauben, an denen etwas schiefgehen kann. Beispielsweise der Speicherort von Data-Verzeichnis und Konfiguration, oder die Frage, ob PHP-FPM einen Opcode-Cache laufen hat, der nach einem Update geleert werden muss.
Bei einem automatischen Update verschiebt sich die Verantwortung vom Menschen auf den Prozess. Der Prozess muss also sämtliche Fehlerquellen kennen und behandeln. Das fängt beim Herunterladen der richtigen Archiv-Datei an und hört beim sauberen Beenden des Wartungsmodus noch lange nicht auf. Wer glaubt, ein einziges Bash-Skript mit wget und unzip reicht aus, der unterschätzt die Sache.
occ, Cron und der Wartungsmodus
Die Grundlage jeder Automatisierung ist zuverlässiges Skripting um occ herum. Der Befehl arbeitet im Kontext des Web-Server-Benutzers, was bei Installationen unter Debian oder Ubuntu gelegentlich zu Verwirrung führt, weil man als root nicht einfach drauflosarbeiten kann. Die Konsole zwischen sudo -u www-data und dem normalen Shell-Zugriff ist ein Klassiker unter frischgebackenen Nextcloud-Admins. Ein automatisches Update muss also nicht nur wissen, welcher Befehl ausgeführt wird, sondern auch als welcher Benutzer.
Dasselbe gilt für den Wartungsmodus. Die Weboberfläche wartet nicht darauf, während der Administrator im Hintergrund Dateien austauscht. Deshalb muss ein Skript den Modus explizit ein- und ausschalten: occ maintenance:mode –on beziehungsweise –off. Es ist erstaunlich, wie oft dieser Schritt vergessen wird. Das Ergebnis sind wirre Fehlermeldungen, die mit dem eigentlichen Update gar nichts zu tun haben.
Ein interessanter Aspekt ist, dass Nextcloud zwischen zwei Arten von Updates unterscheidet. Da ist zum einen der Upgrade-Prozess des Kerns, zum anderen die Aktualisierung der Apps. Beide laufen inkompatibel zueinander, wenn man sie nicht in der richtigen Reihenfolge anstößt. Die App-Datenbank kennt die Versionen, und wenn der Kern schon weiter springt als die Apps, kann es zu Konflikten kommen. Deshalb sorgt die Nextcloud-Update-Logik selbst dafür, dass nach einem Kern-Upgrade die Apps neu migriert werden. In der Praxis bedeutet das: Wer den Upgrade-Befehl korrekt abarbeitet, bekommt die App-Aktualisierung meistens als Dreingabe.
Automatische Updates mit Skripten und Cron
Der naheliegendste Weg zu automatisierten Updates ist ein Cron-Job, der die neuen Versionen prüft und ein Update durchführt. Das ist auf den ersten Blick simpel, auf den zweiten Blick aber ein kleines Projekt. Man muss den offiziellen Update-Kanal abfragen, die aktuelle Version mit der installierten vergleichen, den Download einspielen und den Upgrade-Vorgang starten. Und all das sollte idealerweise nur zu Zeiten passieren, in denen die Instanz nicht stark benutzt wird.
Wer Nextcloud nicht selbst hostet, sondern eine der gemanagten Lösungen nutzt, hat es einfacher. Doch wer die Kontrolle behalten will, kommt um ein eigenes Skript nicht herum. Dabei zeigt sich, dass es weniger um das Skript selbst geht als um die Absicherung drumherum. Bevor ein automatisches Update überhaupt startet, muss ein Backup existieren. Das ist keine Frage des Vertrauens in die Software, sondern schlicht gesunder Menschenverstand. Ein Backup, das nicht regelmäßig getestet wird, ist bloß eine Beruhigungspille – das gilt doppelt für automatische Updates.
Ein gutes Update-Skript müsste also ungefähr so vorgehen: Backup der Datenbank und des Data-Verzeichnisses, Herunterladen der neuen Nextcloud-Version, Entpacken in ein temporäres Verzeichnis, Abgleich der Dateien, Aktivierung des Wartungsmodus, Ausführen von occ upgrade, Prüfen der App-Listen, Deaktivieren des Wartungsmodus. Dazu kommen unwägbare Dinge wie ausreichend Plattenplatz, freier Speicher für PHP-Prozesse und ein Blick auf die PHP-Version, die bei neueren Nextcloud-Versionen nicht mehr dieselbe sein muss wie beim letzten Update.
Eigenartigerweise wird genau dieser letzte Punkt häufig unterschätzt. Nextcloud 30 setzt PHP 8.2 oder 8.3 voraus, andere Versionen haben andere Mindestanforderungen. Ein automatisches Skript muss also nicht nur die Nextcloud-Version prüfen, sondern auch die Systemumgebung. Wer das ignoriert, bekommt eine Aktualisierung, die das gesamte System in einen halb aktualisierten Zustand versetzt.
Was taugen fertige Skripte?
Die Community hat im Laufe der Jahre einige Skripte hervorgebracht, die das Nextcloud-Update automatisieren. Manche sind gut, viele sind Einzelanfertigungen für die eigene Umgebung. Ein bekanntes Beispiel ist das „Update Script for Nextcloud“, das inoffiziell auf GitHub kursiert und in diversen Forumsbeiträgen auftaucht. Es ist eine solide Basis, aber keine Garantie. Denn sobald Nextcloud die Verzeichnisstruktur ändert oder occ neue Befehle bekommt, muss das Skript angepasst werden. Das ist ein Pflegeaufwand, den man einplanen muss.
Interessanterweise ist Nextcloud selbst seit einiger Zeit dabei, den automatischen Update-Prozess zu verbessern. Es gibt Überlegungen, den Update-Mechanismus direkt in die Software zu integrieren, ähnlich wie bei WordPress, wo man mit einem Klick im Admin-Bereich auf „Aktualisieren“ drückt und das System die Arbeit erledigt. Bei Nextcloud ist das bisher nur für die Web-Oberfläche im Rahmen des Online-Update-Assistenten möglich, und der wird gerade von Administratoren eher selten verwendet. Das liegt vor allem an den Hosting-Umgebungen, in denen Nextcloud läuft. Viele Provider geben die Dateirechte nicht so frei, dass der Web-Server eigenmächtig den Core ersetzen könnte. Und bei eigenen Root-Servern ist das Misstrauen gegenüber einem Skript, das im Web-Kontext läuft, ebenfalls groß. Dieses Misstrauen ist nicht unberechtigt, schließlich hat ein Web-Server auf dem Dateisystem eines Servers nichts zu suchen.
Wer also zu einer echten Automatisierung kommen will, muss an der einen oder anderen Stelle ohnehin eigene Skripte schreiben oder sich auf Werkzeuge wie Ansible stützen. Und Ansible ist in diesem Zusammenhang tatsächlich eine gute Wahl, weil es sich nicht nur um den Dateiaustausch kümmert, sondern auch um die Server-Variablen: PHP-Version, Module, Berechtigungen, Cron-Einträge. Eine Playbook-Lösung ist wartbar und lässt sich in größere Deployment-Prozesse integrieren.
Container und Orchestrierung
Die Frage nach automatischen Updates stellt sich noch einmal ganz anders, wenn Nextcloud als Container läuft. Dann wird nicht eine bestehende Installation aktualisiert, sondern ein Container-Image erneuert. Das Prinzip ist konsequent: Alles, was nicht zu den persistenten Daten gehört, wird ausgetauscht. Die Daten liegen in Volumes, die Konfiguration in der Environment oder in einer Config-Datei – und der Kern ist reines ablauffähiges Padding. Genau das macht Container-Updates grundlegend anders und in vielerlei Hinsicht angenehmer.
Mit Docker Compose ist ein Update kaum mehr als ein docker compose pull gefolgt von docker compose up -d. Das lässt sich ohne Weiteres in einen Cron-Job schreiben oder an ein CI-System übergeben. Die Datenbank-Migration übernimmt der Nextcloud-Container selbst, sofern die Umgebungsvariablen richtig gesetzt sind. In der Praxis ist der Ablauf häufig unspektakulär, was man von manuellen Upgrades nicht behaupten kann.
Ein kleines Problem taucht auf, wenn man die Container-Images nicht selbst kontrolliert. Die offiziellen Images des Nextcloud-Projekts sind solide, aber es gibt auch zahlreiche Drittanbieter-Images, die mit zusätzlichen Apps oder Systemwerkzeugen ausgestattet sind. Diese Images sind oft gut gemeint, aber ein Sicherheitsrisiko, wenn sie nicht regelmäßig aktualisiert werden. Automatische Updates auf Basis fremder Images sind daher mit Vorsicht zu genießen – man muss wissen, was man bezieht. Nicht zuletzt kommt hinzu, dass Nextcloud selbst innerhalb eines Containers per occ benachrichtigt werden muss, nachdem das Image gewechselt wurde. Das passiert zwar meist beim Start automatisch, aber es gibt immer wieder Versionen, bei denen manuelles Nachhelfen nötig war.
Wer Kubernetes im Hintergrund hat, kann Updates über Helm-Charts oder Operatoren abwickeln. Das ist dann schon eher ein orchestrierter Prozess, bei dem die Rolling-Update-Mechanik der Plattform dafür sorgt, dass nicht alle Nutzer gleichzeitig abgeschnitten werden. Doch Kubernetes ist für Nextcloud kein typischer Einsatzzweck. Man sieht es öfter in größeren Unternehmensumgebungen, in denen sowieso alles auf der Plattform läuft. Für den normalen Admin ist Docker Compose die realistischere Automatisierungsbasis.
Watchtower und andere Container-Updater
Ein Werkzeug wie Watchtower überwacht laufende Container und ersetzt sie durch neuere Versionen. Das funktioniert auf den ersten Blick gut, hat aber in Kombination mit Nextcloud einen Haken: Nextcloud braucht für ein Update mehr als nur einen neuen Container. Es müssen Datenbank-Migrationen durchgeführt werden, die App-Kompatibilität muss geprüft werden, und der Wartungsmodus ist bei einem automatischen Container-Tausch nicht vorgesehen. Ein blindes Ziehen eines neuen Images kann bei Nextcloud zu einer kurzen, aber heftigen Fehlerwelle führen, weil die Datenbank schon auf dem neuen Stand ist, während die Dateien noch die alten sind – oder umgekehrt.
Das muss nicht jedes Mal schiefgehen, aber es ist ein Risiko. Ein gut konfigurierter Watchtower-Container kann zwar so eingestellt werden, dass er nur zu bestimmten Zeiten läuft und auf Healthchecks achtet, doch die eigentliche Kontrolle über den Upgrade-Prozess bleibt beim Betreiber. Der sollte sicherstellen, dass der Watchtower nicht während des laufenden Betriebs einfach so ein neues Image einspielt. Andernfalls ist das automatische Update eher Glücksspiel.
Besser fährt man, wenn man das Image-Update von einer Logik begleitet, die den Nextcloud-spezifischen Ablauf kennt. Ein elegantes Muster ist ein Skript, das zunächst den Watchtower deaktiviert, dann das Backup anfertigt, danach ein neues Container-Image zieht und den Container neu startet, danach occ upgrade im laufenden Container ausführt und schließlich den Watchtower wieder aktiviert. Auf diese Weise kombiniert man die Vorteile der containerisierten Software mit der Notwendigkeit eines kontrollierten Update-Pfads.
Der Schritt-für-Schritt-Blick auf den aktualisierten Betrieb
Es ist schon vorgekommen, dass ein automatisches Update durchlief und das System am Ende immer noch nicht wie erwartet funktionierte. Wenn Nextcloud nach dem Update eine leere Seite zeigt oder sich nicht mehr einloggen lässt, ist der Fehler meistens im Detail verborgen. Ein Klassiker ist der PHP-Cache. Wer mit OPcache oder APCu arbeitet, muss nach einem Update dafür sorgen, dass der Cache geleert wird. In Container-Umgebungen passiert das durch den Neustart, auf klassischen Systemen aber eben nicht. Ohne diesen Schritt laufen oft veraltete Code-Pfade weiter, was bei einem Dateiaustausch zu seltsamen Mischzuständen führt.
Ein weiterer Klassiker sind die Verzeichnisberechtigungen. Nextcloud ist da nicht pingelig, aber falsche Eigentümer auf den neuen Dateien führen dazu, dass der Web-Server nicht schreiben kann. Das fällt meistens nicht direkt auf, sondern erst bei der App-Konfiguration oder beim Hochladen von Dateien. Ein automatisiertes Update sollte deshalb nach dem Entpacken eine Art „Repair-Occ“ ausführen oder zumindest eine Berechtigungsroutine anstoßen. Nextcloud hat dafür occ maintenance:repair, ein Befehl, der nicht nur für Notfälle da ist, sondern auch nach Upgrades verwendet werden sollte.
Nicht zuletzt muss die Datenbank nach einem Update korrekt migriert sein. occ upgrade ist hier das Zauberwort. Dabei zeigt sich gelegentlich, dass die Migration nur mit einem separaten Schritt abgeschlossen wird, etwa indem man occ db:add-missing-indices ausführt oder die OCC-Datenbank-Überprüfung anstößt. Die meisten dieser Schritte macht die Web-Oberfläche automatisch, aber bei einem automatischen Update in der Kommandozeile sollte man sie explizit einplanen.
Die Frage der Häufigkeit
Wie oft sollte ein automatisches Update laufen? Täglich? Wöchentlich? Viele Admins neigen dazu, die Intervalle möglichst kurz zu setzen, aus Angst, etwas zu verpassen. Aber bei Nextcloud ist die Antwort nicht ohne Weiteres „so oft wie möglich“. Die Software ist komplex, und ein Update in der Nacht, während vielleicht noch ein Backup läuft, kann schiefgehen. Zudem veröffentlichen die Nextcloud-Entwickler nicht jeden Tag neue Versionen; in der Regel ist ein wöchentlicher Abruf des Update-Kanals mehr als ausreichend. Sicherheits-Hotfixes kommen dann doch in unregelmäßigen Abständen, und dafür ist ein wöchentlicher Cron-Job immer noch früh genug.
Wenn man automatisierte Updates nachts ausführt, sollte man die Ausführungszeit nicht mit anderen Wartungsfenstern kollidieren lassen. Das Monitoring sollte jede Aktion protokollieren, damit man im Zweifel nachvollziehen kann, was schiefgelaufen ist. Ein Update, das sich über Stunden still in die Länge zieht, ist meist ein Zeichen für eine unzureichende Systemleistung oder ein Datenbankproblem. Da hilft es ungemein, wenn das Skript bereits eine Zeitbegrenzung kennt und bei Überschreitung Alarm schlägt.
Und dann ist da noch die Frage, welche Version man überhaupt treffen will. Nextcloud hat ein abgestuftes Release-Modell. Die neueste Funktionen-Version ist oft spannend, aber nicht immer die stabilste für den Produktivbetrieb. Automatische Updates tuen gut daran, auf eine der letzten Minor-Versionen eines Versionszweigs zu zielen, anstatt auf jedes neue Feature-Release zu springen. Das klingt altmodisch, spart aber unnötige Überraschungen. Wer dagegen direkt auf die neueste Version aktualisiert, trägt ein höheres Risiko, gleichzeitig weniger dokumentierte Fehler auszugleichen. Wer Nextcloud automatisch auf die neueste Hauptversion bringt, betreibt eine Form von Tagesgeschäft, die man verantwortungsvoll nur mit einer sehr guten Testumgebung machen sollte.
Enterprise und Unternehmensumgebungen
Für Unternehmen bietet Nextcloud eine Enterprise-Edition an, die unter anderem länger unterstützte Versionen und einen direkten Support-Kanal umfasst. In dieser Umgebung sind automatische Updates nicht weniger relevant, aber sie werden anders gehandhabt. Während der Betreiber einer kleinen Instance ein Skript in die crontab wirft, ist im Enterprise-Umfeld der geplante Rollout üblich. Man testet in einer Staging-Umgebung, genehmigt das Update-Release und spielt es dann auf die Produktivumgebung auf. Das mag bürokratisch klingen, ist aber die einzige Methode, die sicherstellt, dass ein automatisch eingespieltes Update nicht doch eine unerwartete Nebenwirkung auf andere Systeme hat.
Nextcloud selbst liefert in der Enterprise-Variante das Werkzeug „Nextcloud Enterprise“, das ebenfalls mit occ zusammenarbeitet und den Update-Pfad unterstützt. Automatisierung bedeutet in diesem Kontext weniger „cronjob anwerfen“, sondern vielmehr „Release-Prozess im Rahmen eines Configuration-Managements“. Tools wie Ansible oder Puppet übernehmen die Verteilung, das Monitoring die Erfolgskontrolle. Das ist zwar aufwendiger, aber setzt genau voraus, was automatische Updates auch im kleinen Maßstab brauchen: Verlässlichkeit und Nachvollziehbarkeit.
Wer Prozesse plant, sollte bedenken, dass Nextcloud eine heterogene Struktur mitbringt: Da sind externe Speicher, LDAP/SSO-Anbindungen, Collabora- oder OnlyOffice-Integrationen. Jede dieser Komponenten hat eine eigene Update-Dynamik und kann die Nextcloud-Automatisierung ausbremsen. Ein automatisches Update von Nextcloud allein ist deshalb nicht genug; man muss auch die angedockten Dienste mit in den Rhythmus aufnehmen. Dabei zeigt sich, dass die größten Schwierigkeiten nicht in der Nextcloud selbst liegen, sondern im Umfeld.
Fehlerquellen und schmerzhafte Erfahrungen
Man sollte nicht so tun, als wären automatische Updates eine reine Erfolgsgeschichte. Es gibt genug Beispiele, wo ein automatisiertes Skript ein System in einen Zustand versetzt hat, mit dem niemand gerechnet hat. Etwa, wenn eine Datenbank-Migration zu viel Zeit in Anspruch nimmt und ein Timeout dafür sorgt, dass der Prozess abgebrochen wird. Oder wenn die neue Version alte App-Abhängigkeiten nicht mehr erfüllt und die Oberfläche nach der Aktualisierung nur noch Fehlermeldungen anzeigt. In solchen Fällen ist der Retter oft ein gutes Backup. Deshalb gehört zu einer Automatisierung rechtlich und logisch immer das Backup dazu – sonst ist es keine Automatisierung, sondern eine Mutprobe.
Eine oft unterschätzte Fehlerquelle ist die Ausführung von updaten im Web-Modus. Nextcloud bietet seit einiger Zeit an, den Upgrade-Prozess direkt über die Web-Oberfläche auszulösen. Das ist praktisch, aber eben nicht ohne Sicherheitsbedenken. Wenn ein Angreifer Zugriff auf das Admin-Panel bekommen hat, kann er damit unter Umständen eigenen Code in den Nextcloud-Prozess einschleusen. Deshalb raten Sicherheitsexperten dazu, Web-Updates in Produktionsumgebungen zu deaktivieren und stattdessen auf occ zu setzen. Das ist eine klare Meinung, aber sie ist durch die langjährige Praxis gestützt.
Eine Empfehlung für die Praxis
Was also soll man tun? Die naheliegende Antwort lautet: ein Skript, das die offizielle JSON-API von Nextcloud für die Versionsprüfung nutzt und dann einen geregelten Ablauf anstößt. Dafür braucht man keine großen Heldenlieder, sondern einigermaßen sauberes Bash oder Python. Als Aufhänger könnte man sich an den offiziellen Nextcloud-Dokumentationen orientieren und die dort beschriebenen Schritte nachbauen. Einige Administratoren haben solche Skripte veröffentlicht, und man kann ihre Arbeit problemlos als Grundlage nehmen.
Der Aufbau eines solchen Skripts sieht konkret so aus:
Zunächst sollte geprüft werden, ob die Instanz sich überhaupt in einem guten Zustand befindet. Das geht mit occ status. Danach schaut man auf die Versions-API auf download.nextcloud.com/community/releases/ und vergleicht die Versionsnummern. Wenn eine neue Version vorliegt, legt das Skript den Wartungsmodus fest, sichert die Daten, lädt die neue Version herunter, verschiebt die Verzeichnisse und führt occ upgrade aus. Am Ende wird der Wartungsmodus beendet und eine Benachrichtigung per E-Mail oder über einen Messenger versandt. So trivial das klingt, die einzelnen Schritte sind anfällig für Tücken, die sich erst im Praxistest zeigen.
Ein interessanter Aspekt ist die Forderung nach einer sog. „unattended“-Installation, die ohne menschliche Eingriff auskommt. Die gibt es bei Nextcloud offiziell bislang nicht, und das ist auch gut so. Eine Software, die Datenbanken migriert und Dateien überträgt, braucht eine definierte Umgebung und keinen Schnellschuss. Wer das Unattended-Update um jeden Preis will, muss den Prozess selbst so weit gehärtet haben, dass er keine Rückfragen stellt. Das ist anspruchsvoll, aber bei etwas Sorgfalt machbar.
Monitoring und Rückfalloptionen
Ein automatisches Update ohne direktes Monitoring ist wie ein Rauchmelder ohne Batterie. Man sollte also von Anfang an mitdenken, wie man den Ausgang des Updates prüft. Nextcloud selbst liefert dafür die Status-Seite und die System-Informationen. Ein Skript kann nach dem Upgrade die Startseite mit einem HTTP GET abfragen und prüfen, ob der HTTP-Status 200 zurückkommt und ob die Seite nicht leer ist. Ein noch besseres Signal ist der Blick in die Logdateien, insbesondere in die Owncloud/Nextcloud-Logs. Wer hier keine neuen Fehler eintragen sieht, kann dann – und nur dann – den Wartungsmodus beenden.
Die Rückfalloption ist und bleibt das Backup. Wer automatisch aktualisiert, sollte sich im Klaren darüber sein, dass der schlimmste Fall nicht das fehlgeschlagene Update ist, sondern das unbemerkte fehlgeschlagene Update, das nach Tagen erst entdeckt wird. Insofern ist es keine Schande, nach dem Update eine kurze Testsequenz durchzuspielen: Einloggen, Datei hoch- und herunterladen, App öffnen. Das lässt sich mit einfachen HTTP-Requests oder einem Browser-Automatisierungs-Tool erledigen. Erst wenn diese Prüfungen erfolgreich sind, sollte das Skript den Betrieb offiziell wieder freigeben.
Fazit und Ausblick
Nextcloud-Administratoren stehen vor der Aufgabe, Updates so zu automatisieren, dass sie nicht zur Belastung werden. Die Software ist robust, aber nicht unfehlbar. Wer einmal eine Nacht damit verbracht hat, eine kaputte Instanz wiederherzustellen, wird die Wichtigkeit eines sauberen Prozesses verstehen. Automatische Updates sind dafür eine vernünftige Lösung, sofern sie nicht blind einzelne Schritte überspringen.
In der nahen Zukunft wird Nextcloud vermutlich selbst bessere Mechanismen für automatische Updates mitbringen. Bis dahin bleibt es eine Aufgabe der Administratoren, den Prozess zu beherrschen. Und genau das ist auch gut so, denn die Beschäftigung mit den Update-Mechanismen führt unweigerlich zu einem besseren Verständnis des gesamten Systems. Wer dieses Verständnis hat, wird mit Nextcloud auch dann klarkommen, wenn mal wieder ein Update nervt.