:::предупреждение Этот учебный материал является вкладом сообщества и не поддерживается командой Open WebUI. Он служит только демонстрацией того, как настроить Open WebUI для ваших конкретных нужд. Хотите внести вклад? Ознакомьтесь с учебным материалом по внесению вклада. :::

Резервное копирование вашей установки

Никто не любит терять данные!

Если вы размещаете Open WebUI самостоятельно, возможно, вам захочется внедрить какой-либо официальный план резервного копирования, чтобы гарантировать сохранение второй и третьей копии частей вашей конфигурации.

Данное руководство предназначено для того, чтобы предложить некоторые базовые рекомендации по выполнению этой задачи.

Руководство предполагает, что пользователь установил Open WebUI через Docker (или планирует это сделать).

Обеспечение устойчивости данных

Во-первых, перед развертыванием вашего стека с помощью Docker убедитесь, что ваш Docker Compose использует постоянное хранилище данных. Если вы используете Docker Compose из репозитория на Github, это уже учтено. Однако легко создать свою вариацию и забыть проверить это.

Контейнеры Docker эфемерны, и данные должны сохраняться, чтобы обеспечить их сохранность в файловой системе хоста.

Использование Docker volumes

Если вы используете Docker Compose из репозитория проекта, вы будете развертывать Open Web UI с использованием Docker volumes.

Для Ollama и Open WebUI монтирования выглядят следующим образом:

ollama:
  volumes:
    - ollama:/root/.ollama

open-webui:
  volumes:
    - open-webui:/app/backend/data

Чтобы найти путь привязки на хосте, выполните:

docker volume inspect ollama

docker volume inspect open-webui

Использование прямых привязок хоста

Некоторые пользователи развертывают Open Web UI с прямыми (фиксированными) привязками к файловой системе хоста, например:

services:
  ollama:
    container_name: ollama
    image: ollama/ollama:${OLLAMA_DOCKER_TAG-latest}
    volumes:
      - /opt/ollama:/root/.ollama
  open-webui:
    container_name: open-webui
    image: ghcr.io/open-webui/open-webui:${WEBUI_DOCKER_TAG-main}
    volumes:
      - /opt/open-webui:/app/backend/data

Если вы развернули вашу установку таким образом, вам нужно будет отметить пути на корневом уровне.

Скрипт для задания резервного копирования

Как бы ни была настроена ваша установка, стоит проверить хранилище данных приложения на вашем сервере, чтобы понять, какие данные вы будете резервировать. Вы должны увидеть что-то такое:

├── audit.log
├── cache/
├── uploads/
├── vector_db/
└── webui.db

Файлы в постоянном хранилище данных

Файл/Директория	Описание
`audit.log`	Файл журнала для аудита событий.
`cache/`	Директория для хранения кэшированных данных.
`uploads/`	Директория для хранения файлов, загруженных пользователем.
`vector_db/`	Директория, содержащая базу данных ChromaDB.
`webui.db`	SQLite база данных для хранения других постоянных данных установки.

Подходы к резервному копированию на уровне файлов

Первый способ резервного копирования данных приложения — это подход к копированию на уровне файлов, обеспечивающий, чтобы постоянные данные Open Web UI были правильно сохранены.

Существует практически бесконечное количество способов резервного копирования технических служб, но rsync остаётся популярным выбором для задач с дополнительным копированием и будет использован в качестве демонстрации.

Пользователи могут нацелиться на всю директорию data, чтобы скопировать все данные установки разом, или создать более выборочные задания резервного копирования, нацеленные на отдельные компоненты. Вы также можете добавить более описательные названия для целевых объектов.

Пример задания rsync может выглядеть так:

#!/bin/bash

# Конфигурация
SOURCE_DIR="."  # Текущая директория (где находится файловая структура)
B2_BUCKET="b2://OpenWebUI-backups" # Ваш Backblaze B2 бакет
B2_PROFILE="your_rclone_profile" # Имя вашего профиля rclone
# Убедитесь, что rclone настроен с вашими учетными данными B2

# Определите исходные и целевые директории
SOURCE_UPLOADS="$SOURCE_DIR/uploads"
SOURCE_VECTORDB="$SOURCE_DIR/vector_db"
SOURCE_WEBUI_DB="$SOURCE_DIR/webui.db"

DEST_UPLOADS="$B2_BUCKET/user_uploads"
DEST_CHROMADB="$B2_BUCKET/ChromaDB"
DEST_MAIN_DB="$B2_BUCKET/main_database"

# Исключить cache и audit.log
EXCLUDE_LIST=(
    "cache/"
    "audit.log"
)

# Создание аргументов исключения для rclone
EXCLUDE_ARGS=""
for EXCLUDE in "${EXCLUDE_LIST[@]}"; do
    EXCLUDE_ARGS="$EXCLUDE_ARGS --exclude $EXCLUDE"
done

# Функция для выполнения синхронизации rclone с проверкой ошибок
rclone_sync() {
    SOURCE="$1"
    DEST="$2"
    echo "Синхронизация $SOURCE с $DEST..."
    rclone sync "$SOURCE" "$DEST" $EXCLUDE_ARGS --progress --transfers=32 --checkers=16 --profile "$B2_PROFILE"
    if [ $? -ne 0 ]; then
        echo "Ошибка: синхронизация rclone не удалась для $SOURCE к $DEST"
        exit 1
    fi
}

# Выполнение синхронизации rclone для каждой директории/файла
rclone_sync "$SOURCE_UPLOADS" "$DEST_UPLOADS"
rclone_sync "$SOURCE_VECTORDB" "$DEST_CHROMADB"
rclone_sync "$SOURCE_WEBUI_DB" "$DEST_MAIN_DB"

echo "Резервное копирование успешно выполнено."
exit 0

Задача Rsync с прерыванием контейнера

Для сохранения целостности данных обычно рекомендуется выполнять резервное копирование баз данных на "холодных" файловых системах. Наша стандартная задача резервного копирования моделей может быть немного изменена, чтобы остановить стек перед выполнением скрипта резервного копирования и запустить его обратно после этого.

Недостатком этого подхода, конечно же, является то, что это приведет к временному простоя сервиса. Рассмотрите возможность выполнения задачи в то время, когда вы не будете использовать инстанс, или проводить "ежедневные" резервные копии (на действующих данных) и более надежные еженедельные (на холодных данных).

#!/bin/bash

# Конфигурация
COMPOSE_FILE="docker-compose.yml" # Путь к вашему файлу docker-compose.yml
B2_BUCKET="b2://OpenWebUI-backups" # Ваш Backblaze B2 bucket
B2_PROFILE="your_rclone_profile" # Имя профиля rclone
SOURCE_DIR="."  # Текущий каталог (где находится файловая структура)

# Определите исходные и целевые каталоги
SOURCE_UPLOADS="$SOURCE_DIR/uploads"
SOURCE_VECTORDB="$SOURCE_DIR/vector_db"
SOURCE_WEBUI_DB="$SOURCE_DIR/webui.db"

DEST_UPLOADS="$B2_BUCKET/user_uploads"
DEST_CHROMADB="$B2_BUCKET/ChromaDB"
DEST_MAIN_DB="$B2_BUCKET/main_database"

# Исключите cache и audit.log
EXCLUDE_LIST=(
    "cache/"
    "audit.log"
)

# Создайте аргументы исключения для rclone
EXCLUDE_ARGS=""
for EXCLUDE in "${EXCLUDE_LIST[@]}"; do
    EXCLUDE_ARGS="$EXCLUDE_ARGS --exclude '$EXCLUDE'"
done

# Функция для синхронизации rclone с проверкой ошибок
rclone_sync() {
    SOURCE="$1"
    DEST="$2"
    echo "Синхронизация '$SOURCE' с '$DEST'..."
    rclone sync "$SOURCE" "$DEST" $EXCLUDE_ARGS --progress --transfers=32 --checkers=16 --profile "$B2_PROFILE"
    if [ $? -ne 0 ]; then
        echo "Ошибка: синхронизация rclone не удалась для '$SOURCE' с '$DEST'"
        exit 1
    fi
}

# 1. Остановите среду Docker Compose
echo "Остановка среды Docker Compose..."
docker-compose -f "$COMPOSE_FILE" down

# 2. Выполните резервное копирование
echo "Начало резервного копирования..."
rclone_sync "$SOURCE_UPLOADS" "$DEST_UPLOADS"
rclone_sync "$SOURCE_VECTORDB" "$DEST_CHROMADB"
rclone_sync "$SOURCE_WEBUI_DB" "$DEST_MAIN_DB"

# 3. Запустите среду Docker Compose
echo "Запуск среды Docker Compose..."
docker-compose -f "$COMPOSE_FILE" up -d

echo "Резервное копирование успешно завершено."
exit 0

Скрипт резервного копирования модели с использованием функций резервного копирования SQLite и ChromaDB для удаленной B2

#!/bin/bash
#
# Скрипт резервного копирования для создания резервных копий ChromaDB и SQLite в Backblaze B2 bucket
# openwebuiweeklies, с сохранением 3 еженедельных снимков.
# Снимки независимы и полностью восстанавливаемы.
# Использует механизмы резервного копирования ChromaDB и SQLite.
# Исключает audit.log, cache и каталоги uploads.
#
# Убедитесь, что rclone установлен и правильно настроен.
# Установите rclone: https://rclone.org/install/
# Настройте rclone: https://rclone.org/b2/

# Исходный каталог (содержащий данные ChromaDB и SQLite)
SOURCE="/var/lib/open-webui/data"

# Имя удаленной B2 bucket и имя удаленного ресурса
B2_REMOTE="openwebuiweeklies"
B2_BUCKET="b2:$B2_REMOTE"

# Метка времени для каталога резервного копирования
TIMESTAMP=$(date +%Y-%m-%d)

# Имя каталога резервного копирования
BACKUP_DIR="open-webui-backup-$TIMESTAMP"

# Полный путь к каталогу резервного копирования в bucket B2
DESTINATION="$B2_BUCKET/$BACKUP_DIR"

# Количество еженедельных снимков для сохранения
NUM_SNAPSHOTS=3

# Фильтры исключений (применяются *после* резервного копирования базы данных)
EXCLUDE_FILTERS="--exclude audit.log --exclude cache/** --exclude uploads/** --exclude vector_db"

# Настройки резервного копирования ChromaDB (настройте при необходимости)
CHROMADB_DATA_DIR="$SOURCE/vector_db"  # Путь к каталогу данных ChromaDB
CHROMADB_BACKUP_FILE="$SOURCE/chromadb_backup.tar.gz" # Архивный файл для резервного копирования ChromaDB

# Настройки резервного копирования SQLite (настройте при необходимости)
SQLITE_DB_FILE="$SOURCE/webui.db" # Путь к файлу базы данных SQLite
SQLITE_BACKUP_FILE="$SOURCE/webui.db.backup" # Временный файл для резервного копирования SQLite

# Функция для создания резервной копии ChromaDB
backup_chromadb() {
  echo "Резервное копирование ChromaDB..."

  # Создайте архивный файл каталога vector_db
  tar -czvf "$CHROMADB_BACKUP_FILE" -C "$SOURCE" vector_db

  echo "Резервное копирование ChromaDB завершено."
}

# Функция для создания резервной копии SQLite
backup_sqlite() {
  echo "Резервное копирование базы данных SQLite..."
  # Создайте резервную копию базы данных SQLite с использованием команды .backup
  sqlite3 "$SQLITE_DB_FILE" ".backup '$SQLITE_BACKUP_FILE'"

  # Переместите файл резервной копии в исходный каталог
  mv "$SQLITE_BACKUP_FILE" "$SOURCE/"

  echo "Резервное копирование SQLite завершено."
}

# Выполните резервное копирование баз данных
backup_chromadb
backup_sqlite

# Выполните резервное копирование с исключениями
rclone copy "$SOURCE" "$DESTINATION" $EXCLUDE_FILTERS --progress

# Удалите старые резервные копии, сохраняя последние NUM_SNAPSHOTS
find "$B2_BUCKET" -type d -name "open-webui-backup-*" | sort -r | tail -n +$((NUM_SNAPSHOTS + 1)) | while read dir; do
  rclone purge "$dir"
done

echo "Резервное копирование выполнено в $DESTINATION"

Снимки точек во времени

В дополнение к резервному копированию, пользователи также могут создавать снимки точек во времени, которые могут храниться локально (на сервере), удаленно или же одновременно в обоих местах.

#!/bin/bash

# Конфигурация
SOURCE_DIR="."  # Каталог для создания снимка (текущий каталог)
SNAPSHOT_DIR="/snapshots" # Каталог для хранения снимков
TIMESTAMP=$(date +%Y%m%d%H%M%S) # Генерация временной метки

# Создать каталог для снимков, если он не существует
mkdir -p "$SNAPSHOT_DIR"

# Создать имя для снимка
SNAPSHOT_NAME="snapshot_$TIMESTAMP"
SNAPSHOT_PATH="$SNAPSHOT_DIR/$SNAPSHOT_NAME"

# Выполнить снятие снимка с помощью rsync
echo "Создание снимка: $SNAPSHOT_PATH"
rsync -av --delete --link-dest="$SNAPSHOT_DIR/$(ls -t "$SNAPSHOT_DIR" | head -n 1)" "$SOURCE_DIR/" "$SNAPSHOT_PATH"

# Проверить успешность выполнения rsync
if [ $? -eq 0 ]; then
  echo "Снимок успешно создан."
else
  echo "Ошибка: создание снимка не удалось."
  exit 1
fi

exit 0

Планирование задач с помощью Crontab

После добавления вашего скрипта резервного копирования и подготовки хранилища данных, проверьте работу скриптов, чтобы убедиться, что они выполняются должным образом. Ведение логов настоятельно рекомендуется.

Настройте новые скрипты для выполнения с помощью crontab в соответствии с желаемой частотой выполнения.

Коммерческие утилиты

Помимо написания собственных скриптов резервного копирования, вы можете использовать коммерческие решения, которые обычно работают через установку агентов на сервер, упрощающих выполнение резервных копий. Это выходит за рамки данного руководства, но предлагает удобные решения.

Резервное копирование на уровне хоста

Ваш экземпляр Open WebUI может быть размещен на хосте (физическом или виртуализированном), который вы контролируете.

Резервное копирование на уровне хоста включает создание снимков или резервных копий всей виртуальной машины, а не работающих приложений.

Некоторые предпочитают использовать их в качестве основной или единственной защиты, а другие могут добавлять их как дополнительную защиту данных.

Сколько резервных копий мне нужно?

Количество резервных копий зависит от вашей личной терпимости к риску. Тем не менее, помните, что считается хорошей практикой не рассматривать само приложение как резервную копию (даже если оно находится в облаке!). Это значит, что если вы разместили свой экземпляр на VPS, всё же рекомендуется иметь две (независимые) копии резервных данных.

Пример плана резервного копирования, который может подойти для большинства домашних пользователей:

Модель плана резервного копирования 1 (основной + 2 копии)

Частота	Цель	Технология	Описание
Ежедневное инкрементальное	Облачное хранилище (S3/B2)	rsync	Ежедневная инкрементальная резервная копия, отправляемая в облачное хранилище (S3 или B2).
Еженедельное инкрементальное	Локальное хранилище (домашний NAS)	rsync	Еженедельная инкрементальная резервная копия, получаемая сервером для локального хранилища (например, домашний NAS).

Модель плана резервного копирования 2 (основной + 3 копии)

Этот план немного сложнее, но также более полный: он включает ежедневное отправление данных двум облачным поставщикам для дополнительной надёжности.

Частота	Цель	Технология	Описание
Ежедневное инкрементальное	Облачное хранилище (S3)	rsync	Ежедневная инкрементальная резервная копия, отправляемая в облачное хранилище S3.
Ежедневное инкрементальное	Облачное хранилище (B2)	rsync	Ежедневная инкрементальная резервная копия, отправляемая в облачное хранилище Backblaze B2.
Еженедельное инкрементальное	Локальное хранилище (домашний NAS)	rsync	Еженедельная инкрементальная резервная копия, получаемая сервером для локального хранилища (например, домашний NAS).

Дополнительные темы

Чтобы сделать это руководство достаточно полным, эти дополнительные темы были опущены, но могут быть полезны в зависимости от того, сколько времени вы готовы выделить для настройки и поддержания плана защиты данных для вашего экземпляра:

Тема	Описание
Встроенный резервный механизм SQLite	Рассмотрите использование команды `.backup` SQLite для обеспечения постоянного решения для резервного копирования базы данных.
Шифрование	Измените скрипты резервного копирования, чтобы включить шифрование данных для повышения безопасности.
Αναстановление при катастрофах и тестирование	Разработайте план восстановления после катастрофы и регулярно тестируйте процесс резервного копирования и восстановления.
Альтернативные инструменты резервного копирования	Изучите другие инструменты командной строки, такие как `borgbackup` или `restic`, для использования более продвинутых функций.
Email-уведомления и вебхуки	Реализуйте email-уведомления или вебхуки для контроля успешности или неудачи резервного копирования.

Обеспечение устойчивости данных​

Использование Docker volumes​

Использование прямых привязок хоста​

Скрипт для задания резервного копирования​

Файлы в постоянном хранилище данных​