Restaurer Open WebUI et Ollama après une panne

#Ce qu'il faut vraiment sauvegarder

Une stack locale typique tient en deux briques : Ollama, le service qui charge les modèles et répond sur http://localhost:11434, et Open WebUI, l'interface web qui stocke les comptes, l'historique et les réglages. Quand un disque lâche, qu'une mise à jour casse un conteneur ou qu'on supprime un volume Docker par erreur, ce ne sont pas les mêmes choses qui disparaissent, et elles ne se remplacent pas au même prix.

Les modèles pèsent lourd mais se retéléchargent. Les conversations, les comptes utilisateurs, les prompts enregistrés et les documents importés sont uniques : sans copie, ils sont perdus. C'est donc sur Open WebUI que l'effort de sauvegarde doit porter en priorité, et sur Ollama qu'il faut surtout garder une liste précise de ce qui était installé.

Une sauvegarde qui n'a jamais été restaurée reste une hypothèse. La seule preuve qu'elle fonctionne, c'est de la remonter ailleurs, sur une instance isolée, et d'y retrouver ses données. La section « Prouver que la restauration marche » détaille ce contrôle ; prévoyez-le dès la première sauvegarde, pas le jour de la panne.

#Conversations, configuration, modèles : trois familles distinctes

Conversations et comptes

Historique des chats, utilisateurs, groupes, prompts, réglages d'administration enregistrés dans l'interface. Avec la configuration par défaut, tout cela vit dans une base SQLite (fichier webui.db) du dossier de données d'Open WebUI, monté dans le conteneur sur /app/backend/data. Si vous avez défini DATABASE_URL vers PostgreSQL, ces données sont dans PostgreSQL et se sauvegardent avec les outils de PostgreSQL, pas en copiant le volume.

Documents et index

Fichiers importés (sous-dossier uploads) et index vectoriel utilisé par la recherche dans les documents (sous-dossier vector_db avec la base vectorielle par défaut). Ils sont dans le même volume que webui.db, mais leur restauration n'a pas été vérifiée dans le cadre de ce guide : voir la section dédiée aux limites.

Configuration de déploiement

Ce qui n'est pas dans le volume : la commande docker run ou le fichier docker-compose.yml, les variables d'environnement (WEBUI_SECRET_KEY, OLLAMA_BASE_URL, DATABASE_URL…), l'étiquette et l'empreinte exacte de l'image, la configuration du reverse proxy. À versionner à part, sans y laisser de secret en clair dans un dépôt partagé.

Modèles Ollama

Les poids des modèles et leurs manifestes, dans le dossier models d'Ollama. Volumineux, retéléchargeables tant que le modèle est toujours publié. Les modèles personnalisés créés avec un Modelfile sont l'exception : il faut garder le Modelfile.

#Prérequis

Installation visée

Open WebUI en Docker avec un volume nommé (open-webui dans la commande d'installation documentée) et la base SQLite par défaut. Pour une installation pip ou un volume monté sur un dossier de l'hôte, le principe est identique : seul le chemin change.

Accès

Un terminal avec les droits Docker sur la machine, et un emplacement de stockage hors de cette machine (disque externe, NAS, autre serveur). Une copie sur le même disque ne protège pas d'une panne de disque.

Fenêtre d'arrêt

Quelques minutes pendant lesquelles Open WebUI peut être arrêté. Copier un fichier SQLite pendant qu'il est en cours d'écriture peut produire une copie incohérente.

Instance de test

Un endroit où restaurer sans toucher à la production : un autre nom de conteneur et un autre volume sur la même machine suffisent, avec un autre port.

Si Open WebUI n'est pas encore installé, commencez par le guide Open WebUI avec Ollama listé en fin de page : la procédure ci-dessous part de la commande Docker qu'il décrit.

#Sauvegarder Open WebUI : volume, version et configuration

1. 01
   1. Relever la version et la configuration

   Avant toute copie, notez l'image utilisée, son empreinte (digest) et les variables d'environnement. Restaurer des données sur la même version évite de dépendre d'une migration de base qui n'aurait pas été vérifiée. Attention : la sortie de docker inspect contient vos variables, donc d'éventuels secrets. Rangez ce fichier avec la même prudence que la sauvegarde elle-même.
2. 02
   2. Arrêter le conteneur

   docker stop open-webui laisse le temps à l'application de fermer proprement la base. Les conversations en cours d'écriture sont ainsi terminées avant la copie.
3. 03
   3. Archiver le volume

   Un conteneur temporaire monte le volume en lecture seule et produit une archive datée dans le dossier courant. Le volume n'est pas modifié.
4. 04
   4. Redémarrer et sortir la copie de la machine

   Relancez le conteneur, puis copiez l'archive et le fichier de configuration vers le stockage externe. Calculez une empreinte SHA-256 pour détecter plus tard une archive corrompue en transit.

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

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

Si votre volume porte un autre nom, retrouvez-le avec docker inspect open-webui et la rubrique Mounts. Si vous utilisez docker compose, le nom réel du volume est souvent préfixé par le nom du projet : docker volume ls l'affiche. Avec PostgreSQL, ajoutez un pg_dump de la base : l'archive du volume ne contient alors plus l'historique des conversations.

#Sauvegarder Ollama et ses modèles

Côté Ollama, la question n'est pas tant de copier des dizaines de gigaoctets que de pouvoir reconstruire exactement le même parc. Pour cela, trois éléments suffisent dans la plupart des cas : la liste des modèles avec leur étiquette exacte (qwen3:8b n'est pas qwen3:8b-q8_0), les Modelfiles des modèles personnalisés, et les réglages du service (variables comme OLLAMA_HOST, OLLAMA_MODELS ou OLLAMA_KEEP_ALIVE, souvent dans un override systemd).

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

Si la bande passante ou la disponibilité future d'un modèle vous inquiète, vous pouvez aussi copier le dossier des modèles. Son emplacement dépend de l'installation : ~/.ollama/models sur macOS, C:\Users\<utilisateur>\.ollama\models sous Windows, /usr/share/ollama/.ollama/models avec le script d'installation Linux, ou le volume monté sur /root/.ollama avec l'image Docker officielle. La variable OLLAMA_MODELS, si elle est définie, prime sur ces chemins. Arrêtez Ollama pendant la copie pour éviter de figer un téléchargement à moitié écrit.

#Restaurer Open WebUI et Ollama après une panne : la procédure

L'ordre compte : Ollama d'abord, pour que l'interface trouve ses modèles au démarrage, puis les données d'Open WebUI, puis le conteneur avec la même image et les mêmes variables qu'avant. Restaurez dans un volume neuf plutôt que par-dessus un volume existant : en cas d'erreur, l'ancien reste intact.

1. 01
   1. Vérifier l'archive

   Contrôlez l'empreinte SHA-256 avant de restaurer. Une archive tronquée par une copie interrompue se détecte ici, pas après avoir écrasé quoi que ce soit.
2. 02
   2. Remettre Ollama en état

   Réinstallez Ollama, réappliquez vos variables de service, puis relancez ollama pull pour chaque modèle de la liste et ollama create pour chaque Modelfile personnalisé. Vérifiez que l'API répond sur http://localhost:11434.
3. 03
   3. Recréer le volume Open WebUI

   Créez un volume vide et décompressez l'archive dedans avec un conteneur temporaire. Le nom du volume doit correspondre à celui de votre commande de lancement.
4. 04
   4. Relancer avec la même image

   Utilisez l'image relevée lors de la sauvegarde (étiquette ou, mieux, empreinte) et les mêmes variables d'environnement, en particulier WEBUI_SECRET_KEY et OLLAMA_BASE_URL si vous les aviez définies.
5. 05
   5. Contrôler avant de rouvrir l'accès

   Connectez-vous, ouvrez quelques conversations anciennes, vérifiez que les modèles apparaissent. Seulement ensuite, rouvrez l'accès aux autres utilisateurs.

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

Remplacez AAAA-MM-JJ par la date de votre archive et ghcr.io/open-webui/open-webui:main par l'image exacte relevée à l'étape 1 de la sauvegarde. Ajoutez les options -e que vous utilisiez (secret, URL d'Ollama, base de données). Si un ancien volume open-webui existe encore et que vous voulez le garder par précaution, restaurez dans un volume nommé autrement et adaptez l'option -v.

# 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

Un modèle personnalisé recréé à partir de son Modelfile a besoin que le modèle de base cité dans la ligne FROM soit présent : tirez d'abord les modèles de base, puis créez les variantes. Si un modèle a été retiré de la bibliothèque Ollama entre-temps, ollama pull échouera ; c'est le seul cas où une copie du dossier models aurait évité la perte.

#Prouver que la restauration marche avant d'en avoir besoin

Le test le plus utile se fait à froid, un jour sans panne : restaurer la dernière archive dans une instance séparée et vérifier qu'on y retrouve des données connues. Un compte et une conversation de test, créés exprès avec un contenu reconnaissable, servent de témoin : s'ils réapparaissent, la chaîne sauvegarde-restauration fonctionne au moins pour la base.

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

Le compte témoin se connecte avec son mot de passe d'origine.

Historique

La conversation témoin est présente, avec son contenu complet, ainsi que quelques conversations réelles anciennes.

Réglages

Les paramètres d'administration, les prompts enregistrés et les utilisateurs sont ceux attendus.

Documents

Si vous utilisez la recherche dans des documents, posez une question dont la réponse se trouve dans un fichier importé. C'est un contrôle à faire vous-même : il n'est pas couvert par la vérification décrite plus bas.

Trace

Notez la date, l'archive utilisée et le résultat. Sans cette trace, impossible d'affirmer plus tard que la sauvegarde a été testée.

L'instance de contrôle n'a pas besoin d'accéder à Ollama pour vérifier les comptes et l'historique : ces données viennent de la base, pas des modèles. Elle affichera simplement une liste de modèles vide, ce qui est attendu.

#Ce qui a été vérifié, et ce qui ne l'a pas été

Le 30/10/2026, la sauvegarde puis la restauration d'Open WebUI ont été vérifiées dans un cadre volontairement restreint : conteneur Docker Open WebUI sur architecture arm64, base SQLite par défaut, sans réseau ni GPU. Un compte et une conversation factices, créés avant la sauvegarde, ont été retrouvés après restauration. Ce résultat porte sur ce périmètre précis, et rien de plus.

Vérifié

Comptes et conversations stockés en SQLite, retrouvés après archivage du volume et restauration dans une instance isolée.

Non vérifié

Documents importés et index vectoriel (recherche dans les documents).

Non vérifié

Modèles Ollama : ni la copie du dossier models, ni son transfert vers une autre machine.

Non vérifié

Restauration sur une version d'Open WebUI différente de celle de la sauvegarde (migration de base).

Non vérifié

Installations avec PostgreSQL, sur x86_64 avec GPU, ou derrière un reverse proxy.

Pour tout ce qui figure en « non vérifié », la procédure décrite suit le fonctionnement documenté mais doit être contrôlée sur votre propre installation avant d'être considérée comme fiable. C'est précisément le rôle de l'instance de contrôle de la section précédente. Aucune durée de restauration ni aucun volume de données n'est donné ici : ils dépendent entièrement de la taille de votre base et de vos modèles.

#Dépannage

Écran de création de compte au lieu de l'historique

L'archive a été décompressée au mauvais endroit (un niveau de dossier en trop) ou dans un autre volume que celui monté. Listez le contenu avec docker run --rm -v open-webui:/data alpine ls -la /data : webui.db doit être à la racine.

Sessions refusées après restauration

WEBUI_SECRET_KEY a changé entre l'ancienne et la nouvelle instance. Les comptes restent en base ; une nouvelle connexion suffit en général. Fixez la variable explicitement pour les prochaines fois.

Aucun modèle dans la liste

Open WebUI ne joint pas Ollama. Vérifiez qu'Ollama répond sur http://localhost:11434 depuis l'hôte et que OLLAMA_BASE_URL pointe vers une adresse joignable depuis le conteneur (host.docker.internal avec l'option --add-host).

Erreur de base au démarrage

Copie faite conteneur allumé, ou image différente de celle de la sauvegarde. Repartez d'une archive faite conteneur arrêté et relancez avec l'image relevée.

ollama create échoue

Le modèle de base de la ligne FROM du Modelfile n'est pas installé. Lancez d'abord ollama pull sur ce modèle.

Archive anormalement petite

Volume monté vide ou mauvais nom de volume. Contrôlez docker volume ls et la rubrique Mounts du conteneur d'origine avant de conclure à une perte.

#Pour aller plus loin

La sauvegarde n'est qu'une partie de l'exploitation d'une stack locale. Ces guides couvrent l'installation d'Open WebUI qui sert de point de départ ici, l'entretien courant d'Ollama et la mise en service d'Ollama dans Docker.