Бэкап и восстановление ИИ-стека на сервере

MAATRIX

После случайного docker volume rm, сгоревшего диска или переустановки Ubuntu выясняется: чаты и пользователи Open WebUI пропали, а модели Ollama придётся качать заново — и это ещё повезло, если только их. ИИ-стек бэкапится не так, как обычный сайт: почти весь его вес — веса моделей, копировать которые бессмысленно, а по-настоящему ценные мегабайты легко потерять, снимая бэкап «на глаз». Разберём, что из Ollama и Open WebUI стоит сохранять, как автоматизировать это без даунтайма и как восстановиться на чистом сервере с первого раза.

Что в ИИ-стеке действительно нужно бэкапить

Связка Ollama и Open WebUI — та самая, что разворачивается одной кнопкой из каталога MAATRIX, — при аварии ведёт себя по-разному. Ollama хранит веса моделей: гигабайты бинарных данных, доступных для повторной закачки в любой момент. Open WebUI хранит то, что создали именно вы: пользователей, переписку, документы и ключи провайдеров — и это без бэкапа не вернуть.

Разложите по полочкам, прежде чем писать первый tar:

Ключевая мысль статьи: бэкап ИИ-стека почти ничего не весит, если исключить из него веса моделей. Реальный объём ценных данных — от единиц до нескольких десятков мегабайт плюс размер загруженных документов. Меньше архив — быстрее снимается и быстрее уезжает в другое место.

Почему «просто скопировать диск» подводит в момент аварии

Первый инстинкт — снять образ диска или заархивировать каталог целиком, пока всё работает. Для ИИ-стека это ловушка сразу по двум причинам.

Первая — размер. Одна модель 7B в Q4 — это уже около 4,5 ГБ весов, а если на сервере их три-четыре, счёт идёт на десятки гигабайт, которые каждую ночь будут перегоняться в архив без единого изменённого внутри байта. На небыстром канале или платном исходящем трафике это чистые потери.

Вторая причина серьёзнее — согласованность. webui.db — обычный файл SQLite, и пока Open WebUI работает, база может оказаться в процессе записи именно в момент, когда до неё дотянется tar. Файловый снимок «на живую» иногда проходит без вопросов, а иногда даёт при восстановлении:

sqlite3.OperationalError: database disk image is malformed

или чуть менее фатальное:

sqlite3.OperationalError: database is locked

Оба сообщения — стандартные ошибки SQLite, они возникают не из-за бага в Open WebUI, а из-за самого способа снятия копии. Правильный бэкап либо останавливает писателя на пару секунд, либо использует собственный механизм СУБД для согласованного снимка — разберём оба варианта.

Бэкап шаг за шагом: команды для Ollama и Open WebUI

Для Ollama достаточно текстового списка — он крошечный и восстанавливается без сюрпризов:

ollama list | awk 'NR>1{print 
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
Бэкап шаг за шагом: команды для Ollama и Open WebUI
Для Ollama достаточно текстового списка — он крошечный и восстанавливается без сюрпризов:
ollama list | awk 'NR>1{print $1}' > /opt/backups/ollama-models-$(date +%F).txt
Заодно сохраните Modelfile для каждой модели — команда работает и для скачанных из реестра, и для кастомных, а весят такие файлы единицы килобайт:
mkdir -p /opt/backups/modelfiles
for m in $(ollama list | awk 'NR>1{print $1}'); do
  ollama show "$m" --modelfile > "/opt/backups/modelfiles/${m}.Modelfile"
done
Без этого шага восстановление кастомной модели через ollama pull имямодели ответит Error: pull model manifest: file does not exist — в публичном реестре такого имени никогда не было, взять его неоткуда.
Для Open WebUI по умолчанию хватает короткой остановки: docker compose stop не удаляет контейнер и не трогает настройки, поэтому перезапуск занимает секунды, а не минуты повторной конфигурации.
cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar czf /backup/openwebui-$(date +%F).tar.gz -C /data .
docker compose start open-webui
Заберите том целиком, а не только webui.db: точная раскладка каталогов uploads и векторного индекса — деталь реализации, которая менялась между версиями Open WebUI, и выборочное копирование рискует упустить файл, о существовании которого вы даже не подозревали. Точное имя тома, как в любой Compose-установке, уточняйте через docker volume ls — оно склеивается из имени каталога проекта и имени тома в compose.yaml.
Отдельно, в закрытый для посторонних каталог, скопируйте compose.yaml, systemd drop-in /etc/systemd/system/ollama.service.d/override.conf и файл с WEBUI_SECRET_KEY, если задавали его вручную. Здесь же нередко лежат ключи внешних провайдеров, подключённые через настройки Open WebUI, — обращайтесь с этим бэкапом как с секретом, а не как с обычным архивом.
Автоматизация: cron, ротация и проверка, что бэкап не сломался тихо
Ручной запуск команд выше работает ровно до первого забытого вторника. Соберите их в один скрипт /opt/backups/ai-stack-backup.sh:
#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
DIR=/opt/backups

ollama list | awk 'NR>1{print $1}' > "$DIR/ollama-models-$DATE.txt"

cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v "$DIR":/backup alpine \
  tar czf /backup/openwebui-$DATE.tar.gz -C /data .
docker compose start open-webui

gzip -t "$DIR/openwebui-$DATE.tar.gz"
[ -s "$DIR/ollama-models-$DATE.txt" ]

find "$DIR" -name 'openwebui-*.tar.gz' -mtime +14 -delete
find "$DIR" -name 'ollama-models-*.txt' -mtime +14 -delete
set -euo pipefail в начале — не формальность: без него скрипт продолжит работу и сотрёт старые копии, даже если docker run выше упал с ошибкой, — и вы останетесь без единого рабочего бэкапа, зато с чистой историей находок find.
Планировщик — системный /etc/cron.d/ai-stack-backup, а не пользовательский crontab -e: у файлов в cron.d обязательна колонка с именем пользователя, и если вставить туда строку из обычного crontab, cron откажется её выполнять.
0 3 * * * root /opt/backups/ai-stack-backup.sh >> /var/log/ai-stack-backup.log 2>&1
Перенаправление в лог не для галочки: у cron минимальное окружение и никакого интерактивного вывода, ошибка молча растворится, если не писать её в файл явно. Проверяйте результат самого свежего запуска:
tail -20 /var/log/ai-stack-backup.log
ls -lh /opt/backups | tail -5
Если в стеке уже стоит Uptime Kuma из того же каталога приложений, добавьте в конец скрипта одну строку с push-мониторингом — он не проверяет содержимое бэкапа, зато честно сообщит, если скрипт вообще не отработал:
curl -fsS "https://kuma.example.com/api/push/xxxxxxxx?status=up" >/dev/null || true
Восстановление на новом сервере: пошагово
Бэкап без проверенного восстановления — это архив, о котором вы верите, а не знаете. Разложим процесс на чистом сервере.
Если заказывали приложение Ollama из каталога MAATRIX, сервис и контейнер уже подняты и связаны между собой — переходите сразу к возврату данных. Если ставили руками, сначала повторите установку Ubuntu 24.04 тем же путём и только потом восстанавливайтесь.
Модели Ollama. Убедитесь, что сервис запущен, и прогоните сохранённый список через pull.
sudo systemctl status ollama --no-pager
while read -r model; do ollama pull "$model"; done < ollama-models-2026-08-20.txt
Если вместо списка вы держали полный архив manifests и blobs — оправдано для приватных моделей или дорогого трафика, — верните его до старта сервиса и поправьте владельца файлов, иначе вернётесь к проблеме «ollama list пустой, хотя файлы на месте»:
sudo systemctl stop ollama
sudo rsync -a /backup/ollama-models/ /usr/share/ollama/.ollama/models/
sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models
sudo systemctl start ollama
ollama list
Кастомные модели поднимите из сохранённых Modelfile:
ollama create мойассистент -f мойассистент.Modelfile
Данные Open WebUI. Создайте том и наполните его архивом до первого старта контейнера — иначе Compose создаст пустой том, и данные придётся заливать поверх уже работающего процесса.
docker volume create open-webui_open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar xzf /backup/openwebui-2026-08-20.tar.gz -C /data
cd /opt/open-webui && docker compose up -d
На новом хосте адрес шлюза docker0 из старого compose.yaml может не совпасть — Docker выдаёт его динамически, и 172.17.0.1 не гарантирован, если на сервере уже есть другие сети:
ip -4 addr show docker0
Поправьте OLLAMA_BASE_URL=http://<адрес>:11434 под фактический адрес и перезапустите docker compose up -d. Про WEBUI_SECRET_KEY можно не переживать: если он не совпал со старым, пользователи один раз перелогинятся — данные это не затронет.
Проверка на этом не заканчивается: docker compose logs -f open-webui должен показать чистый старт без трейсбеков, а после входа сверьте, что модели и история чатов совпадают с тем, что было до аварии.
Нюансы, о которых часто забывают
Версия образа на момент бэкапа. Тег :main у ghcr.io/open-webui/open-webui — плавающая ветка, и к моменту восстановления реестр может уйти на версию вперёд. Обычно это безобидно — образ сам прогонит миграции схемы при первом старте, — но при аварии спокойнее поднять именно ту версию, что работала раньше. Зафиксируйте её заранее:
docker inspect --format='{{.Image}}' open-webui
Бэкап без остановки контейнера. Секундная пауза от docker compose stop не подходит, если в интерфейсе постоянно сидят люди. SQLite отдаёт согласованный снимок через собственный Backup API, и до него легко достать из Python внутри контейнера — интерпретатор там точно есть, это среда исполнения самого Open WebUI:
docker compose exec -T open-webui python3 -c \
  "import sqlite3; s=sqlite3.connect('/app/backend/data/webui.db'); d=sqlite3.connect('/tmp/webui.bak'); s.backup(d); d.close(); s.close()"
docker cp open-webui:/tmp/webui.bak /opt/backups/webui-$(date +%F).db
docker compose exec -T open-webui rm -f /tmp/webui.bak
Так копия базы снимается без простоя; каталог uploads можно архивировать так же, без остановки — это обычные дописанные файлы, а не меняющаяся на лету структура вроде базы.
В бэкапе лежат чужие секреты. Ключи OpenAI, Anthropic и других провайдеров, подключённые через настройки Open WebUI, попадают прямиком в webui.db. Архив с базой не менее чувствителен, чем .env: права 600, отдельный пользователь для бэкапов и шифрование архива перед тем, как он уедет с сервера — подробности в статье про бэкап с шифрованием.
Если в стеке есть LiteLLM. У него своя пара критичных значений — LITELLM_MASTER_KEY и LITELLM_SALT_KEY. Бэкап его базы без salt-ключа бесполезен: без него ключи провайдеров в базе не расшифровать, и это отдельная больная тема.
Копия должна жить не на том же диске. Правило «3-2-1» никто не отменял: рабочая копия, локальный бэкап и хотя бы одна копия за пределами сервера. Раз в месяц реально поднимайте архив на тестовой машине — только так вы узнаете о проблеме заранее, а не когда она уже стала проблемой с данными.
Какой сервер и локацию брать под ИИ-стек с бэкапами
Требования к вычислениям задаёт не бэкап, а сама модель — расчёт по памяти для конкретных весов разобран в статье о том, сколько RAM нужно для Ollama. Здесь — только то, что добавляет к этим цифрам тема сегодняшней статьи.
Честный минимум — 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Это нижняя граница, на которой каталожное приложение Ollama + Open WebUI на тарифе Heka ощущается комфортно: модель 7B в Q4 занимает около 4,5 ГБ весов, и на многое сверх контейнера и системы память уже не остаётся. Бэкапам здесь тесно по диску: если храните ещё и полный архив весов кастомной модели, закладывайте под /opt/backups отдельный раздел — иначе pull новой модели и ночной cron рано или поздно поборются за гигабайты.
Комфортный вариант — 8 vCPU, 16 ГБ RAM, 120–150 ГБ NVMe. Разница не в скорости бэкапа — он и на минимуме весит немного, — а в свободе: несколько моделей одновременно, RAG-документы без взгляда на df -h и запас на тридцать ежедневных копий вместо семи. На такой конфигурации удобно держать и тестовое восстановление — рядом, не трогая рабочий стек.
Локация — Лондон (UK). В повседневной работе это доступ к ghcr.io, Docker Hub и Hugging Face без блокировок, низкий пинг до Европы и соседство с GDPR. Для темы бэкапов важнее другое: при аварии веса моделей вы не восстанавливаете из архива, а качаете заново из реестра, и тут пропускная способность решает, займёт это пять минут или полтора часа простоя. Именно этот сценарий у российской площадки страдает первым.
В каталоге Ollama и Open WebUI разворачиваются одной кнопкой при заказе сервера — доступы появятся в личном кабинете, но бэкап каталог за вас не настроит, это по-прежнему ваш cron. Конфигурация покрупнее — выбрать здесь. Под вынесенную копию бэкапов хватит младшего тарифа в другой локации, скажем в России или США, с диском под архивы и SSH для rsync. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
}' > /opt/backups/ollama-models-$(date +%F).txt

Заодно сохраните Modelfile для каждой модели — команда работает и для скачанных из реестра, и для кастомных, а весят такие файлы единицы килобайт:

mkdir -p /opt/backups/modelfiles
for m in $(ollama list | awk 'NR>1{print 
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
Бэкап шаг за шагом: команды для Ollama и Open WebUI
Для Ollama достаточно текстового списка — он крошечный и восстанавливается без сюрпризов:
ollama list | awk 'NR>1{print $1}' > /opt/backups/ollama-models-$(date +%F).txt
Заодно сохраните Modelfile для каждой модели — команда работает и для скачанных из реестра, и для кастомных, а весят такие файлы единицы килобайт:
mkdir -p /opt/backups/modelfiles
for m in $(ollama list | awk 'NR>1{print $1}'); do
  ollama show "$m" --modelfile > "/opt/backups/modelfiles/${m}.Modelfile"
done
Без этого шага восстановление кастомной модели через ollama pull имямодели ответит Error: pull model manifest: file does not exist — в публичном реестре такого имени никогда не было, взять его неоткуда.
Для Open WebUI по умолчанию хватает короткой остановки: docker compose stop не удаляет контейнер и не трогает настройки, поэтому перезапуск занимает секунды, а не минуты повторной конфигурации.
cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar czf /backup/openwebui-$(date +%F).tar.gz -C /data .
docker compose start open-webui
Заберите том целиком, а не только webui.db: точная раскладка каталогов uploads и векторного индекса — деталь реализации, которая менялась между версиями Open WebUI, и выборочное копирование рискует упустить файл, о существовании которого вы даже не подозревали. Точное имя тома, как в любой Compose-установке, уточняйте через docker volume ls — оно склеивается из имени каталога проекта и имени тома в compose.yaml.
Отдельно, в закрытый для посторонних каталог, скопируйте compose.yaml, systemd drop-in /etc/systemd/system/ollama.service.d/override.conf и файл с WEBUI_SECRET_KEY, если задавали его вручную. Здесь же нередко лежат ключи внешних провайдеров, подключённые через настройки Open WebUI, — обращайтесь с этим бэкапом как с секретом, а не как с обычным архивом.
Автоматизация: cron, ротация и проверка, что бэкап не сломался тихо
Ручной запуск команд выше работает ровно до первого забытого вторника. Соберите их в один скрипт /opt/backups/ai-stack-backup.sh:
#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
DIR=/opt/backups

ollama list | awk 'NR>1{print $1}' > "$DIR/ollama-models-$DATE.txt"

cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v "$DIR":/backup alpine \
  tar czf /backup/openwebui-$DATE.tar.gz -C /data .
docker compose start open-webui

gzip -t "$DIR/openwebui-$DATE.tar.gz"
[ -s "$DIR/ollama-models-$DATE.txt" ]

find "$DIR" -name 'openwebui-*.tar.gz' -mtime +14 -delete
find "$DIR" -name 'ollama-models-*.txt' -mtime +14 -delete
set -euo pipefail в начале — не формальность: без него скрипт продолжит работу и сотрёт старые копии, даже если docker run выше упал с ошибкой, — и вы останетесь без единого рабочего бэкапа, зато с чистой историей находок find.
Планировщик — системный /etc/cron.d/ai-stack-backup, а не пользовательский crontab -e: у файлов в cron.d обязательна колонка с именем пользователя, и если вставить туда строку из обычного crontab, cron откажется её выполнять.
0 3 * * * root /opt/backups/ai-stack-backup.sh >> /var/log/ai-stack-backup.log 2>&1
Перенаправление в лог не для галочки: у cron минимальное окружение и никакого интерактивного вывода, ошибка молча растворится, если не писать её в файл явно. Проверяйте результат самого свежего запуска:
tail -20 /var/log/ai-stack-backup.log
ls -lh /opt/backups | tail -5
Если в стеке уже стоит Uptime Kuma из того же каталога приложений, добавьте в конец скрипта одну строку с push-мониторингом — он не проверяет содержимое бэкапа, зато честно сообщит, если скрипт вообще не отработал:
curl -fsS "https://kuma.example.com/api/push/xxxxxxxx?status=up" >/dev/null || true
Восстановление на новом сервере: пошагово
Бэкап без проверенного восстановления — это архив, о котором вы верите, а не знаете. Разложим процесс на чистом сервере.
Если заказывали приложение Ollama из каталога MAATRIX, сервис и контейнер уже подняты и связаны между собой — переходите сразу к возврату данных. Если ставили руками, сначала повторите установку Ubuntu 24.04 тем же путём и только потом восстанавливайтесь.
Модели Ollama. Убедитесь, что сервис запущен, и прогоните сохранённый список через pull.
sudo systemctl status ollama --no-pager
while read -r model; do ollama pull "$model"; done < ollama-models-2026-08-20.txt
Если вместо списка вы держали полный архив manifests и blobs — оправдано для приватных моделей или дорогого трафика, — верните его до старта сервиса и поправьте владельца файлов, иначе вернётесь к проблеме «ollama list пустой, хотя файлы на месте»:
sudo systemctl stop ollama
sudo rsync -a /backup/ollama-models/ /usr/share/ollama/.ollama/models/
sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models
sudo systemctl start ollama
ollama list
Кастомные модели поднимите из сохранённых Modelfile:
ollama create мойассистент -f мойассистент.Modelfile
Данные Open WebUI. Создайте том и наполните его архивом до первого старта контейнера — иначе Compose создаст пустой том, и данные придётся заливать поверх уже работающего процесса.
docker volume create open-webui_open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar xzf /backup/openwebui-2026-08-20.tar.gz -C /data
cd /opt/open-webui && docker compose up -d
На новом хосте адрес шлюза docker0 из старого compose.yaml может не совпасть — Docker выдаёт его динамически, и 172.17.0.1 не гарантирован, если на сервере уже есть другие сети:
ip -4 addr show docker0
Поправьте OLLAMA_BASE_URL=http://<адрес>:11434 под фактический адрес и перезапустите docker compose up -d. Про WEBUI_SECRET_KEY можно не переживать: если он не совпал со старым, пользователи один раз перелогинятся — данные это не затронет.
Проверка на этом не заканчивается: docker compose logs -f open-webui должен показать чистый старт без трейсбеков, а после входа сверьте, что модели и история чатов совпадают с тем, что было до аварии.
Нюансы, о которых часто забывают
Версия образа на момент бэкапа. Тег :main у ghcr.io/open-webui/open-webui — плавающая ветка, и к моменту восстановления реестр может уйти на версию вперёд. Обычно это безобидно — образ сам прогонит миграции схемы при первом старте, — но при аварии спокойнее поднять именно ту версию, что работала раньше. Зафиксируйте её заранее:
docker inspect --format='{{.Image}}' open-webui
Бэкап без остановки контейнера. Секундная пауза от docker compose stop не подходит, если в интерфейсе постоянно сидят люди. SQLite отдаёт согласованный снимок через собственный Backup API, и до него легко достать из Python внутри контейнера — интерпретатор там точно есть, это среда исполнения самого Open WebUI:
docker compose exec -T open-webui python3 -c \
  "import sqlite3; s=sqlite3.connect('/app/backend/data/webui.db'); d=sqlite3.connect('/tmp/webui.bak'); s.backup(d); d.close(); s.close()"
docker cp open-webui:/tmp/webui.bak /opt/backups/webui-$(date +%F).db
docker compose exec -T open-webui rm -f /tmp/webui.bak
Так копия базы снимается без простоя; каталог uploads можно архивировать так же, без остановки — это обычные дописанные файлы, а не меняющаяся на лету структура вроде базы.
В бэкапе лежат чужие секреты. Ключи OpenAI, Anthropic и других провайдеров, подключённые через настройки Open WebUI, попадают прямиком в webui.db. Архив с базой не менее чувствителен, чем .env: права 600, отдельный пользователь для бэкапов и шифрование архива перед тем, как он уедет с сервера — подробности в статье про бэкап с шифрованием.
Если в стеке есть LiteLLM. У него своя пара критичных значений — LITELLM_MASTER_KEY и LITELLM_SALT_KEY. Бэкап его базы без salt-ключа бесполезен: без него ключи провайдеров в базе не расшифровать, и это отдельная больная тема.
Копия должна жить не на том же диске. Правило «3-2-1» никто не отменял: рабочая копия, локальный бэкап и хотя бы одна копия за пределами сервера. Раз в месяц реально поднимайте архив на тестовой машине — только так вы узнаете о проблеме заранее, а не когда она уже стала проблемой с данными.
Какой сервер и локацию брать под ИИ-стек с бэкапами
Требования к вычислениям задаёт не бэкап, а сама модель — расчёт по памяти для конкретных весов разобран в статье о том, сколько RAM нужно для Ollama. Здесь — только то, что добавляет к этим цифрам тема сегодняшней статьи.
Честный минимум — 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Это нижняя граница, на которой каталожное приложение Ollama + Open WebUI на тарифе Heka ощущается комфортно: модель 7B в Q4 занимает около 4,5 ГБ весов, и на многое сверх контейнера и системы память уже не остаётся. Бэкапам здесь тесно по диску: если храните ещё и полный архив весов кастомной модели, закладывайте под /opt/backups отдельный раздел — иначе pull новой модели и ночной cron рано или поздно поборются за гигабайты.
Комфортный вариант — 8 vCPU, 16 ГБ RAM, 120–150 ГБ NVMe. Разница не в скорости бэкапа — он и на минимуме весит немного, — а в свободе: несколько моделей одновременно, RAG-документы без взгляда на df -h и запас на тридцать ежедневных копий вместо семи. На такой конфигурации удобно держать и тестовое восстановление — рядом, не трогая рабочий стек.
Локация — Лондон (UK). В повседневной работе это доступ к ghcr.io, Docker Hub и Hugging Face без блокировок, низкий пинг до Европы и соседство с GDPR. Для темы бэкапов важнее другое: при аварии веса моделей вы не восстанавливаете из архива, а качаете заново из реестра, и тут пропускная способность решает, займёт это пять минут или полтора часа простоя. Именно этот сценарий у российской площадки страдает первым.
В каталоге Ollama и Open WebUI разворачиваются одной кнопкой при заказе сервера — доступы появятся в личном кабинете, но бэкап каталог за вас не настроит, это по-прежнему ваш cron. Конфигурация покрупнее — выбрать здесь. Под вынесенную копию бэкапов хватит младшего тарифа в другой локации, скажем в России или США, с диском под архивы и SSH для rsync. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
}'); do
  ollama show "$m" --modelfile > "/opt/backups/modelfiles/${m}.Modelfile"
done

Без этого шага восстановление кастомной модели через ollama pull имямодели ответит Error: pull model manifest: file does not exist — в публичном реестре такого имени никогда не было, взять его неоткуда.

Для Open WebUI по умолчанию хватает короткой остановки: docker compose stop не удаляет контейнер и не трогает настройки, поэтому перезапуск занимает секунды, а не минуты повторной конфигурации.

cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar czf /backup/openwebui-$(date +%F).tar.gz -C /data .
docker compose start open-webui

Заберите том целиком, а не только webui.db: точная раскладка каталогов uploads и векторного индекса — деталь реализации, которая менялась между версиями Open WebUI, и выборочное копирование рискует упустить файл, о существовании которого вы даже не подозревали. Точное имя тома, как в любой Compose-установке, уточняйте через docker volume ls — оно склеивается из имени каталога проекта и имени тома в compose.yaml.

Отдельно, в закрытый для посторонних каталог, скопируйте compose.yaml, systemd drop-in /etc/systemd/system/ollama.service.d/override.conf и файл с WEBUI_SECRET_KEY, если задавали его вручную. Здесь же нередко лежат ключи внешних провайдеров, подключённые через настройки Open WebUI, — обращайтесь с этим бэкапом как с секретом, а не как с обычным архивом.

Автоматизация: cron, ротация и проверка, что бэкап не сломался тихо

Ручной запуск команд выше работает ровно до первого забытого вторника. Соберите их в один скрипт /opt/backups/ai-stack-backup.sh:

#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
DIR=/opt/backups

ollama list | awk 'NR>1{print 
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
Бэкап шаг за шагом: команды для Ollama и Open WebUI
Для Ollama достаточно текстового списка — он крошечный и восстанавливается без сюрпризов:
ollama list | awk 'NR>1{print $1}' > /opt/backups/ollama-models-$(date +%F).txt
Заодно сохраните Modelfile для каждой модели — команда работает и для скачанных из реестра, и для кастомных, а весят такие файлы единицы килобайт:
mkdir -p /opt/backups/modelfiles
for m in $(ollama list | awk 'NR>1{print $1}'); do
  ollama show "$m" --modelfile > "/opt/backups/modelfiles/${m}.Modelfile"
done
Без этого шага восстановление кастомной модели через ollama pull имямодели ответит Error: pull model manifest: file does not exist — в публичном реестре такого имени никогда не было, взять его неоткуда.
Для Open WebUI по умолчанию хватает короткой остановки: docker compose stop не удаляет контейнер и не трогает настройки, поэтому перезапуск занимает секунды, а не минуты повторной конфигурации.
cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar czf /backup/openwebui-$(date +%F).tar.gz -C /data .
docker compose start open-webui
Заберите том целиком, а не только webui.db: точная раскладка каталогов uploads и векторного индекса — деталь реализации, которая менялась между версиями Open WebUI, и выборочное копирование рискует упустить файл, о существовании которого вы даже не подозревали. Точное имя тома, как в любой Compose-установке, уточняйте через docker volume ls — оно склеивается из имени каталога проекта и имени тома в compose.yaml.
Отдельно, в закрытый для посторонних каталог, скопируйте compose.yaml, systemd drop-in /etc/systemd/system/ollama.service.d/override.conf и файл с WEBUI_SECRET_KEY, если задавали его вручную. Здесь же нередко лежат ключи внешних провайдеров, подключённые через настройки Open WebUI, — обращайтесь с этим бэкапом как с секретом, а не как с обычным архивом.
Автоматизация: cron, ротация и проверка, что бэкап не сломался тихо
Ручной запуск команд выше работает ровно до первого забытого вторника. Соберите их в один скрипт /opt/backups/ai-stack-backup.sh:
#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
DIR=/opt/backups

ollama list | awk 'NR>1{print $1}' > "$DIR/ollama-models-$DATE.txt"

cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v "$DIR":/backup alpine \
  tar czf /backup/openwebui-$DATE.tar.gz -C /data .
docker compose start open-webui

gzip -t "$DIR/openwebui-$DATE.tar.gz"
[ -s "$DIR/ollama-models-$DATE.txt" ]

find "$DIR" -name 'openwebui-*.tar.gz' -mtime +14 -delete
find "$DIR" -name 'ollama-models-*.txt' -mtime +14 -delete
set -euo pipefail в начале — не формальность: без него скрипт продолжит работу и сотрёт старые копии, даже если docker run выше упал с ошибкой, — и вы останетесь без единого рабочего бэкапа, зато с чистой историей находок find.
Планировщик — системный /etc/cron.d/ai-stack-backup, а не пользовательский crontab -e: у файлов в cron.d обязательна колонка с именем пользователя, и если вставить туда строку из обычного crontab, cron откажется её выполнять.
0 3 * * * root /opt/backups/ai-stack-backup.sh >> /var/log/ai-stack-backup.log 2>&1
Перенаправление в лог не для галочки: у cron минимальное окружение и никакого интерактивного вывода, ошибка молча растворится, если не писать её в файл явно. Проверяйте результат самого свежего запуска:
tail -20 /var/log/ai-stack-backup.log
ls -lh /opt/backups | tail -5
Если в стеке уже стоит Uptime Kuma из того же каталога приложений, добавьте в конец скрипта одну строку с push-мониторингом — он не проверяет содержимое бэкапа, зато честно сообщит, если скрипт вообще не отработал:
curl -fsS "https://kuma.example.com/api/push/xxxxxxxx?status=up" >/dev/null || true
Восстановление на новом сервере: пошагово
Бэкап без проверенного восстановления — это архив, о котором вы верите, а не знаете. Разложим процесс на чистом сервере.
Если заказывали приложение Ollama из каталога MAATRIX, сервис и контейнер уже подняты и связаны между собой — переходите сразу к возврату данных. Если ставили руками, сначала повторите установку Ubuntu 24.04 тем же путём и только потом восстанавливайтесь.
Модели Ollama. Убедитесь, что сервис запущен, и прогоните сохранённый список через pull.
sudo systemctl status ollama --no-pager
while read -r model; do ollama pull "$model"; done < ollama-models-2026-08-20.txt
Если вместо списка вы держали полный архив manifests и blobs — оправдано для приватных моделей или дорогого трафика, — верните его до старта сервиса и поправьте владельца файлов, иначе вернётесь к проблеме «ollama list пустой, хотя файлы на месте»:
sudo systemctl stop ollama
sudo rsync -a /backup/ollama-models/ /usr/share/ollama/.ollama/models/
sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models
sudo systemctl start ollama
ollama list
Кастомные модели поднимите из сохранённых Modelfile:
ollama create мойассистент -f мойассистент.Modelfile
Данные Open WebUI. Создайте том и наполните его архивом до первого старта контейнера — иначе Compose создаст пустой том, и данные придётся заливать поверх уже работающего процесса.
docker volume create open-webui_open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar xzf /backup/openwebui-2026-08-20.tar.gz -C /data
cd /opt/open-webui && docker compose up -d
На новом хосте адрес шлюза docker0 из старого compose.yaml может не совпасть — Docker выдаёт его динамически, и 172.17.0.1 не гарантирован, если на сервере уже есть другие сети:
ip -4 addr show docker0
Поправьте OLLAMA_BASE_URL=http://<адрес>:11434 под фактический адрес и перезапустите docker compose up -d. Про WEBUI_SECRET_KEY можно не переживать: если он не совпал со старым, пользователи один раз перелогинятся — данные это не затронет.
Проверка на этом не заканчивается: docker compose logs -f open-webui должен показать чистый старт без трейсбеков, а после входа сверьте, что модели и история чатов совпадают с тем, что было до аварии.
Нюансы, о которых часто забывают
Версия образа на момент бэкапа. Тег :main у ghcr.io/open-webui/open-webui — плавающая ветка, и к моменту восстановления реестр может уйти на версию вперёд. Обычно это безобидно — образ сам прогонит миграции схемы при первом старте, — но при аварии спокойнее поднять именно ту версию, что работала раньше. Зафиксируйте её заранее:
docker inspect --format='{{.Image}}' open-webui
Бэкап без остановки контейнера. Секундная пауза от docker compose stop не подходит, если в интерфейсе постоянно сидят люди. SQLite отдаёт согласованный снимок через собственный Backup API, и до него легко достать из Python внутри контейнера — интерпретатор там точно есть, это среда исполнения самого Open WebUI:
docker compose exec -T open-webui python3 -c \
  "import sqlite3; s=sqlite3.connect('/app/backend/data/webui.db'); d=sqlite3.connect('/tmp/webui.bak'); s.backup(d); d.close(); s.close()"
docker cp open-webui:/tmp/webui.bak /opt/backups/webui-$(date +%F).db
docker compose exec -T open-webui rm -f /tmp/webui.bak
Так копия базы снимается без простоя; каталог uploads можно архивировать так же, без остановки — это обычные дописанные файлы, а не меняющаяся на лету структура вроде базы.
В бэкапе лежат чужие секреты. Ключи OpenAI, Anthropic и других провайдеров, подключённые через настройки Open WebUI, попадают прямиком в webui.db. Архив с базой не менее чувствителен, чем .env: права 600, отдельный пользователь для бэкапов и шифрование архива перед тем, как он уедет с сервера — подробности в статье про бэкап с шифрованием.
Если в стеке есть LiteLLM. У него своя пара критичных значений — LITELLM_MASTER_KEY и LITELLM_SALT_KEY. Бэкап его базы без salt-ключа бесполезен: без него ключи провайдеров в базе не расшифровать, и это отдельная больная тема.
Копия должна жить не на том же диске. Правило «3-2-1» никто не отменял: рабочая копия, локальный бэкап и хотя бы одна копия за пределами сервера. Раз в месяц реально поднимайте архив на тестовой машине — только так вы узнаете о проблеме заранее, а не когда она уже стала проблемой с данными.
Какой сервер и локацию брать под ИИ-стек с бэкапами
Требования к вычислениям задаёт не бэкап, а сама модель — расчёт по памяти для конкретных весов разобран в статье о том, сколько RAM нужно для Ollama. Здесь — только то, что добавляет к этим цифрам тема сегодняшней статьи.
Честный минимум — 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Это нижняя граница, на которой каталожное приложение Ollama + Open WebUI на тарифе Heka ощущается комфортно: модель 7B в Q4 занимает около 4,5 ГБ весов, и на многое сверх контейнера и системы память уже не остаётся. Бэкапам здесь тесно по диску: если храните ещё и полный архив весов кастомной модели, закладывайте под /opt/backups отдельный раздел — иначе pull новой модели и ночной cron рано или поздно поборются за гигабайты.
Комфортный вариант — 8 vCPU, 16 ГБ RAM, 120–150 ГБ NVMe. Разница не в скорости бэкапа — он и на минимуме весит немного, — а в свободе: несколько моделей одновременно, RAG-документы без взгляда на df -h и запас на тридцать ежедневных копий вместо семи. На такой конфигурации удобно держать и тестовое восстановление — рядом, не трогая рабочий стек.
Локация — Лондон (UK). В повседневной работе это доступ к ghcr.io, Docker Hub и Hugging Face без блокировок, низкий пинг до Европы и соседство с GDPR. Для темы бэкапов важнее другое: при аварии веса моделей вы не восстанавливаете из архива, а качаете заново из реестра, и тут пропускная способность решает, займёт это пять минут или полтора часа простоя. Именно этот сценарий у российской площадки страдает первым.
В каталоге Ollama и Open WebUI разворачиваются одной кнопкой при заказе сервера — доступы появятся в личном кабинете, но бэкап каталог за вас не настроит, это по-прежнему ваш cron. Конфигурация покрупнее — выбрать здесь. Под вынесенную копию бэкапов хватит младшего тарифа в другой локации, скажем в России или США, с диском под архивы и SSH для rsync. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть Ollama
}' > "$DIR/ollama-models-$DATE.txt"

cd /opt/open-webui
docker compose stop open-webui
docker run --rm -v open-webui_open-webui:/data -v "$DIR":/backup alpine \
  tar czf /backup/openwebui-$DATE.tar.gz -C /data .
docker compose start open-webui

gzip -t "$DIR/openwebui-$DATE.tar.gz"
[ -s "$DIR/ollama-models-$DATE.txt" ]

find "$DIR" -name 'openwebui-*.tar.gz' -mtime +14 -delete
find "$DIR" -name 'ollama-models-*.txt' -mtime +14 -delete

set -euo pipefail в начале — не формальность: без него скрипт продолжит работу и сотрёт старые копии, даже если docker run выше упал с ошибкой, — и вы останетесь без единого рабочего бэкапа, зато с чистой историей находок find.

Планировщик — системный /etc/cron.d/ai-stack-backup, а не пользовательский crontab -e: у файлов в cron.d обязательна колонка с именем пользователя, и если вставить туда строку из обычного crontab, cron откажется её выполнять.

0 3 * * * root /opt/backups/ai-stack-backup.sh >> /var/log/ai-stack-backup.log 2>&1

Перенаправление в лог не для галочки: у cron минимальное окружение и никакого интерактивного вывода, ошибка молча растворится, если не писать её в файл явно. Проверяйте результат самого свежего запуска:

tail -20 /var/log/ai-stack-backup.log
ls -lh /opt/backups | tail -5

Если в стеке уже стоит Uptime Kuma из того же каталога приложений, добавьте в конец скрипта одну строку с push-мониторингом — он не проверяет содержимое бэкапа, зато честно сообщит, если скрипт вообще не отработал:

curl -fsS "https://kuma.example.com/api/push/xxxxxxxx?status=up" >/dev/null || true

Восстановление на новом сервере: пошагово

Бэкап без проверенного восстановления — это архив, о котором вы верите, а не знаете. Разложим процесс на чистом сервере.

Если заказывали приложение Ollama из каталога MAATRIX, сервис и контейнер уже подняты и связаны между собой — переходите сразу к возврату данных. Если ставили руками, сначала повторите установку Ubuntu 24.04 тем же путём и только потом восстанавливайтесь.

Модели Ollama. Убедитесь, что сервис запущен, и прогоните сохранённый список через pull.

sudo systemctl status ollama --no-pager
while read -r model; do ollama pull "$model"; done < ollama-models-2026-08-20.txt

Если вместо списка вы держали полный архив manifests и blobs — оправдано для приватных моделей или дорогого трафика, — верните его до старта сервиса и поправьте владельца файлов, иначе вернётесь к проблеме «ollama list пустой, хотя файлы на месте»:

sudo systemctl stop ollama
sudo rsync -a /backup/ollama-models/ /usr/share/ollama/.ollama/models/
sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models
sudo systemctl start ollama
ollama list

Кастомные модели поднимите из сохранённых Modelfile:

ollama create мойассистент -f мойассистент.Modelfile

Данные Open WebUI. Создайте том и наполните его архивом до первого старта контейнера — иначе Compose создаст пустой том, и данные придётся заливать поверх уже работающего процесса.

docker volume create open-webui_open-webui
docker run --rm -v open-webui_open-webui:/data -v /opt/backups:/backup alpine \
  tar xzf /backup/openwebui-2026-08-20.tar.gz -C /data
cd /opt/open-webui && docker compose up -d

На новом хосте адрес шлюза docker0 из старого compose.yaml может не совпасть — Docker выдаёт его динамически, и 172.17.0.1 не гарантирован, если на сервере уже есть другие сети:

ip -4 addr show docker0

Поправьте OLLAMA_BASE_URL=http://<адрес>:11434 под фактический адрес и перезапустите docker compose up -d. Про WEBUI_SECRET_KEY можно не переживать: если он не совпал со старым, пользователи один раз перелогинятся — данные это не затронет.

Проверка на этом не заканчивается: docker compose logs -f open-webui должен показать чистый старт без трейсбеков, а после входа сверьте, что модели и история чатов совпадают с тем, что было до аварии.

Нюансы, о которых часто забывают

Версия образа на момент бэкапа. Тег :main у ghcr.io/open-webui/open-webui — плавающая ветка, и к моменту восстановления реестр может уйти на версию вперёд. Обычно это безобидно — образ сам прогонит миграции схемы при первом старте, — но при аварии спокойнее поднять именно ту версию, что работала раньше. Зафиксируйте её заранее:

docker inspect --format='{{.Image}}' open-webui

Бэкап без остановки контейнера. Секундная пауза от docker compose stop не подходит, если в интерфейсе постоянно сидят люди. SQLite отдаёт согласованный снимок через собственный Backup API, и до него легко достать из Python внутри контейнера — интерпретатор там точно есть, это среда исполнения самого Open WebUI:

docker compose exec -T open-webui python3 -c \
  "import sqlite3; s=sqlite3.connect('/app/backend/data/webui.db'); d=sqlite3.connect('/tmp/webui.bak'); s.backup(d); d.close(); s.close()"
docker cp open-webui:/tmp/webui.bak /opt/backups/webui-$(date +%F).db
docker compose exec -T open-webui rm -f /tmp/webui.bak

Так копия базы снимается без простоя; каталог uploads можно архивировать так же, без остановки — это обычные дописанные файлы, а не меняющаяся на лету структура вроде базы.

В бэкапе лежат чужие секреты. Ключи OpenAI, Anthropic и других провайдеров, подключённые через настройки Open WebUI, попадают прямиком в webui.db. Архив с базой не менее чувствителен, чем .env: права 600, отдельный пользователь для бэкапов и шифрование архива перед тем, как он уедет с сервера — подробности в статье про бэкап с шифрованием.

Если в стеке есть LiteLLM. У него своя пара критичных значений — LITELLM_MASTER_KEY и LITELLM_SALT_KEY. Бэкап его базы без salt-ключа бесполезен: без него ключи провайдеров в базе не расшифровать, и это отдельная больная тема.

Копия должна жить не на том же диске. Правило «3-2-1» никто не отменял: рабочая копия, локальный бэкап и хотя бы одна копия за пределами сервера. Раз в месяц реально поднимайте архив на тестовой машине — только так вы узнаете о проблеме заранее, а не когда она уже стала проблемой с данными.

Какой сервер и локацию брать под ИИ-стек с бэкапами

Требования к вычислениям задаёт не бэкап, а сама модель — расчёт по памяти для конкретных весов разобран в статье о том, сколько RAM нужно для Ollama. Здесь — только то, что добавляет к этим цифрам тема сегодняшней статьи.

Честный минимум — 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Это нижняя граница, на которой каталожное приложение Ollama + Open WebUI на тарифе Heka ощущается комфортно: модель 7B в Q4 занимает около 4,5 ГБ весов, и на многое сверх контейнера и системы память уже не остаётся. Бэкапам здесь тесно по диску: если храните ещё и полный архив весов кастомной модели, закладывайте под /opt/backups отдельный раздел — иначе pull новой модели и ночной cron рано или поздно поборются за гигабайты.

Комфортный вариант — 8 vCPU, 16 ГБ RAM, 120–150 ГБ NVMe. Разница не в скорости бэкапа — он и на минимуме весит немного, — а в свободе: несколько моделей одновременно, RAG-документы без взгляда на df -h и запас на тридцать ежедневных копий вместо семи. На такой конфигурации удобно держать и тестовое восстановление — рядом, не трогая рабочий стек.

Локация — Лондон (UK). В повседневной работе это доступ к ghcr.io, Docker Hub и Hugging Face без блокировок, низкий пинг до Европы и соседство с GDPR. Для темы бэкапов важнее другое: при аварии веса моделей вы не восстанавливаете из архива, а качаете заново из реестра, и тут пропускная способность решает, займёт это пять минут или полтора часа простоя. Именно этот сценарий у российской площадки страдает первым.

В каталоге Ollama и Open WebUI разворачиваются одной кнопкой при заказе сервера — доступы появятся в личном кабинете, но бэкап каталог за вас не настроит, это по-прежнему ваш cron. Конфигурация покрупнее — выбрать здесь. Под вынесенную копию бэкапов хватит младшего тарифа в другой локации, скажем в России или США, с диском под архивы и SSH для rsync. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не нужна даже для лондонской площадки.

Частые вопросы