Mettre à jour et sauvegarder Open WebUI et Ollama sans rien casser

Comment mettre à jour sans perdre mes conversations ? C’est la question qui revient dès qu’Open WebUI et Ollama deviennent l’outil quotidien d’une asso lilloise, d’un atelier à Amiens ou d’une petite équipe à Valenciennes. Une mise à jour d’image Docker mal préparée peut laisser une interface jolie… et un volume de chats inaccessible, ou des modèles à retélécharger au plus mauvais moment. Ce tutoriel avancé décrit une routine : inventaire, sauvegarde, mise à jour, vérifications, restauration, puis automatisation légère. IAHDF est indépendant : pas de chemins magiques inventés, des placeholders clairs, des ordres de grandeur qualifiés, et le renvoi permanent vers la documentation officielle Docker, Open WebUI et Ollama du jour.

Pourquoi une routine plutôt qu’un « docker pull » improvisé

Open WebUI stocke en général conversations, réglages, utilisateurs et éventuels fichiers dans un volume Docker (ou un bind mount). Ollama conserve les poids des modèles dans son propre répertoire ou volume. Mettre à jour l’image sans snapshot, c’est jouer à pile ou face avec le travail de vos agents. Une mairie expérimentale près de Lens qui perd trois mois de fils de discussion perd aussi la confiance dans l’outil local.

La routine n’est pas de la bureaucratie : c’est ce qui permet d’oser mettre à jour. Sans elle, on reste bloqué sur une version vieillissante « parce que ça marche ». Avec elle, vous avancez par petits pas, un week-end sur deux, avec une porte de sortie. Reliez cette discipline à les bases d’une IA locale et aux sujets de durcissement déjà vus dans la série (par exemple voisinages avancés si présent dans votre catalogue).

Trois symptômes typiques d’absence de routine : personne ne sait quel tag tourne vraiment ; la seule sauvegarde date d’une install initiale ; la dernière mise à jour a été faite « vite fait » avant une démo. Inversez ces trois points et vous avez déjà gagné plus de résilience que n’importe quel gadget d’interface. IAHDF insiste sur ce point parce que l’indépendance technique se joue aussi dans la maintenance, pas seulement dans le choix du modèle.

Inventaire : savoir ce que l’on touche

Sur la machine hôte, listez les conteneurs, images (digests / tags), volumes et éventuels bind mounts. Repérez le fichier Compose ou la commande `docker run` qui a créé la stack. Notez les variables d’environnement non secrètes utiles (ports, noms de volumes). Stockez cette fiche hors du serveur (coffre d’équipe, papier dans le local technique de Boulogne).

Distinguez clairement : (A) données Open WebUI — chats, comptes, config UI ; (B) données Ollama — modèles ; (C) fichiers Compose et secrets. On peut mettre à jour A sans retélécharger B, et inversement. Beaucoup d’incidents viennent du mélange mental « tout est dans le conteneur » : non, le précieux est dans les volumes.

Sauvegarde : volumes, tar, et placeholders

Principe : arrêter proprement les conteneurs qui écrivent dans le volume (ou utiliser une méthode cohérente avec votre doc Docker du jour), archiver le volume vers un disque externe ou un partage de sauvegarde, redémarrer, vérifier la taille de l’archive et un test de lecture. Nommez les archives avec date ISO et rôle (`openwebui`, `ollama`). Conservez au moins deux générations récentes si l’espace le permet.

Ne copiez pas des chemins absolus inventés dans vos runbooks d’équipe : utilisez des variables (`VOLUME_OWUI`, `BACKUP_DIR`). Sur un NAS associatif à Roubaix comme sur un disque USB chiffré à Arras, le schéma reste le même. Testez une restauration sur une machine clone ou un second Compose avant le jour de panique.

#!/usr/bin/env bash
# Sauvegarde pédagogique IAHDF — à adapter à VOTRE hôte.
# Remplacez les placeholders. Vérifiez la doc Docker du jour.
# Ne commitez jamais de secrets dans ce fichier.

set -euo pipefail

# --- Placeholders à renseigner ---
BACKUP_DIR="${BACKUP_DIR:-/chemin/vers/backups}"   # ex. disque externe
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
VOLUME_OWUI="${VOLUME_OWUI:-nom_volume_open_webui}" # docker volume ls
VOLUME_OLLAMA="${VOLUME_OLLAMA:-nom_volume_ollama}" # optionnel
COMPOSE_DIR="${COMPOSE_DIR:-/chemin/vers/compose}" # là où est le compose.yml

mkdir -p "${BACKUP_DIR}/${STAMP}"

# 1) Figer la fiche d’inventaire
{
  echo "stamp=${STAMP}"
  docker compose -f "${COMPOSE_DIR}/compose.yml" images || true
  docker volume ls
} > "${BACKUP_DIR}/${STAMP}/inventory.txt"

# 2) Arrêt propre (Compose) — adaptez le nom de projet
docker compose -f "${COMPOSE_DIR}/compose.yml" stop

# 3) Archive du volume Open WebUI via conteneur Alpine
docker run --rm \
  -v "${VOLUME_OWUI}:/volume:ro" \
  -v "${BACKUP_DIR}/${STAMP}:/backup" \
  alpine:3.20 \
  tar czf "/backup/openwebui-data.tgz" -C /volume .

# 4) Archive Ollama (si volume Docker dédié)
if docker volume inspect "${VOLUME_OLLAMA}" >/dev/null 2>&1; then
  docker run --rm \
    -v "${VOLUME_OLLAMA}:/volume:ro" \
    -v "${BACKUP_DIR}/${STAMP}:/backup" \
    alpine:3.20 \
    tar czf "/backup/ollama-data.tgz" -C /volume .
fi

# 5) Copier le Compose (sans secrets si ailleurs)
cp "${COMPOSE_DIR}/compose.yml" "${BACKUP_DIR}/${STAMP}/compose.yml" || true

# 6) Redémarrage
docker compose -f "${COMPOSE_DIR}/compose.yml" start

# 7) Contrôles minimaux
ls -lh "${BACKUP_DIR}/${STAMP}"
echo "Sauvegarde terminée : ${BACKUP_DIR}/${STAMP}"
# Vérifiez ensuite login Open WebUI + un chat témoin + ollama list

Mise à jour des images sans précipitation

Épinglez d’abord le tag actuel (pas seulement `latest` mental). Lisez les notes de version Open WebUI et Ollama du jour : breaking changes, migrations, variables renommées. Sur un clone ou une fenêtre de maintenance annoncée, `docker compose pull` puis `up -d` (ou équivalent). Gardez l’ancien tag récupérable localement jusqu’à validation humaine.

Ordre prudent souvent observé : (1) sauvegarde, (2) mise à jour Ollama si nécessaire, (3) smoke test `ollama list` / une génération courte, (4) mise à jour Open WebUI, (5) smoke test UI. Inverser parfois selon les notes de version — la doc officielle prime sur ce tutoriel. Ne mettez pas à jour le vendredi 18 h avant un atelier public à Lille sans plan de restauration.

Si vous gérez plusieurs instances (labo + production atelier), mettez à jour d’abord le labo pendant une semaine d’usage réel. Les régressions d’UI ou de permissions apparaissent souvent à l’usage, pas au premier login. Notez dans le runbook le délai d’observation choisi — trois jours peuvent suffire pour une petite équipe, davantage si des outils ou pipelines critiques sont en jeu.

Vérifications après bascule

Checklist courte : conteneurs healthy / running ; port UI joignable sur le LAN ; login admin et compte utilisateur test ; ouverture d’un chat ancien ; envoi d’un nouveau message vers un modèle connu ; éventuels outils ou pipelines critiques encore listés ; horloge et permissions fichiers si bind mounts. Chronométrez qualitative­ment : « normal / plus lent / cassé », sans inventer de tokens/s.

Si la UI démarre mais les conversations manquent, arrêtez tout et passez en restauration : ne « réparez » pas en créant un nouveau volume vide qui écraserait la piste. Si les chats sont là mais le modèle manque, c’est souvent le volume Ollama ou un tag de modèle non rétiré — problème distinct de la base Open WebUI.

Modèles Ollama : migrer, retirer, ne pas paniquer

Les poids occupent beaucoup d’espace : une sauvegarde complète du volume modèles est longue et volumineuse. Stratégies : sauvegarder systématiquement Open WebUI ; pour Ollama, soit volume complet sur gros disque, soit accepter un `ollama pull` des tags documentés après restauration machine. Tenez un fichier `models.txt` avec les tags réellement utilisés en production (pas toute la zoo téléchargée un soir de curiosité).

Après restauration ou nouvel hôte : `ollama list`, comparez à `models.txt`, retéléchargez les manquants. Pour une asso qui anime des ateliers hebdomadaires à Compiègne, mieux vaut trois tags stables documentés que quinze expérimentaux oubliés. Croisez avec bonnes pratiques de stack locale si ce contenu est dans votre catalogue.

Restauration : la compétence qui rachète la mise à jour

Scénario A — régression UI : `compose` avec l’ancien tag d’image Open WebUI, volume intact. Scénario B — volume corrompu ou perdu : stop, restauration du tar dans un volume neuf au bon nom, start, vérification. Scénario C — hôte mort : réinstall Docker, volumes depuis sauvegarde externe, Compose depuis la fiche, retags modèles. Chaque scénario doit avoir été joué une fois « à blanc ».

Documentez qui a le droit de restaurer (pas douze comptes admin). Après restauration réussie, refaites une sauvegarde fraîche : vous venez de prouver que la chaîne marche, figez cet état.

Astuce de terrain : conservez un chat témoin nommé clairement (« TÉMOIN SAUVEGARDE — ne pas supprimer ») avec une phrase unique. Après restore, cherchez cette phrase. Si elle est là, votre volume Open WebUI est probablement le bon. Ce test humble évite de valider trop vite une instance « qui se lance » mais qui pointe vers un volume neuf vide. En atelier à Amiens, ce geste a déjà évité une fausse victoire avant l’arrivée du public.

Automatiser : la sauvegarde oui, la bascule non

Automatisez l’archive nocturne des volumes vers un disque dédié, avec rotation (garder N dernières). Surveillez l’échec du job (mail local, notification LAN). N’automatisez pas `latest` en production sans filet : une image cassée un mardi à 3 h ruine le mercredi d’atelier. Exception possible : labo jetable explicitement jetable.

Pour une communauté de communes ou un Fab Lab près de Saint-Quentin, un runbook d’une page collé au mur vaut mieux qu’un wiki abandonné : inventaire, commande de backup, commande de restore, contacts. Revisitez-le après chaque incident réel.

Côté planification : une tâche hebdomadaire de backup complet Open WebUI, une tâche mensuelle qui inclut aussi Ollama si l’espace le permet, et un créneau trimestriel d’exercice de restauration. Adaptez les fréquences à votre criticité — une instance de démo rare n’a pas les mêmes exigences qu’un outil quotidien d’équipe. L’essentiel est la régularité et l’alerte en cas d’échec, pas la sophistication de l’outil de scheduling.

Gouvernance légère en Hauts-de-France

Nommez un responsable de la stack (même à 10 %). Tenez le registre des fenêtres de MAJ. Séparez compte admin Docker et comptes utilisateurs Open WebUI. Rapportez en cinq minutes lors d’une réunion d’équipe : date de dernière sauvegarde testée, date de dernière MAJ, incidents. Cette hygiène protège l’indépendance de votre IA locale mieux qu’un modèle plus gros.

Rappel IAHDF : pas de prix d’hébergement inventés, pas de benchmarks tokens/s, pas de promesses « zero downtime » sans architecture haute disponibilité réelle. Mesurez vos durées de maintenance chez vous et communiquez-les honnêtement aux usagers.

Pour aller plus loin