Restaurar Open WebUI y Ollama tras una panne

#Lo que realmente hay que respaldar

Un stack local típico se compone de dos piezas: Ollama, el servicio que carga los modelos y responde en http://localhost:11434, y Open WebUI, la interfaz web que almacena las cuentas, el historial y la configuración. Cuando falla un disco, una actualización rompe un contenedor o se elimina un volumen de Docker por error, no desaparecen las mismas cosas, y no cuesta lo mismo reponerlas.

Los modelos pesan mucho, pero se pueden volver a descargar. Las conversaciones, las cuentas de usuario, los prompts guardados y los documentos importados son únicos: sin copia, se pierden. Por eso el esfuerzo de copia de seguridad debe centrarse prioritariamente en Open WebUI, y en Ollama lo principal es conservar una lista precisa de lo que estaba instalado.

Una copia de seguridad que nunca se ha restaurado sigue siendo una hipótesis. La única prueba de que funciona es restaurarla en otro lugar, en una instancia aislada, y encontrar allí tus datos. La sección «Demostrar que la restauración funciona» detalla esta comprobación; planifícala desde la primera copia de seguridad, no el día de la avería.

#Conversaciones, configuración, modelos: tres tipos de datos distintos

Conversaciones y cuentas

Historial de chats, usuarios, grupos, prompts y ajustes de administración guardados en la interfaz. Con la configuración predeterminada, todo eso reside en una base de datos SQLite (archivo webui.db) de la carpeta de datos de Open WebUI, montada en el contenedor en /app/backend/data. Si definiste DATABASE_URL apuntando a PostgreSQL, estos datos están en PostgreSQL y se respaldan con las herramientas de PostgreSQL, no copiando el volumen.

Documentos e índice

Archivos importados (subcarpeta uploads) e índice vectorial utilizado por la búsqueda en documentos (subcarpeta vector_db con la base de datos vectorial predeterminada). Están en el mismo volumen que webui.db, pero su restauración no se ha verificado en el marco de esta guía: consulta la sección dedicada a las limitaciones.

Configuración de despliegue

Lo que no está en el volumen: el comando docker run o el archivo docker-compose.yml, las variables de entorno (WEBUI_SECRET_KEY, OLLAMA_BASE_URL, DATABASE_URL…), la etiqueta y el digest exacto de la imagen, la configuración del proxy inverso. Todo esto debe versionarse aparte, sin dejar secretos en texto plano en un repositorio compartido.

Modelos Ollama

Los pesos de los modelos y sus manifiestos, en la carpeta models de Ollama. Son voluminosos y se pueden volver a descargar mientras el modelo siga publicado. Los modelos personalizados creados con un Modelfile son la excepción: hay que conservar el Modelfile.

#Prerrequisitos

Instalación de referencia

Open WebUI en Docker con un volumen con nombre (open-webui en el comando de instalación documentado) y la base de datos SQLite predeterminada. Para una instalación con pip o un volumen montado en una carpeta del host, el principio es el mismo: solo cambia la ruta.

Acceso

Una terminal con permisos de Docker en la máquina y una ubicación de almacenamiento fuera de esa máquina (disco externo, NAS, otro servidor). Una copia en el mismo disco no protege contra una falla del disco.

Ventana de inactividad

Unos minutos durante los cuales Open WebUI puede estar detenido. Copiar un archivo SQLite mientras se está escribiendo en él puede producir una copia inconsistente.

Instancia de prueba

Un lugar donde restaurar sin tocar producción: basta con otro nombre de contenedor y otro volumen en la misma máquina, con otro puerto.

Si Open WebUI aún no está instalado, empieza por la guía Open WebUI con Ollama que aparece al final de la página: el procedimiento de abajo parte del comando de Docker que allí se describe.

#Hacer copia de seguridad de Open WebUI: volumen, versión y configuración

1. 01
   1. Anotar la versión y la configuración

   Antes de hacer cualquier copia, anota la imagen utilizada, su hash (digest) y las variables de entorno. Restaurar los datos en la misma versión evita depender de una migración de la base de datos que no se haya verificado. Atención: la salida de docker inspect contiene tus variables y, por lo tanto, posibles secretos. Guarda este archivo con la misma precaución que la propia copia de seguridad.
2. 02
   2. Detener el contenedor

   docker stop open-webui le da tiempo a la aplicación para cerrar la base de datos correctamente. Así, las conversaciones que se están escribiendo se terminan antes de la copia.
3. 03
   3. Archivar el volumen

   Un contenedor temporal monta el volumen en modo de solo lectura y genera un archivo comprimido con fecha en la carpeta actual. El volumen no se modifica.
4. 04
   4. Reiniciar y sacar la copia de la máquina

   Vuelve a iniciar el contenedor y luego copia el archivo comprimido y el archivo de configuración al almacenamiento externo. Calcula un hash SHA-256 para detectar más adelante un archivo comprimido que se haya dañado durante la transferencia.

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 tu volumen tiene otro nombre, encuéntralo con docker inspect open-webui y la sección Mounts. Si usas docker compose, el nombre real del volumen suele llevar como prefijo el nombre del proyecto: docker volume ls lo muestra. Con PostgreSQL, añade un pg_dump de la base de datos: en ese caso, el archivo del volumen ya no contiene el historial de conversaciones.

#Hacer una copia de seguridad de Ollama y sus modelos

En el caso de Ollama, la cuestión no es tanto copiar decenas de gigabytes como poder reconstruir exactamente el mismo conjunto de modelos. Para ello, en la mayoría de los casos bastan tres elementos: la lista de modelos con su etiqueta exacta (qwen3:8b no es qwen3:8b-q8_0), los Modelfiles de los modelos personalizados y la configuración del servicio (variables como OLLAMA_HOST, OLLAMA_MODELS u OLLAMA_KEEP_ALIVE, a menudo en un override de 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 te preocupa el ancho de banda o la disponibilidad futura de un modelo, también puedes copiar la carpeta de modelos. Su ubicación depende de la instalación: ~/.ollama/models en macOS, C:\Users\<usuario>\.ollama\models en Windows, /usr/share/ollama/.ollama/models con el script de instalación de Linux, o el volumen montado en /root/.ollama con la imagen oficial de Docker. La variable OLLAMA_MODELS, si está definida, tiene prioridad sobre estas rutas. Detén Ollama durante la copia para no congelar una descarga escrita a medias.

#Restaurar Open WebUI y Ollama después de una falla: el procedimiento

El orden importa: primero Ollama, para que la interfaz encuentre sus modelos al arrancar; luego los datos de Open WebUI, y después el contenedor con la misma imagen y las mismas variables que antes. Restaura en un volumen nuevo en lugar de hacerlo encima de un volumen existente: en caso de error, el antiguo queda intacto.

1. 01
   1. Verificar el archivo

   Comprueba el hash SHA-256 antes de restaurar. Un archivo comprimido truncado por una copia interrumpida se detecta aquí, no después de haber sobrescrito algo.
2. 02
   2. Restablecer Ollama

   Reinstala Ollama, vuelve a aplicar tus variables de servicio y luego ejecuta de nuevo ollama pull para cada modelo de la lista y ollama create para cada Modelfile personalizado. Comprueba que la API responde en http://localhost:11434.
3. 03
   3. Recrear el volumen Open WebUI

   Crea un volumen vacío y descomprime en él el archivo comprimido con un contenedor temporal. El nombre del volumen debe coincidir con el de tu comando de inicio.
4. 04
   4. Volver a iniciar con la misma imagen

   Usa la imagen anotada durante la copia de seguridad (etiqueta o, mejor, digest) y las mismas variables de entorno, en particular WEBUI_SECRET_KEY y OLLAMA_BASE_URL si las habías definido.
5. 05
   5. Comprobar antes de volver a abrir el acceso

   Inicia sesión, abre algunas conversaciones antiguas y comprueba que aparezcan los modelos. Solo entonces vuelve a habilitar el acceso a los demás usuarios.

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

Reemplaza AAAA-MM-JJ por la fecha de tu archivo y ghcr.io/open-webui/open-webui:main por la imagen exacta anotada en el paso 1 de la copia de seguridad. Añade las opciones -e que usabas (secreto, URL de Ollama, base de datos). Si todavía existe un volumen open-webui antiguo y quieres conservarlo por precaución, restaura en un volumen con otro nombre y adapta la opción -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 modelo personalizado recreado a partir de su Modelfile necesita que el modelo base citado en la línea FROM esté presente: descarga primero los modelos base y luego crea las variantes. Si mientras tanto un modelo se retiró de la biblioteca de Ollama, ollama pull fallará; es el único caso en que una copia de la carpeta models habría evitado la pérdida.

#Demostrar que la restauración funciona antes de necesitarla

La prueba más útil se hace en frío, un día sin fallas: restaurar el último archivo en una instancia separada y comprobar que contiene datos conocidos. Una cuenta y una conversación de prueba, creadas a propósito con un contenido reconocible, sirven de testigo: si reaparecen, la cadena copia de seguridad-restauración funciona al menos para la base de datos.

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

La cuenta testigo inicia sesión con su contraseña original.

Historial

La conversación testigo está presente, con su contenido completo, así como algunas conversaciones reales antiguas.

Ajustes

La configuración de administración, los prompts guardados y los usuarios son los esperados.

Documentos

Si usas la búsqueda en documentos, haz una pregunta cuya respuesta se encuentre en un archivo importado. Es una comprobación que debes hacer tú mismo: no está cubierta por la verificación descrita más abajo.

Trace

Anota la fecha, el archivo comprimido utilizado y el resultado. Sin este registro, no podrás afirmar más adelante que la copia de seguridad se probó.

La instancia de control no necesita acceder a Ollama para verificar las cuentas y el historial: estos datos provienen de la base de datos, no de los modelos. Simplemente mostrará una lista de modelos vacía, lo cual es lo esperado.

#Lo que se verificó y lo que no

El 30/10/2026 se verificaron la copia de seguridad y la posterior restauración de Open WebUI en un marco deliberadamente limitado: contenedor Docker Open WebUI en arquitectura arm64, base de datos SQLite predeterminada, sin red ni GPU. Una cuenta y una conversación ficticias, creadas antes de la copia de seguridad, se encontraron después de la restauración. Este resultado se refiere a este alcance concreto y a nada más.

Verificado

Cuentas y conversaciones almacenadas en SQLite, recuperadas después de archivar el volumen y restaurarlo en una instancia aislada.

No verificado

Documentos importados e índice vectorial (búsqueda en los documentos).

No verificado

Modelos de Ollama: ni la copia de la carpeta models ni su transferencia a otra máquina.

No verificado

Restauración en una versión de Open WebUI distinta de la de la copia de seguridad (migración de la base de datos).

No verificado

Instalaciones con PostgreSQL, en x86_64 con GPU o detrás de un proxy inverso.

Para todo lo que figura como «no verificado», el procedimiento descrito sigue el funcionamiento documentado, pero debe comprobarse en tu propia instalación antes de considerarlo fiable. Ese es precisamente el papel de la instancia de control de la sección anterior. Aquí no se indica ninguna duración de restauración ni ningún volumen de datos: dependen totalmente del tamaño de tu base de datos y de tus modelos.

#Solución de problemas

Pantalla de creación de cuenta en lugar del historial

El archivo comprimido se descomprimió en el lugar equivocado (con un nivel de carpeta de más) o en un volumen distinto del montado. Lista el contenido con docker run --rm -v open-webui:/data alpine ls -la /data: webui.db debe estar en la raíz.

Sesiones rechazadas tras la restauración

WEBUI_SECRET_KEY cambió entre la instancia antigua y la nueva. Las cuentas siguen en la base de datos; por lo general basta con volver a iniciar sesión. Define la variable explícitamente para las próximas veces.

Ningún modelo en la lista

Open WebUI no logra conectarse con Ollama. Comprueba que Ollama responda en http://localhost:11434 desde el host y que OLLAMA_BASE_URL apunte a una dirección accesible desde el contenedor (host.docker.internal con la opción --add-host).

Error de base de datos al iniciar

Copia hecha con el contenedor encendido, o imagen distinta de la de la copia de seguridad. Parte de un archivo hecho con el contenedor detenido y vuelve a lanzarlo con la imagen anotada.

ollama create échoue

El modelo base de la línea FROM del Modelfile no está instalado. Ejecuta primero ollama pull sur para ese modelo.

Archivo anormalmente pequeño

Volumen montado vacío o nombre de volumen incorrecto. Revisa docker volume ls y la sección Mounts del contenedor original antes de concluir que hubo una pérdida.

#Para ir más allá

La copia de seguridad es solo una parte de la operación de un stack local. Estas guías cubren la instalación de Open WebUI que sirve aquí como punto de partida, el mantenimiento habitual de Ollama y la puesta en marcha de Ollama en Docker.