„`html
Wenn die Cloud schweigt: Warum jedes Nextcloud-Team ein Notfallhandbuch braucht
Es ist Montagmorgen, die erste Tasse Kaffee dampft, und statt des gewohnten Dashboards erscheint ein nackter 503-Fehler. Der Nextcloud-Server antwortet nicht. Kein Login, keine Dateien, kein Kalender – das digitale Rückgrat einer ganzen Organisation ist verschwunden. Solche Momente sind der Albtraum jedes Administrators, und sie kommen häufiger vor, als man denkt. Ob ein fehlgeschlagenes Update, ein defektes RAID, ein versehentlich gelöschter Datenbankeintrag oder ein kryptischer Konfigurationsfehler – die Ursachen sind vielfältig, die Folgen oft identisch: Stillstand, Frustration und im schlimmsten Fall Datenverlust. Dabei zeigt sich: Wer heute auf Nextcloud setzt, also auf eine der am weitesten verbreiteten Open-Source-Plattformen für Filesharing, Kommunikation und Collaboration, der betreibt nichts Geringeres als eine kritische Infrastruktur. Ein Ausfall trifft nicht nur die IT-Abteilung, sondern jedes Teammitglied, jede Abteilung, jeden Kunden. Die Frage ist nicht, ob ein Notfall eintritt, sondern wann – und wie vorbereitet man dann ist. Genau hier setzt das an, was man ein Nextcloud-Notfallhandbuch nennen könnte: eine strukturierte Sammlung von Prozessen, Checklisten und Wiederherstellungsplänen, die im Ernstfall den Unterschied zwischen einem halbstündigen Eingriff und einer tagelangen Katastrophe ausmacht. Ein interessanter Aspekt ist, dass viele Betreiber zwar regelmäßig Backups erstellen, aber kaum einen vollständigen Recovery-Durchlauf getestet haben. Das ist ungefähr so, als würde man einen Feuerlöscher kaufen, ihn aber nie aus der Halterung nehmen. Nicht zuletzt geht es also um Disziplin, um Wiederholbarkeit und darum, das eigene System so zu dokumentieren, dass auch ein vertretender Kollege oder jemand, der das Setup zum ersten Mal sieht, im Ernstfall handeln kann.
Warum ein Notfallhandbuch mehr ist als eine Liste von Kommandos
Wer Nextcloud betreibt – ob als Single-Node-Instanz auf einem VPS, als Docker-Stack hinter einem Reverse-Proxy oder als hochverfügbaren Cluster mit mehreren Datenbankknoten – der kennt die typischen Handgriffe: occ-Befehle, Datenbank-Dumps, rsync-Skripte. Aber ein Handbuch im eigentlichen Sinne ist kein Memo, das auf dem Schreibtisch verstaubt. Es ist ein lebendes Dokument, das mit dem System wächst und sich verändert. Ein Redakteur mit technischem Hintergrund würde sagen: Es ist die Schnittstelle zwischen Betriebswissen und echter Ausfallsicherheit. Dazu gehört, dass man nicht nur die „Was-tun-wenn“-Szenarien beschreibt, sondern auch die Vorbedingungen klärt. Welche Daten sind wirklich kritisch? Wie schnell muss die Wiederherstellung erfolgen? Welche Kompromisse sind akzeptabel – darf die Synchronisation zum Beispiel für eine Stunde ausfallen, oder müssen alle Clients sekundenschnell wieder verbunden sein? Diese Fragen lassen sich nicht pauschal beantworten, aber sie bestimmen die Priorität jedes Wiederherstellungsschritts. Ein gutes Handbuch unterscheidet deshalb zwischen unterschiedlichen Szenarien: dem leichten „Da stimmt was mit der Datenbank“ und dem schweren „Das Rechenzentrum steht unter Wasser und die letzte Sicherung ist drei Tage alt“. Es berücksichtigt auch, dass nicht jeder Fehler sofort erkannt wird. Manche Probleme – etwa eine schleichende Korruption der Dateistruktur oder ein undichter Speicherbackend – zeigen sich erst Tage später. Dann hilft kein Schnellschuss, sondern nur ein strukturiertes Vorgehen, das Forensik mit Wiederherstellung verbindet.
Ich habe selbst erlebt, wie ein Administrator nach einem fehlgeschlagenen Update stundenlang versuchte, die Nextcloud-Datenbank per Hand zu reparieren, weil er kein aktuelles Backup hatte. Am Ende half nur der Rückgriff auf eine vier Wochen alte Sicherung, und der Datenverlust war enorm. Hätte es ein klares Prozedere gegeben – etwa: „Nach jedem Update wird eine Datenbank-Sicherung angelegt, bevor Änderungen vorgenommen werden“ – wäre das vermeidbar gewesen. Dabei zeigt sich: Die häufigste Ursache für Notfälle ist nicht etwa ein Hackerangriff oder ein Hardwaredefekt, sondern schlicht menschliches Versagen. Ein falscher Befehl, eine übersehene Abhängigkeit, ein ungetestetes Skript. Ein Notfallhandbuch kann solche Fehler nicht verhindern, aber es kann ihre Folgen eindämmen. Nicht zuletzt, weil es den Druck aus der Situation nimmt: Anstatt unter Zeitnot zu improvisieren, folgt man einem erprobten Pfad.
Die Anatomie einer Nextcloud-Installation: Wo liegen die kritischen Punkte?
Bevor man ein Handbuch schreibt, muss man verstehen, woraus eine Nextcloud-Umgebung eigentlich besteht. Vereinfacht gesagt: Es gibt die Dateien selbst – also die Benutzerdaten, die in einem Storage-Ordner liegen, sei es lokal, auf einer NFS-Freigabe oder in einem S3-Bucket. Dazu kommt die Datenbank, in der Metadaten, Benutzerkonten, Freigaben, Einstellungen und der Applikationszustand gespeichert sind. Meist ist das MySQL oder MariaDB, aber auch PostgreSQL oder SQLite sind möglich (letzteres eher für Testsysteme). Und dann gibt es die Konfiguration: die config.php, die occ-Konfiguration, die jeweiligen App-Einstellungen, vielleicht angepasste Theme-Dateien oder Skripte. All diese Komponenten sind voneinander abhängig. Ein Fehler in der Datenbank, und die Dateien sind vielleicht noch vorhanden, aber kein Benutzer kann darauf zugreifen. Ein defekter Storage, und die Metadaten zeigen auf nicht existierende Objekte. Ein verlorener Verschlüsselungsschlüssel, und selbst die korrekt gesicherten Daten bleiben stumm. Genau deshalb muss ein Notfallhandbuch jede dieser Ebenen separat und im Zusammenspiel betrachten.
Ein interessanter Aspekt ist der Umgang mit der sogenannten „External Storage“-Funktion, also angebundenen Netzlaufwerken oder Cloud-Speichern. Backups, die nur die lokalen Ordner sichern, ignorieren diese externen Quellen oft. Wenn dann der Provider ausfällt oder die Anbindung reißt, steht man plötzlich ohne die vermeintlich gesicherten Daten da. Ähnlich verhält es sich mit der Verschlüsselung: Nextcloud bietet eine serverseitige Ende-zu-Ende-Verschlüsselung, die auf Schlüsseln basiert. Diese Schlüssel müssen separat und sicher gesichert werden – sonst hilft auch das beste Datei-Backup nichts. Wer hier nicht genau dokumentiert, welche Komponente wie gesichert wird, baut auf Sand. Ich rate dazu, eine kleine Matrix zu erstellen: Welche Komponente, welches Backup-Intervall, welches Wiederherstellungsziel (RTO/RPO), welche Tools, wer ist verantwortlich. Das klingt nach Bürokratie, erspart aber im Ernstfall wertvolle Zeit. Denn wenn der Server brennt, will man nicht erst überlegen, wo denn die Schlüssel liegen oder wie der Datenbank-Dump zu entschlüsseln ist.
Backup-Strategien, die im Ernstfall wirklich tragen
Kommen wir zum Kern des Notfallhandbuchs: dem Backup und der Wiederherstellung. Viele Administratoren setzen auf einfache Skripte, die per Cron-Job die Datenbank dumpen und den Dateibaum kopieren. Das ist besser als nichts, aber nicht wirklich belastbar. Ein Dump, der mitten im Schreibbetrieb erstellt wird, kann inkonsistent sein. Ein rsync, der nur geänderte Dateien überträgt, hinterlässt unter Umständen alte Versionen, wenn die Quelldatei während des Kopierens geändert wird. Hier kommen Werkzeuge wie BorgBackup, restic oder duplicity ins Spiel, die mit Snapshots, Deduplizierung und konsistenten Checkpoints arbeiten. Sie sind robuster und bieten oft eine einfache Integrationsmöglichkeit in Nextcloud. Aber egal welches Tool: Ohne Tests ist jedes Backup nur eine Illusion. Ich habe schon erlebt, dass ein Backup-Skript jahrelang lief, aber die Sicherung war unbrauchbar, weil die Datenbank-Dumps fehlerhaft waren oder der Zielspeicher überlief. Deshalb gehört in jedes Notfallhandbuch ein regelmäßiger Wiederherstellungstest – zum Beispiel einmal im Quartal auf einem separaten System. Das muss nicht die volle Instanz sein, aber zumindest ein Probelauf für die Datenbank und eine Stichprobe der Dateien. Dabei zeigt sich oft, dass vermeintlich perfekte Sicherungen Lücken haben: Eine App benötigt bestimmte Tabellen, die nicht mitgesichert wurden. Ein Cron-Job bricht wegen eines Timeouts ab. Ein SSH-Schlüssel für den Backup-Server rotiert, aber keiner aktualisiert die Konfiguration. Solche Details sind die wahren Fallstricke.
Ein guter Backup-Plan für Nextcloud besteht aus mehreren Ebenen: Erstens ein täglicher, konsistenter Datenbank-Dump, idealerweise mit einem Tool wie `mysqldump –single-transaction`, der auch bei laufendem Betrieb einen sauberen Snapshot liefert. Zweitens eine Dateisicherung des Nextcloud-Storage-Ordners, inklusive der config.php und der Datenverzeichnisse der Apps. Drittens ein separates Backup der Verschlüsselungsschlüssel und der occ-Konfiguration. Und viertens – oft vergessen – die Konfiguration des Webservers und des Reverse-Proxys. Wer zum Beispiel Nginx mit speziellen Rewrite-Regeln betreibt, sollte diese ebenfalls sichern. Alle diese Sicherungen sollten auf getrennten Medien liegen, idealerweise an einem anderen Standort. Ein Cloud-Backup (etwa via S3 oder Backblaze B2) ist eine gute Ergänzung, aber nicht als einzige Sicherung. Denn wenn der gesamte Rechenzentrumsstandort ausfällt, nützt die lokale Festplatte nichts. Ein interessanter Aspekt ist hier der Einsatz von Git: Man kann die config.php und die wichtigsten Konfigurationsdateien in einem privaten Repository versionieren. Das hilft nicht nur bei der Wiederherstellung, sondern auch beim Nachvollziehen von Änderungen. Allerdings Vorsicht: Die config.php enthält Passwörter und Secrets, die nicht im Klartext in einem öffentlichen Repository landen dürfen. Also entweder ein privates Git-Repo auf einem geschützten Server oder eine verschlüsselte Variante.
Notfallszenarien und ihre spezifischen Wiederherstellungspfade
Nicht jeder Notfall ist gleich. Ein Handbuch sollte die häufigsten Szenarien separat beschreiben, mit Schritt-für-Schritt-Anleitungen. Dazu gehören:
1. Datenbankausfall oder -korruption
Die häufigste Ursache? Ein abgebrochenes Update, ein fehlerhafter Query, Speicherüberlauf. Nextcloud selbst erkennt oft eine inkonsistente Datenbank und meldet das im Log. Die Wiederherstellung beginnt mit der Identifikation der Fehlerquelle: Liegt es an einer bestimmten Tabelle, an der gesamten Datenbank oder an der Verbindung? Dann folgt der Austausch der defekten Datenbank gegen den letzten konsistenten Dump. Falls der Dump zu alt ist, kann man versuchen, mit Tools wie `mysqlcheck` oder `phpmyadmin` Reparaturbefehle auszuführen. Aber Vorsicht: Das kann mehr Schaden anrichten, wenn die Korruption tiefer sitzt. In einem Notfallhandbuch sollte klar stehen: „Im Zweifel immer den Dump zurückspielen, nicht reparieren.“ Denn eine halb reparierte Datenbank führt zu neuen Fehlern, die man erst Tage später bemerkt. Dazu kommt der Abgleich mit den Dateien: Wenn die Datenbank auf einen Stand von vor drei Tagen zurückgesetzt wird, müssen auch die Dateien, die in der Zwischenzeit geändert wurden, entsprechend behandelt werden – entweder durch Wiederherstellung der Dateisicherung vom gleichen Zeitpunkt oder durch eine manuelle Synchronisation. Hier zeigt sich, warum konsistente Sicherungen so wichtig sind: Ein Dump plus File-Backup aus demselben Backup-Job sind automatisch aufeinander abgestimmt. Mischt man verschiedene Zeitpunkte, entstehen Inkonsistenzen.
2. Festplatten- oder Speicherbackend-Ausfall
Wenn der Storage-Ordner beschädigt ist oder das Laufwerk ausfällt, stehen die Dateien nicht mehr zur Verfügung, auch wenn die Datenbank noch funktioniert. Die Wiederherstellung läuft über die Dateisicherung: Ein vollständiger Restore des Dateibaums, danach eine Überprüfung der Berechtigungen und der Dateiintegrität per `occ files:scan –all`. Dieser Befehl aktualisiert die Datei-Caches und gleicht Abweichungen ab. Bei großen Instanzen kann das einige Stunden dauern. Ein Tipp: Vor dem Restore sollte man prüfen, ob der Speicherplatz ausreicht, um die gesamte Sicherungskopie aufzunehmen. Gerade bei deduplizierenden Backups muss man die tatsächliche Größe der wiederhergestellten Dateien kennen. Und ja, auch hier gilt: Vor dem Überschreiben des defekten Dateisystems unbedingt einen weiteren Snapshot oder ein Backup des aktuellen Zustands anlegen – manchmal lässt sich doch noch etwas retten.
3. Fehlgeschlagenes Nextcloud-Update
Updates sind der Klassiker unter den selbstverschuldeten Notfällen. Das Handbuch sollte den gesamten Rollback-Prozess beschreiben: von der Wiederherstellung der vorherigen Code-Version (entweder via Git, via manuellem Download des alten Pakets oder aus einem Container-Image) über das Zurückspielen der Datenbank bis hin zum Abgleichen der Dateien. Dabei muss man wissen, dass manche Updates Änderungen an der Datenbankstruktur vornehmen, die nicht einfach rückgängig zu machen sind. Ein Dump der Datenbank vor dem Update ist hier Gold wert. Die Wiederherstellung läuft dann ähnlich wie bei einem Datenbankausfall: Dump einspielen, Code bereitstellen, Administrations-Interface prüfen. Besonders heikel sind Major-Updates, bei denen auch die Mindestanforderungen an PHP, Datenbankversion oder Apps steigen. Vorher sollte man immer auf einem Testsystem prüfen, ob das Update sauber durchläuft. Ein Notfallhandbuch, das diesen Test als Muss vorschreibt, verhindert viele operative Albträume. Und ja, der Test muss auch die Wiederherstellbarkeit umfassen – sonst ist er wertlos.
4. Sicherheitsvorfall: Kompromittierung des Servers
Das ist das Szenario, das jeder fürchtet, und das ein Handbuch am besten genau beschreiben sollte. Wenn ein Angreifer Zugriff auf den Nextcloud-Server erlangt hat, reicht ein einfaches Backup-Restore nicht aus. Man muss davon ausgehen, dass der Angreifer Backdoors, versteckte Nutzer oder manipulierte Dateien hinterlassen hat. Der Ablauf: Server sofort vom Netz nehmen (oder den betroffenen Dienst isolieren), dann ein forensisches Backup des gesamten Systems anlegen (für spätere Analyse), anschließend das System von Grund auf neu aufsetzen und die Nextcloud-Instanz aus einem als sicher bekannten Backup wiederherstellen. Das Backup muss vor der Kompromittierung erstellt worden sein. Idealerweise hat man ein Golden Image der Installationsumgebung und ein separates Datensicherung, das nach jedem Patch erneuert wird. Ein Notfallhandbuch sollte hier auch die Kommunikationskette definieren: Wen informieren? Wie gehen wir mit Benutzerdaten um? Müssen wir die Behörden einschalten? Gerade bei personenbezogenen Daten ist die DSGVO im Spiel – eine Dokumentation der Maßnahmen kann später rechtlich entlasten. Das klingt nach viel Aufwand, aber wer einmal einen Einbruch erlebt hat, weiß, dass improvisierte Ad-hoc-Lösungen das Desaster nur vergrößern.
Das Handbuch als lebendes Dokument: Wartung und Pflege
Ein Notfallhandbuch ist kein Projekt, das man einmal schreibt und dann in einer Ecke verstauben lässt. Nextcloud selbst entwickelt sich weiter – neue Versionen, neue Datenbank-Requirements, andere Backup-Strategien. Auch die Infrastruktur ändert sich: Ein neuer Storage-Anbieter, ein anderer Reverse-Proxy, zusätzliche Apps. Deshalb sollte das Handbuch mindestens einmal im Jahr durchgegangen und aktualisiert werden. Besser: Nach jedem Major-Update der Nextcloud-Instanz. Man kann es als internes Wiki, als Markdown-Datei im Git-Repo oder als PDF mit Änderungsprotokoll führen. Wichtig ist, dass das Dokument für das gesamte Team zugänglich ist und dass jeder weiß, wo es liegt. Das klingt banal, aber ich habe schon erlebt, dass das Notfallhandbuch nur auf dem ausgefallenen Server selbst lag – eine klassische IT-Dead-End-Situation. Also: Auf einem separaten System, vielleicht sogar ausgedruckt im Tresor oder in einer Passwort-geschützten Cloud (ja, der Ironie bin ich mir bewusst). Ein interessanter Aspekt ist die Einbeziehung von neuen Mitarbeitern: Sie sollten bei der Einarbeitung das Handbuch durchgehen und einen simulierten Wiederherstellungstest absolvieren. So wird das Wissen nicht nur in einer Person konzentriert, und im Ernstfall kann auch der Vertreter handeln.
Ich empfehle, das Handbuch in drei Abschnitte zu unterteilen: Einen Schnellreferenz-Teil für die häufigsten Fehler („Datenbank-Dump einspielen in zehn Schritten“), einen detaillierten Teil mit allen Skripten, Kommandos und Pfaden, und einen dritten Teil mit den langfristigen Notfallplänen (Migration, Disaster Recovery am zweiten Standort, Kommunikationsregeln). Jeder Abschnitt sollte explizit auf die verwendeten Werkzeuge verweisen, und es sollte klar sein, welche Versionen von Nextcloud, MariaDB, PHP etc. derzeit im Einsatz sind. Gerade bei der Wiederherstellung mit Docker oder podman muss man die Container-Konfiguration und die Volume-Pfade exakt kennen. Ein falscher Parameter und die ganze Mühe war umsonst.
Tools und Techniken, die sich in der Praxis bewährt haben
Neben den klassischen Backup-Tools gibt es einige spezifische Ansätze, die in einem Nextcloud-Notfallhandbuch nicht fehlen sollten. Da wäre zum Beispiel die Verwendung von Snapshots auf Dateisystemebene (etwa LVM oder ZFS). Sie erlauben innerhalb von Sekunden einen konsistenten Zustand der Datenbank und der Dateien einzufrieren, ohne die Datenbank anzuhalten. Danach wird der Snapshot auf ein separates Medium kopiert. Das Ganze ist wesentlich schneller als ein traditionelles Backup und reduziert die Belastung des Systems. Allerdings sind Snapshots kein Ersatz für ein Off-Site-Backup – sie liegen auf demselben physikalischen Speicher. Ein weiterer bewährter Ansatz ist der Einsatz von Nextcloud selbst zur Sicherung: Man kann eine verschlüsselte Export-Funktion nutzen, die die Datenbank dump und die Dateien in ein komprimiertes Archiv packt. Der Vorteil: Man bleibt in der gewohnten Umgebung. Der Nachteil: Diese Funktion ist nicht für große Instanzen optimiert und benötigt viel Speicher und Zeit. In der Praxis bewährt hat sich eine Kombination aus Betriebssystem-Ebene (Snapshots, rsync, Borg) und Nextcloud-eigenen Werkzeugen (occ, Export/Import). Für die Datenbank setze ich persönlich auf einen MariaDB-Galera-Cluster, der eine synchrone Replikation erlaubt und im Fehlerfall einen Knoten einfach austauscht. Das erhöht die Ausfallsicherheit, aber auch die Komplexität des Handbuchs. Denn plötzlich muss man nicht mehr nur eine Datenbank wiederherstellen, sondern den gesamten Cluster-Zustand. In so einem Fall gehört ein eigenes Kapitel ins Handbuch.
Ein Tipp am Rande: Wer regelmäßig mit `occ db:add-missing-indices` arbeitet, sollte wissen, dass dieser Befehl bei großen Tabellen blockieren kann. Auch das ist ein Notfallszenario, wenn der Befehl zu lange läuft und die Datenbank die Verbindung verliert. Das Handbuch sollte hier Zeitüberschreitungen und mögliche Rollback-Optionen beschreiben. Ein guter Einstieg ist der `occ maintenance:mode –on`, der den Betrieb unterbricht und die Datenbank in einen definierten Zustand versetzt. Diesen Befehl sollte man vor jedem Wiederherstellungsvorgang ausführen – er verhindert, dass Benutzer während der Arbeiten Daten ändern, die später verloren gehen. Das klingt trivial, wird aber in der Hektik oft vergessen.
Kommunikation und Krisenmanagement nicht vergessen
Ein Notfallhandbuch, das sich nur auf technische Aspekte beschränkt, greift zu kurz. Denn wenn die Cloud ausfällt, stehen nicht nur die Administratoren unter Druck, sondern auch die Anwender. Sie wollen wissen, was passiert ist, wann sie wieder arbeiten können und ob ihre Daten sicher sind. Deshalb sollte das Handbuch auch eine Kommunikationsvorlage enthalten: ein kurzes Statement für das Intranet, eine E-Mail an die Führungskräfte, eine Information für externe Partner. Gerade bei längeren Ausfällen oder bei Datenverlust ist Transparenz unverzichtbar. Wer schweigt, verliert das Vertrauen. Gleichzeitig sollte klar sein, wer welche Informationen nach außen geben darf. Die IT-Abteilung ist nicht unbedingt die beste PR-Abteilung. Ein definierter Eskalationspfad – von der Technik über das Management bis zur Rechtsabteilung – verhindert unbedachte Aussagen. Auch hier zeigt sich die Qualität eines durchdachten Notfallhandbuchs: Es denkt nicht nur an die Bits und Bytes, sondern auch an die Menschen. Ein interessanter Aspekt ist, dass viele Organisationen nach einem erfolgreichen Recovery eine Retrospektive durchführen – eine Art „Lessons Learned“-Session. Die Ergebnisse sollten ins Handbuch einfließen. So wird es mit der Zeit immer besser, immer detaillierter, immer robuster.
Nicht zuletzt: Ein Handbuch ist nur so gut wie die Disziplin, mit der es befolgt wird. Ich habe schon nächste Schritte gesehen, die jahrelang auf dem Papier standen, aber nie umgesetzt wurden. Der Grund war meist Zeitmangel oder die irrige Annahme, dass „unser System ja stabil läuft“. Genau diese Einstellung führt dann zum bösen Erwachen. Ein guter Redakteur würde sagen: Ein Notfallhandbuch ist wie eine Versicherung – man hofft, sie nie zu brauchen, aber man ist froh, wenn man sie hat. Und je mehr man sich darauf verlässt, desto weniger Fehler passieren. Vielleicht ist das der eigentliche Wert eines solchen Dokuments: dass es ein Bewusstsein für die Fragilität der digitalen Infrastruktur schafft und die Menschen dazu bringt, sorgfältiger zu arbeiten. Also: Setzen Sie sich diese Woche hin, analysieren Sie Ihre Nextcloud-Umgebung, schreiben Sie die ersten zehn Seiten eines Notfallhandbuchs. Und testen Sie es. Es wird nicht perfekt sein, aber es ist der Anfang einer Reise, die im Zweifel den Unterschied ausmacht zwischen einem ärgerlichen Vormittag und einer existenzbedrohenden Krise.
Fazit: Vom technischen Werkzeug zur organisatorischen Kultur
Nextcloud ist mehr als nur ein Dateimanager – es ist das zentrale Nervensystem vieler Organisationen. Ein Ausfall trifft nicht nur die IT, sondern das gesamte Unternehmen. Ein Notfallhandbuch, das die spezifischen Eigenheiten der Plattform berücksichtigt, ist daher kein Luxus, sondern eine Notwendigkeit. Es ersetzt nicht das technische Know-how der Administratoren, aber es bündelt es und macht es reproduzierbar. Es schafft Handlungssicherheit in Situationen, die sonst schnell eskalieren. Und es etabliert eine Kultur der Vorsorge, die letztlich allen zugutekommt – den Anwendern, dem Management und vor allem den Menschen, die nachts den Server neu starten müssen. Wer heute mit der Erstellung eines solchen Handbuchs beginnt, hat morgen schon einen entscheidenden Vorteil. Also: Ran an die Konsole, Backup-Strategie prüfen, Dokumentation schreiben. Die nächste Störung kommt bestimmt. Die Frage ist nur, ob man ihr gewachsen ist.
„`