Mittelstufe 12 Min.Täglicher Plan

Wiederherstellung von Open WebUI und Ollama nach einem panne

Open WebUI und Ollama nach einem Ausfall wiederherzustellen bedeutet mehr, als nur einen Ordner zurückzukopieren: Unterhaltungen, Konfiguration und Modelle unterscheiden sich in Größe, Wert und in der Art, wie sie wiederhergestellt werden. Dieser Leitfaden trennt diese drei Kategorien, liefert die Befehle für Sicherung und Wiederherstellung bei einer klassischen Docker-Installation und erklärt, wie Sie selbst prüfen können, ob die Kopie verwendbar ist. Er gibt außerdem genau an, was in der Praxis überprüft wurde und was nicht.

Von Mohamed Meguedmi·Aktualisierung 2026-10-31·Unter Windows, macOS und Linux getestet

#Was Sie wirklich sichern müssen

Ein typischer lokaler Stack besteht aus zwei Bausteinen: Ollama, dem Dienst, der die Modelle lädt und auf http://localhost:11434 antwortet, und Open WebUI, der Weboberfläche, die Konten, Verlauf und Einstellungen speichert. Wenn eine Festplatte ausfällt, ein Update einen Container beschädigt oder ein Docker-Volume versehentlich gelöscht wird, gehen nicht dieselben Dinge verloren, und sie lassen sich nicht mit demselben Aufwand ersetzen.

Die Modelle sind groß, lassen sich aber erneut herunterladen. Unterhaltungen, Benutzerkonten, gespeicherte Prompts und importierte Dokumente sind einmalig: Ohne Kopie sind sie verloren. Der Sicherungsaufwand sollte sich daher vorrangig auf Open WebUI richten, während bei Ollama vor allem eine genaue Liste dessen geführt werden sollte, was installiert war.

Ein Backup, das nie wiederhergestellt wurde, bleibt eine Annahme. Der einzige Beweis, dass es funktioniert, besteht darin, es an anderer Stelle auf einer isolierten Instanz einzuspielen und dort seine Daten wiederzufinden. Der Abschnitt „Nachweisen, dass die Wiederherstellung funktioniert“ beschreibt diese Prüfung im Detail; planen Sie sie bereits ab dem ersten Backup ein, nicht erst am Tag des Ausfalls.

#Unterhaltungen, Konfiguration, Modelle: drei getrennte Kategorien

Das komplette Kit, um deinen eigenen KI-Assistenten zu erstellen.

Profitiere von unserer Erfahrung und einem geführten Lernpfad, um deinen lokalen Assistenten zu erstellen und deine KI im Alltag zu nutzen.

  • Lebenslanger Online-Zugang
  • PDF + Dateien
  • Erstattung binnen 30 Tagen
Kit Lokale KI entdecken: 24 €oder Alle Kits auf Lebenszeit: 49 € →
Unterhaltungen und Konten
Chatverlauf, Benutzer, Gruppen, Prompts und in der Oberfläche gespeicherte Administrationseinstellungen. In der Standardkonfiguration liegt all dies in einer SQLite-Datenbank (Datei webui.db) im Datenordner von Open WebUI, der im Container unter /app/backend/data eingebunden ist. Wenn Sie DATABASE_URL auf PostgreSQL gesetzt haben, liegen diese Daten in PostgreSQL und werden mit den Werkzeugen von PostgreSQL gesichert, nicht durch Kopieren des Volumes.
Dokumente und Index
Importierte Dateien (Unterordner uploads) und der Vektorindex, den die Dokumentensuche verwendet (Unterordner vector_db bei der standardmäßigen Vektordatenbank). Sie liegen im selben Volume wie webui.db, ihre Wiederherstellung wurde im Rahmen dieses Leitfadens jedoch nicht überprüft: siehe den Abschnitt zu den Einschränkungen.
Deployment-Konfiguration
Was nicht im Volume enthalten ist: der Befehl docker run bzw. die Datei docker-compose.yml, die Umgebungsvariablen (WEBUI_SECRET_KEY, OLLAMA_BASE_URL, DATABASE_URL…), das Tag und der exakte Digest des Images sowie die Konfiguration des Reverse Proxys. Diese sollten separat versioniert werden, ohne Secrets im Klartext in einem gemeinsam genutzten Repository zu hinterlassen.
Ollama-Modelle
Die Modellgewichte und ihre Manifeste im Ordner models von Ollama. Umfangreich, aber erneut herunterladbar, solange das Modell weiterhin veröffentlicht ist. Mit einem Modelfile erstellte benutzerdefinierte Modelle sind die Ausnahme: Das Modelfile muss aufbewahrt werden.
!
Ein Volume zu kopieren heißt nicht, alles zu kopieren
Wenn der Startbefehl, die Image-Version oder die Variable WEBUI_SECRET_KEY nicht notiert sind, kann eine Wiederherstellung mit einer anderen Version von Open WebUI starten oder laufende Sitzungen ungültig machen. Sichern Sie das Volume UND die Art, wie der Container gestartet wurde.

#Voraussetzungen

Zielinstallation
Open WebUI in Docker mit einem benannten Volume (open-webui im dokumentierten Installationsbefehl) und der standardmäßigen SQLite-Datenbank. Bei einer pip-Installation oder einem auf ein Host-Verzeichnis eingebundenen Volume ist das Prinzip identisch: Nur der Pfad ändert sich.
Zugriff
Ein Terminal mit Docker-Rechten auf dem Rechner und ein Speicherort außerhalb dieses Rechners (externe Festplatte, NAS, anderer Server). Eine Kopie auf derselben Festplatte schützt nicht vor einem Festplattenausfall.
Wartungsfenster
Einige Minuten, in denen Open WebUI gestoppt werden kann. Das Kopieren einer SQLite-Datei, während in sie geschrieben wird, kann eine inkonsistente Kopie erzeugen.
Testinstanz
Ein Ort, an dem Sie wiederherstellen können, ohne die Produktion anzutasten: Ein anderer Containername und ein anderes Volume auf derselben Maschine genügen, zusammen mit einem anderen Port.

Falls Open WebUI noch nicht installiert ist, beginnen Sie mit der Anleitung Open WebUI mit Ollama, die am Ende der Seite aufgeführt ist: Das folgende Verfahren geht von dem dort beschriebenen Docker-Befehl aus.

#Open WebUI sichern: Volume, Version und Konfiguration

  1. 01
    1. Version und Konfiguration festhalten
    Notieren Sie vor jeder Kopie das verwendete Image, seinen Digest und die Umgebungsvariablen. Wenn Sie die Daten auf derselben Version wiederherstellen, sind Sie nicht auf eine Datenbankmigration angewiesen, die nicht überprüft wurde. Achtung: Die Ausgabe von docker inspect enthält Ihre Variablen und damit möglicherweise Geheimnisse. Bewahren Sie diese Datei mit derselben Sorgfalt auf wie die Sicherung selbst.
  2. 02
    2. Container stoppen
    docker stop open-webui gibt der Anwendung Zeit, die Datenbank sauber zu schließen. So werden Unterhaltungen, die gerade geschrieben werden, vor dem Kopieren abgeschlossen.
  3. 03
    3. Volume archivieren
    Ein temporärer Container bindet das Volume schreibgeschützt ein und erzeugt im aktuellen Verzeichnis ein datiertes Archiv. Das Volume wird nicht verändert.
  4. 04
    4. Neu starten und die Kopie von der Maschine auslagern
    Starten Sie den Container neu und kopieren Sie anschließend das Archiv und die Konfigurationsdatei auf den externen Speicher. Berechnen Sie eine SHA-256-Prüfsumme, um später ein bei der Übertragung beschädigtes Archiv zu erkennen.
Terminal — Schritt 1: Version und Konfiguration
mkdir -p ~/sauvegardes-ia && cd ~/sauvegardes-ia

# Image et empreinte réellement utilisées
docker inspect open-webui --format '{{.Config.Image}}' > open-webui-image-$(date +%F).txt
docker image inspect "$(docker inspect open-webui --format '{{.Config.Image}}')" \
  --format '{{index .RepoDigests 0}}' >> open-webui-image-$(date +%F).txt

# Variables et montages (contient des secrets : à protéger)
docker inspect open-webui > open-webui-inspect-$(date +%F).json
Terminal — Schritte 2 bis 4: Stoppen, Archivieren, Neustart
docker stop open-webui

docker run --rm \
  -v open-webui:/data:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/open-webui-$(date +%F).tar.gz -C /data .

docker start open-webui

sha256sum open-webui-$(date +%F).tar.gz > open-webui-$(date +%F).tar.gz.sha256
ls -lh ~/sauvegardes-ia

Falls Ihr Volume anders heißt, finden Sie es mit docker inspect open-webui im Abschnitt Mounts. Wenn Sie docker compose verwenden, ist dem tatsächlichen Volume-Namen oft der Projektname vorangestellt: docker volume ls zeigt ihn an. Bei PostgreSQL fügen Sie einen pg_dump der Datenbank hinzu: Das Archiv des Volumes enthält dann den Unterhaltungsverlauf nicht mehr.

→
Ergänzend über die Oberfläche exportieren
Open WebUI bietet außerdem Exporte über die Oberfläche an (Unterhaltungen in den Benutzereinstellungen, je nach Version die Datenbank im Administrationsbereich). Sie sind nützlich, um einen einzelnen Verlauf zurückzuholen, ersetzen aber nicht das vollständige Archiv des Volumes: Weder die importierten Dateien noch die Deployment-Konfiguration sind darin enthalten.

#Ollama und seine Modelle sichern

Bei Ollama geht es weniger darum, Dutzende Gigabyte zu kopieren, als darum, exakt denselben Modellbestand wiederherstellen zu können. Dafür genügen in den meisten Fällen drei Elemente: die Liste der Modelle mit ihrem exakten Tag (qwen3:8b ist nicht qwen3:8b-q8_0), die Modelfiles der benutzerdefinierten Modelle und die Einstellungen des Dienstes (Variablen wie OLLAMA_HOST, OLLAMA_MODELS oder OLLAMA_KEEP_ALIVE, oft in einem systemd-Override).

Terminal — Bestandsaufnahme von Ollama
cd ~/sauvegardes-ia

# Liste des modèles installés, étiquettes comprises
ollama list > ollama-list-$(date +%F).txt

# Modelfile d'un modèle personnalisé (répéter pour chacun)
ollama show --modelfile mon-modele > Modelfile-mon-modele

# Réglages du service sous Linux avec systemd
systemctl cat ollama > ollama-service-$(date +%F).txt

Wenn Sie sich Sorgen um die Bandbreite oder die künftige Verfügbarkeit eines Modells machen, können Sie auch den Modellordner kopieren. Sein Speicherort hängt von der Installation ab: ~/.ollama/models unter macOS, C:\Users\<utilisateur>\.ollama\models unter Windows, /usr/share/ollama/.ollama/models mit dem Linux-Installationsskript oder das unter /root/.ollama eingehängte Volume beim offiziellen Docker-Image. Die Variable OLLAMA_MODELS hat, sofern sie gesetzt ist, Vorrang vor diesen Pfaden. Beenden Sie Ollama während des Kopierens, um nicht einen halb geschriebenen Download festzuhalten.

i
Wichtige Einschränkung
Die Übertragung des Modellverzeichnisses von Ollama auf eine andere Maschine wurde für diese Anleitung nicht getestet. Die hier beschriebene Methode (Kopie des Verzeichnisses models, Berechtigungen beibehalten, gleiche Version von Ollama) folgt der dokumentierten Struktur, wird aber nicht als überprüft dargestellt. Der sichere Weg bleibt, jedes Modell anhand der gesicherten Liste mit ollama pull erneut herunterzuladen.

#Open WebUI und Ollama nach einem Ausfall wiederherstellen: das Vorgehen

Die Reihenfolge ist wichtig: zuerst Ollama, damit die Oberfläche beim Start ihre Modelle findet, dann die Daten von Open WebUI, dann der Container mit demselben Image und denselben Variablen wie zuvor. Stellen Sie in ein neues Volume wieder her statt über ein bestehendes: Bei einem Fehler bleibt das alte unverändert.

  1. 01
    1. Archiv prüfen
    Prüfen Sie die SHA-256-Prüfsumme vor der Wiederherstellung. Ein durch einen abgebrochenen Kopiervorgang abgeschnittenes Archiv wird hier erkannt, nicht erst, nachdem etwas überschrieben wurde.
  2. 02
    2. Ollama wieder einsatzbereit machen
    Installieren Sie Ollama neu, wenden Sie Ihre Dienstvariablen erneut an und führen Sie dann ollama pull für jedes Modell der Liste sowie ollama create für jedes benutzerdefinierte Modelfile aus. Prüfen Sie, ob die API unter http://localhost:11434 antwortet.
  3. 03
    3. Das Volume Open WebUI neu erstellen
    Erstellen Sie ein leeres Volume und entpacken Sie das Archiv mit einem temporären Container hinein. Der Name des Volumes muss mit dem in Ihrem Startbefehl übereinstimmen.
  4. 04
    4. Mit demselben Image neu starten
    Verwenden Sie das bei der Sicherung notierte Image (Tag oder, besser, Digest) und dieselben Umgebungsvariablen, insbesondere WEBUI_SECRET_KEY und OLLAMA_BASE_URL, falls Sie diese definiert hatten.
  5. 05
    5. Vor der erneuten Freigabe des Zugriffs prüfen
    Melden Sie sich an, öffnen Sie einige ältere Unterhaltungen und prüfen Sie, ob die Modelle angezeigt werden. Geben Sie erst danach den Zugang für die anderen Benutzer wieder frei.
Terminal — Wiederherstellung von Open WebUI (SQLite, Docker)
cd ~/sauvegardes-ia
sha256sum -c open-webui-AAAA-MM-JJ.tar.gz.sha256

# Volume neuf, puis décompression de l'archive dedans
docker volume create open-webui
docker run --rm \
  -v open-webui:/data \
  -v "$PWD":/backup:ro \
  alpine sh -c "cd /data && tar xzf /backup/open-webui-AAAA-MM-JJ.tar.gz"

# Relance avec l'image notée lors de la sauvegarde
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Ersetzen Sie AAAA-MM-JJ durch das Datum Ihres Archivs und ghcr.io/open-webui/open-webui:main durch das exakte Image, das Sie in Schritt 1 der Sicherung notiert haben. Fügen Sie die -e-Optionen hinzu, die Sie verwendet haben (Secret, URL von Ollama, Datenbank). Falls noch ein altes Volume open-webui existiert und Sie es vorsichtshalber behalten möchten, stellen Sie in ein anders benanntes Volume wieder her und passen Sie die Option -v an.

Terminal — Ollama-Modellbestand aus der Liste neu aufbauen
# Première colonne de ollama list, sans la ligne d'en-tête
tail -n +2 ollama-list-AAAA-MM-JJ.txt | awk '{print $1}' | while read -r modele; do
  ollama pull "$modele"
done

# Modèles personnalisés
ollama create mon-modele -f Modelfile-mon-modele

curl http://localhost:11434/api/tags

Ein aus seinem Modelfile neu erstelltes benutzerdefiniertes Modell setzt voraus, dass das in der FROM-Zeile genannte Basismodell vorhanden ist: Laden Sie zuerst die Basismodelle herunter und erstellen Sie dann die Varianten. Wurde ein Modell zwischenzeitlich aus der Ollama-Bibliothek entfernt, schlägt ollama pull fehl; nur in diesem Fall hätte eine Kopie des Ordners models den Verlust verhindert.

#Nachweisen, dass die Wiederherstellung funktioniert, bevor Sie sie brauchen

Der nützlichste Test erfolgt in Ruhe, an einem Tag ohne Ausfall: Stellen Sie das letzte Archiv in einer separaten Instanz wieder her und prüfen Sie, ob dort bekannte Daten vorhanden sind. Ein Testkonto und eine Testunterhaltung, eigens mit wiedererkennbarem Inhalt angelegt, dienen als Referenz: Tauchen sie wieder auf, funktioniert die Kette aus Sicherung und Wiederherstellung zumindest für die Datenbank.

Terminal — isolierte Prüfinstanz
docker volume create open-webui-controle
docker run --rm \
  -v open-webui-controle:/data \
  -v "$PWD":/backup:ro \
  alpine sh -c "cd /data && tar xzf /backup/open-webui-AAAA-MM-JJ.tar.gz"

docker run -d -p 3001:8080 \
  -v open-webui-controle:/app/backend/data \
  --name open-webui-controle \
  ghcr.io/open-webui/open-webui:main

# Après vérification dans le navigateur sur http://localhost:3001
docker rm -f open-webui-controle
docker volume rm open-webui-controle
Connexion
Das Referenzkonto meldet sich mit seinem ursprünglichen Passwort an.
Verlauf
Die Referenzunterhaltung ist mit vollständigem Inhalt vorhanden, ebenso einige ältere echte Unterhaltungen.
Einstellungen
Die Administrationseinstellungen, die gespeicherten Prompts und die Benutzer entsprechen den Erwartungen.
Dokumente
Wenn Sie die Dokumentensuche nutzen, stellen Sie eine Frage, deren Antwort in einer importierten Datei steht. Diese Kontrolle müssen Sie selbst durchführen: Sie ist durch die weiter unten beschriebene Überprüfung nicht abgedeckt.
Trace
Notieren Sie das Datum, das verwendete Archiv und das Ergebnis. Ohne diesen Nachweis lässt sich später nicht belegen, dass die Sicherung getestet wurde.

Die Prüfinstanz benötigt keinen Zugriff auf Ollama, um Konten und Verlauf zu überprüfen: Diese Daten stammen aus der Datenbank, nicht aus den Modellen. Sie zeigt lediglich eine leere Modellliste an, was zu erwarten ist.

#Was überprüft wurde – und was nicht

Am 30/10/2026 wurden Sicherung und Wiederherstellung von Open WebUI in einem bewusst eng gefassten Rahmen überprüft: Docker-Container Open WebUI auf arm64-Architektur, standardmäßige SQLite-Datenbank, ohne Netzwerk und ohne GPU. Ein Testkonto und eine Testunterhaltung, die vor der Sicherung angelegt wurden, waren nach der Wiederherstellung wieder vorhanden. Dieses Ergebnis gilt für genau diesen Rahmen und für nichts darüber hinaus.

Überprüft
In SQLite gespeicherte Konten und Unterhaltungen, nach Archivierung des Volumes und Wiederherstellung in einer isolierten Instanz wieder vorhanden.
Nicht verifiziert
Importierte Dokumente und Vektorindex (Suche in Dokumenten).
Nicht verifiziert
Modelle von Ollama: weder die Kopie des Verzeichnisses models noch dessen Übertragung auf eine andere Maschine.
Nicht verifiziert
Wiederherstellung auf einer anderen Version von Open WebUI als der der Sicherung (Datenbankmigration).
Nicht verifiziert
Installationen mit PostgreSQL, auf x86_64 mit GPU oder hinter einem Reverse Proxy.

Für alles, was als „nicht überprüft“ markiert ist, folgt das beschriebene Vorgehen der dokumentierten Funktionsweise, muss aber auf Ihrer eigenen Installation geprüft werden, bevor es als zuverlässig gelten kann. Genau das ist die Aufgabe der Kontrollinstanz aus dem vorherigen Abschnitt. Weder eine Wiederherstellungsdauer noch eine Datenmenge wird hier angegeben: Beide hängen vollständig von der Größe Ihrer Datenbank und Ihrer Modelle ab.

!
Updates und Migrationen
Beim Start kann eine neuere Version von Open WebUI das Datenbankschema ändern. Das Wiederherstellen eines alten Archivs auf einem neueren Image oder umgekehrt wurde hier nicht überprüft. Erstellen Sie unmittelbar vor jedem Update eine Sicherung und bewahren Sie den Digest des vorherigen Images auf, um zurückkehren zu können.

#Fehlerbehebung

Kontoerstellungsbildschirm statt des Verlaufs
Das Archiv wurde an der falschen Stelle entpackt (eine Verzeichnisebene zu viel) oder in ein anderes Volume als das eingebundene. Listen Sie den Inhalt mit docker run --rm -v open-webui:/data alpine ls -la /data auf: webui.db muss im Wurzelverzeichnis liegen.
Sitzungen nach der Wiederherstellung abgelehnt
WEBUI_SECRET_KEY hat sich zwischen alter und neuer Instanz geändert. Die Konten bleiben in der Datenbank erhalten; eine erneute Anmeldung genügt in der Regel. Legen Sie die Variable für künftige Fälle explizit fest.
Kein Modell in der Liste
Open WebUI erreicht Ollama nicht. Prüfen Sie, ob Ollama vom Host aus auf http://localhost:11434 antwortet und ob OLLAMA_BASE_URL auf eine Adresse zeigt, die vom Container aus erreichbar ist (host.docker.internal mit der Option --add-host).
Datenbankfehler beim Start
Kopie bei laufendem Container erstellt oder anderes Image als bei der Sicherung. Gehen Sie von einem bei gestopptem Container erstellten Archiv aus und starten Sie mit dem notierten Image neu.
ollama create échoue
Das Basismodell aus der FROM-Zeile des Modelfile ist nicht installiert. Führen Sie zuerst ollama pull sur für dieses Modell aus.
Ungewöhnlich kleines Archiv
Leeres Volume eingebunden oder falscher Volume-Name. Prüfen Sie docker volume ls und den Abschnitt Mounts des ursprünglichen Containers, bevor Sie auf einen Datenverlust schließen.

#Weiterführende Informationen

Das Backup ist nur ein Teil des Betriebs eines lokalen Stacks. Diese Anleitungen behandeln die Installation von Open WebUI, die hier als Ausgangspunkt dient, die laufende Wartung von Ollama und die Inbetriebnahme von Ollama in Docker.

Hat Ihnen dieser Guide geholfen?

Haben Sie Feedback, einen Fehler entdeckt oder möchten Sie etwas präzisieren? Geben Sie uns Bescheid – so wird der Guide für alle besser.