Hochverfügbarkeit, Backup und Releases

Hochverfügbarkeit, Backup und Releases

0:00 Willkommen zu Modul vierzehn. Im letzten Modul haben wir gelernt, Störungen zu erkennen und ihre Ursache zu finden. Jetzt geht es um die Frage danach: Wie übersteht Lotsenhaus einen Ausfall, einen Datenverlust oder ein Upgrade, das schiefgeht? Wir bringen die Plattform zuerst auf mehrere Instanzen und klären, welcher Zustand dafür in gemeinsame Dienste wandern muss.

0:21 Dann sichern wir alles, was zählt, und proben die Wiederherstellung. Danach schauen wir uns an, warum jedes Release das Datenbankschema verändern kann und was das für einen Rückweg bedeutet. Zum Schluss ordnen wir, wer im Störfall entscheidet. In der Übung holen Sie Lotsenhaus aus einer Sicherung zurück und spielen ein Upgrade ein.

Hochverfügbarkeit, Backup und Releases

0:41 Der sechste und letzte Tag gehört dem Übergang in den Regelbetrieb. Das Zitat auf dieser Folie trifft einen wunden Punkt vieler Teams: Eine grüne Sicherungsmeldung beweist nur, dass etwas geschrieben wurde. Ob es sich zurückholen lässt, weiß man erst, wenn man es getan hat. Diesen Unterschied nehmen wir heute ernst.

Mehrinstanzbetrieb

1:00 Eine einzelne Instanz ist bequem, aber sie ist auch ein einzelner Punkt, an dem alles hängt. Bevor wir eine zweite danebenstellen, müssen wir verstehen, wo eigentlich der Zustand wohnt. Die Schichten zeigen eine einfache Idee: Die Anwendung selbst wird austauschbar, der Zustand wandert nach unten in gemeinsame Dienste. Ganz oben verteilt der Reverse Proxy die Anfragen und auch die dauerhaften WebSocket-Verbindungen auf die Instanzen.

1:26 Darunter laufen die Open-WebUI-Instanzen, alle mit demselben Image-Tag und demselben Schlüssel, damit es für die Nutzer egal ist, wo sie landen. Redis koordiniert die Live-Verbindungen und den Widerruf von Tokens. PostgreSQL trägt Anwendungsdaten und Vektoren in einer Datenbank, und alle Instanzen teilen sich ein Datenverzeichnis.

1:44 Das Bild dazu ist ein Callcenter: Jeder Platz ist gleich, weil die Kundenakte nicht am Schreibtisch liegt, sondern im gemeinsamen System. Diese Tabelle ist im Grunde eine Checkliste der Dinge, die alle Instanzen gemeinsam haben müssen. Drei Gruppen lassen sich erkennen. Erstens der gemeinsame Speicher: PostgreSQL statt der eingebauten Datei-Datenbank und eine Vektordatenbank, die mehrere Prozesse verträgt. Das eingebaute ChromaDB kann das nicht.

2:11 Zweitens die Koordination über Redis, ohne die WebSocket-Verbindungen mit Fehlern abbrechen. Drittens identische Schlüssel, denn sonst kann eine Instanz nicht lesen, was die andere signiert oder verschlüsselt hat, und Ihre Nutzer drehen sich in Anmeldeschleifen. Die letzte Zeile ist subtil, aber wichtig: Datenbankmigrationen darf nur eine einzige Instanz ausführen.

2:33 Damit die Gemeinsamkeiten nicht zweimal gepflegt werden und irgendwann auseinanderlaufen, legt die Compose-Datei sie einmal als Vorlage an, die beide Instanzen übernehmen. Darin stehen Datenbank, Vektorspeicher, Redis und die beiden Schlüssel. Die eigentlichen Geheimnisse kommen aus Variablen, nicht aus der Datei selbst, damit lotsenhaus-betrieb kein Passwort im Klartext enthält.

2:55 Auffällig ist, dass jede Instanz nur einen Worker-Prozess startet. Skaliert wird über weitere Instanzen, nicht über mehr Prozesse in einem Container. Die Fußzeile zeigt den einzigen Unterschied: Die zweite Instanz verzichtet auf Migrationen, und beide binden denselben Speicher ein. Hochverfügbarkeit beginnt nicht beim Server, sondern beim Repository.

3:16 Alles, was Lotsenhaus ausmacht, liegt versioniert in lotsenhaus-betrieb, damit eine Änderung nachvollziehbar ist und sich zurückdrehen lässt. Das Image-Tag wird fest gepinnt, denn wer in der Produktion auf einen beweglichen Stand setzt, bekommt Upgrades, die niemand bestellt hat. Die CI prüft die Compose-Datei, bevor sie irgendwo landet, und jede Änderung geht zuerst auf die Testumgebung.

3:39 Nach dem Ausrollen fragen Sie die Gesundheits-Endpunkte jeder Instanz ab. Die Fußzeile verdient Aufmerksamkeit: Was nur im Admin-Bereich eingestellt wurde, steht in keiner Datei. Entscheiden Sie bewusst, wo die Wahrheit liegt. Die Stolpersteine hier haben eines gemeinsam: Im Test mit einer Instanz fällt keiner davon auf.

3:58 Eine zweite Instanz neben SQLite führt zu gesperrten Datenbanken und im schlimmsten Fall zu beschädigten Daten. Ein fehlender Schlüssel bedeutet, dass jede Instanz sich einen eigenen ausdenkt, und Nutzer fliegen beim Wechsel einfach heraus. Mehrere Worker mit dem eingebauten ChromaDB stürzen beim Hochladen ab. Und der Verbindungspool wird gern vergessen.

4:19 Jede Instanz öffnet ihren eigenen Pool zur Datenbank, und die Summe muss unter dem Limit von PostgreSQL bleiben. Mit zwei Instanzen geht das meist gut, mit vier plötzlich nicht mehr.

Sicherung und Wiederherstellung

4:30 Mehrere Instanzen schützen vor dem Ausfall eines Rechners. Gegen gelöschte Daten, eine kaputte Migration oder einen Bedienfehler helfen sie nicht. Dafür braucht es eine Sicherung, die sich wirklich zurückholen lässt. Eine Sicherung ist wie ein Umzugskarton: Er nützt nur, wenn am Ende auch der Schlüssel zur neuen Wohnung dabei ist. Bei Lotsenhaus gibt es sechs Bestandteile.

4:53 Die Datenbank mit Benutzern, Chats und Rechten, die Vektoren, die dank pgvector gleich mit in der Datenbank liegen, das Datenverzeichnis mit hochgeladenen Dateien, die Konfiguration im Repository, die Schlüssel im Tresor und das Image-Tag, also die genaue Version. Fehlt eines davon, ist die Wiederherstellung unvollständig. Beachten Sie die Fußzeile: Die Backup-Anleitung der Doku zeigt den Einzelbetrieb mit SQLite und ChromaDB.

5:19 Für PostgreSQL gelten dessen eigene Werkzeuge. Der geheime Schlüssel ist das unscheinbarste und zugleich kritischste Stück der ganzen Sicherung. Er signiert die Anmeldetokens und verschlüsselt gespeicherte OAuth-Token. Die Falle: Wird er automatisch erzeugt, liegt er nicht im Datenverzeichnis, sondern an einer anderen Stelle im Container.

5:39 Wer brav das Volume sichert, hat danach Daten, aber keinen passenden Schlüssel dazu. Mit einem neuen Schlüssel sind dann alle Nutzer abgemeldet und alle verschlüsselten Tokens unlesbar. Deshalb gilt: Den Schlüssel ausdrücklich setzen, im Tresor verwahren und getrennt vom Backup aufbewahren. Getrennt deshalb, weil eine gestohlene Sicherung samt Schlüssel ein offenes Buch wäre.

6:01 Das Skript ist bewusst schlicht und hat drei Schritte. Zuerst ein Abzug der Datenbank in einem einzigen Snapshot, und weil die Vektoren in derselben Datenbank liegen, sind die Wissensbasen gleich mit dabei. Dann ein Archiv des gemeinsamen Datenverzeichnisses. Und zuletzt eine kleine, aber entscheidende Notiz: welcher Stand der Konfiguration und damit welches Image-Tag zu dieser Sicherung gehört.

6:24 Ohne diese Notiz rätseln Sie später, mit welcher Version Sie zurückspielen müssen. Die Fußzeile benennt ehrlich eine Schwäche: Die Datenbank ist in sich konsistent, die Dateisicherung läuft aber Minuten später. Für den Pilot ist das vertretbar, man sollte es nur wissen. Vier Missverständnisse rund um Konsistenz. Die Datenbank-Schaltfläche im Admin-Bereich ist verlockend, laut Doku aber nicht der empfohlene Sicherungsweg.

6:49 Wer eine SQLite-Datei im laufenden Betrieb kopiert, verliert die Änderungen, die noch in der Nebendatei des Schreibprotokolls stehen. Wer eine externe Vektordatenbank betreibt und sie nicht sichert, hat nach der Wiederherstellung leere Wissensbasen, bis alles neu indiziert ist. Und die Funktion zum Neuaufbau der Wissensbasen ist kein Allheilmittel: Sie baut nur Wissensbasen neu auf, Erinnerungen und lose Dateien bleiben außen vor.

7:14 Die Lehre: Eine Sicherung ist so gut wie die Liste dessen, was dazugehört. Eine Wiederherstellung probt man wie eine Feuerwehrübung: regelmäßig, mit Stoppuhr und nicht im brennenden Haus. Sie starten eine getrennte Umgebung mit genau dem Image-Tag, das zum Sicherungszeitpunkt lief. Dann spielen Sie Datenbank und Dateien ein, setzen den Schlüssel aus dem Tresor und starten die Instanzen.

7:37 Geprüft wird nicht nur, ob die Seite lädt, sondern ob Anmeldung, ein alter Chat und eine Quellenantwort des Richtlinienlotsen funktionieren. Und Sie messen die Zeit. Diese Zahl gehört ins Notfallhandbuch. Ganz wichtig die Fußzeile: Die Testumgebung bekommt eigene Modellzugänge und Identitäten, damit eine Übung nie in die Produktion durchgreift.

Releases und Upgrades

7:57 Gesichert ist die Plattform jetzt. Aber sie bleibt nicht stehen. Open WebUI entwickelt sich schnell, und jedes neue Release kann tiefer eingreifen, als die Versionsnummer vermuten lässt. Ein Release einfach einzuspielen, ist bei Open WebUI keine gute Idee, und die Zahlen auf dieser Folie zeigen, warum. Das Projekt veröffentlicht in kurzen Abständen.

8:19 Allein im September 2026 kamen sechsundzwanzig Sicherheitshinweise hinzu, mehrere davon mit hohem Schweregrad. Eine Lücke, über die sich Session-Tokens abgreifen ließen, ist erst ab Version 0.11.4 behoben. Das heißt: Nicht aktualisieren ist auch ein Risiko. Gleichzeitig bringen neue Funktionen neue Variablen und Rechte mit, die jemand prüfen und freigeben muss.

8:42 Release Notes zu lesen, ist also keine Bürokratie, sondern der Moment, in dem Sie entscheiden, was in Lotsenhaus hineinkommt. Die Doku unterscheidet die Strategien nach Umgebung, und das Prinzip dahinter ist einfach: Je mehr Menschen auf einer Instanz arbeiten, desto weniger Automatik. Auf der eigenen Spielwiese darf man dem neuesten Stand folgen. Eine Teaminstanz wird gepinnt, und ein Benachrichtigungsdienst meldet, wenn es etwas Neues gibt.

9:09 In der Produktion kommt die Lektüre der Release Notes und ein Test im Staging dazu. Wer das nächste Release vorab ausprobieren will, tut das auf einer eigenen Instanz mit eigenem Volume. Die Fußzeile warnt vor der bequemen Variante: Automatische Aktualisierung kann Lotsenhaus über Nacht mit einer inkompatiblen Änderung lahmlegen.

9:28 Das Upgrade folgt einer festen Choreografie, und die Reihenfolge ist der eigentliche Inhalt. Zuerst wird gesichert, denn das ist Ihr Rückweg. Dann halten Sie beide Instanzen an und ziehen die neue Version. Jetzt startet nur die erste Instanz, denn sie migriert das Datenbankschema, und dabei soll ihr niemand dazwischenfunken.

9:47 Sie beobachten das Log, bis die Migration durch ist, prüfen die Gesundheit der Datenbankanbindung und starten erst dann die zweite Instanz. Die Fußzeile sagt es offen: Weil Alembic das Schema beim Start umbaut, gibt es einen kurzen Komplettausfall. Den kündigt man an, statt ihn zu verstecken. Hier liegt das größte Missverständnis beim Thema Upgrade: der Glaube, man könne jederzeit einfach das alte Image zurückholen.

10:12 Ist die Migration gelaufen, bleibt das Schema neu, und die alte Version arbeitet dann gegen eine Datenbank, die sie nicht versteht. Ein Downgrade über das Migrationswerkzeug klingt nach Ausweg, kostet aber entfernte Spalten und Tabellen samt Inhalt. Instanzen einzeln nacheinander zu aktualisieren, wirkt vorsichtig, bedeutet aber zwei Versionen an einer Datenbank.

10:33 Und mehrere Worker in einem Container migrieren womöglich gleichzeitig. Der einzige sichere Rückweg ist deshalb: altes Tag plus die Sicherung von unmittelbar vor dem Upgrade.

Betriebsorganisation

10:44 Technik allein rettet keinen Störfall. Wenn es ernst wird, muss feststehen, wer entscheidet, wer informiert wird und wo die Schlüssel liegen. Darum geht es jetzt. Ein Notfallhandbuch schreibt man für einen Menschen, der nachts um drei geweckt wurde und das System vielleicht nicht gebaut hat. Deshalb enthält es keine Theorie, sondern Reihenfolgen und Orte. Beim Wiederanlauf erst die Datenbank, dann Redis, dann eine Instanz und zuletzt die übrigen.

11:11 Bei der Wiederherstellung das Skript und die gemessene Dauer aus unserer Probe. Der Notfallzugang über das lokale Konto notfall-admin, mit Passwort im Tresor und protokollierter Nutzung. Dazu, wo die Schlüssel liegen und wer sie herausgeben darf, wie die Pilotbereiche informiert werden und wen man anruft. Banner auf der Startseite sind dafür das einfachste Mittel.

11:32 Diese Tabelle beantwortet eine Frage, die man im Störfall nicht mehr diskutieren will: Wer entscheidet? Das Muster ist klar. Entschieden wird dort, wo die Fachkenntnis liegt, und beteiligt werden die, die betroffen sind oder mitreden müssen. Ist die Plattform weg, führt der Plattformbetrieb. Scheitert die Anmeldung, liegt es bei Identität und Zugriff. Liefert der Richtlinienlotse falsche Antworten, ist das keine Technikfrage, sondern Sache der Gruppe lh-wissen.

12:00 Und beim Verdacht auf Datenabfluss übernimmt die Informationssicherheit, mit Datenschutz und Betriebsrat an der Seite. Wer das vorher festlegt, spart im Ernstfall die wertvollsten Minuten. Die organisatorischen Stolpersteine sind leise, bis sie laut werden. Ohne vereinbartes Wartungsfenster wird ein dringendes Sicherheitsupdate eben ohne Ankündigung eingespielt, und das Vertrauen der Pilotbereiche leidet.

12:24 Ein Notfallzugang, der nie getestet wurde, versagt genau dann, wenn der Identitätsanbieter ausfällt und man ihn am dringendsten braucht. Eine Rufbereitschaft, die die Wiederherstellung nur vom Lesen kennt, verliert im Ernstfall Zeit. Und ein technisches Detail mit organisatorischer Wirkung: Ohne Redis bleiben Tokens nach dem Abmelden bis zu vier Wochen gültig.

12:44 Ein gesperrtes Konto ist dann nicht sofort gesperrt.

Übung

12:48 Jetzt dürfen Sie das tun, was man in der Produktion lieber nicht ausprobiert: Lotsenhaus zurückholen und ein Upgrade riskieren. Die Fähigkeit, um die es hier geht, ist Gelassenheit aus Übung. Sie stellen eine Open-WebUI-Plattform reproduzierbar aus einer Sicherung wieder her und führen ein Upgrade durch, bei dem Sie vorher wissen, wie weit der Rückweg reicht.

13:08 Erfolgreich sind Sie, wenn die Testinstanz Chats und Quellenantworten aus der Sicherung zeigt, auf dem neuen Tag läuft und Ihre Rückfallstrategie ihre Grenze ehrlich benennt. Wer früher fertig ist, bekommt eine Zusatzaufgabe: eine zweite Instanz starten und prüfen, ob die Anmeldung beim Wechsel erhalten bleibt. Damit testen Sie ganz nebenbei, ob Ihr Schlüssel wirklich gemeinsam ist.

13:30 Der Ablauf führt durch das ganze Modul. Sie sichern Datenbank, Dateien und Konfiguration und legen den Schlüssel getrennt ab. Dann stellen Sie in der getrennten Umgebung wieder her und prüfen nicht nur, dass etwas läuft, sondern dass Anmeldung, Chat und Quellenantwort stimmen. Vor dem Upgrade lesen Sie Release Notes und Sicherheitshinweise und notieren, was sich ändert. Das Upgrade folgt dem Runbook, die Migration verfolgen Sie im Log.

13:56 Zum Schluss schreiben Sie die Rückfallstrategie auf. Und die gemessene Wiederherstellungszeit landet im Notfallhandbuch. Im nächsten Modul geht es darum, wie Lotsenhaus vom Labor zu den ersten echten Nutzern kommt.