Бэкап и восстановление Owncast

MAATRIX

Собственный стриминговый сервер снимает зависимость от Twitch и YouTube, но добавляет ответственность: если диск с Owncast умрёт, вы теряете не только конфиг, а весь архив трансляций и историю канала — и никакая техподдержка площадки это не восстановит, потому что площадки больше нет, есть только ваш VPS. Разберём, что конкретно нужно бэкапить в Owncast, как это автоматизировать и как поднять сервер заново на чистой машине после аварии.

Что нужно бэкапить в Owncast и почему это не «просто скопировать data»

Owncast хранит почти всё состояние в одной директории данных — в docker-инсталляции это том, примонтированный на /app/data внутри контейнера (/opt/owncast/data на хосте, если ставили сервер по стандартной схеме из статьи про установку Owncast на VPS). Но «одна папка» не значит «один тип данных» — внутри лежат вещи с разной ценностью и частотой изменения:

• owncast.db — SQLite-база: настройки сервера, стрим-ключ, история трансляций, чат-сообщения, список модераторов, вебхуки, токены доступа. Это самое критичное — без неё сервер после переустановки будет выглядеть как только что развёрнутый, со случайным новым ключом.
• Записи трансляций (VOD), если в админке включено сохранение прошлых стримов — самые тяжёлые файлы в директории данных, растут с каждым часом эфира.
• Медиатека и кастомизация — логотип, обложки, кастомные страницы (о канале, теги), загруженные эмодзи для чата, если вы их настраивали.
• Сама конфигурация docker-compose — docker-compose.yml и, если используете, .env с переменными — без них проброс портов и сетевые настройки придётся собирать заново руками.

Точный список файлов может отличаться от версии к версии — Owncast активно развивается, и структура директории данных не зафиксирована как публичный контракт. Прежде чем писать скрипт бэкапа, посмотрите, что реально лежит на вашем сервере:

docker compose exec owncast ls -la /app/data

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

Бэкап базы данных owncast.db

База — SQLite-файл, и с ним нельзя работать как с обычным файлом на живом сервере: если скопировать его во время активной записи (идёт стрим, пишутся чат-сообщения), можно получить файл в промежуточном состоянии. Правильный способ — снять снапшот через встроенный механизм SQLite, а не голый cp.

Самый надёжный вариант — команда .backup через sqlite3, которая безопасна даже при параллельной записи в базу:

docker compose exec -T owncast sh -c \
  "sqlite3 /app/data/owncast.db '.backup /app/data/owncast_backup.db'"

docker compose cp owncast:/app/data/owncast_backup.db \
  /var/backups/owncast/db_$(date +%F_%H%M).db

docker compose exec owncast rm /app/data/owncast_backup.db

Если в образе Owncast нет утилиты sqlite3 (в официальном образе owncast/owncast она может отсутствовать — образ минималистичный), проще остановить контейнер на секунду и скопировать файл напрямую с хоста, раз запись гарантированно не идёт:

docker compose stop owncast
cp /opt/owncast/data/owncast.db /var/backups/owncast/db_$(date +%F_%H%M).db
docker compose start owncast

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

Проверить целостность снятого дампа можно сразу же, не разворачивая полноценное восстановление:

sqlite3 /var/backups/owncast/db_2026-08-30_0300.db "PRAGMA integrity_check;"

Ответ ok значит, что файл не повреждён и пригоден для восстановления.

Бэкап видеозаписей и медиатеки

Если в Owncast (Config → General → Video Storage / Recording) включено сохранение прошлых трансляций, записи копятся в директории данных и быстро становятся самой тяжёлой частью бэкапа — час стрима в 1080p легко занимает несколько гигабайт. Логика бэкапа здесь отличается от базы: файлы неизменяемые после записи, поэтому подходит инкрементальная синхронизация без риска зацепить файл на середине записи.

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

restic -r s3:https://s3.example.com/owncast-backup init
restic -r s3:https://s3.example.com/owncast-backup backup \
  /opt/owncast/data \
  --exclude "*.tmp" \
  --exclude "hls/*"

Каталог hls (или аналогичный временный каталог с сегментами активного эфира — название может отличаться по версии) исключайте из бэкапа осознанно: это транзитные фрагменты текущего вещания, которые не имеют смысла вне живого стрима и пересоздаются заново при каждом новом эфире. Бэкапить нужно готовые сохранённые записи, а не сырые HLS-сегменты в процессе.

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

Для небольших архивов (до нескольких десятков гигабайт) хватит и простого rsync на удалённый сервер без промежуточного S3:

rsync -avz --exclude 'hls/' \
  /opt/owncast/data/ backup-user@backup-server:/backups/owncast/data/

Скрипт автоматизации и cron

Собираем базу, конфиг и медиатеку в один скрипт с ротацией старых копий:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/var/backups/owncast"
DATE=$(date +%F_%H%M)
KEEP_DAYS=14

mkdir -p "$BACKUP_DIR"

# 1. База данных — безопасный снапшот через sqlite3 .backup
docker compose -f /opt/owncast/docker-compose.yml exec -T owncast sh -c \
  "sqlite3 /app/data/owncast.db '.backup /app/data/owncast_backup.db'"
docker compose -f /opt/owncast/docker-compose.yml cp \
  owncast:/app/data/owncast_backup.db "$BACKUP_DIR/db_$DATE.db"
docker compose -f /opt/owncast/docker-compose.yml exec owncast \
  rm /app/data/owncast_backup.db

# 2. Конфиг docker-compose
tar czf "$BACKUP_DIR/config_$DATE.tar.gz" -C /opt/owncast docker-compose.yml

# 3. Медиатека и VOD — инкрементально через restic
restic -r s3:https://s3.example.com/owncast-backup backup \
  /opt/owncast/data \
  --exclude "*.tmp" \
  --exclude "hls/*" \
  --tag "$DATE"

# 4. Ротация локальных копий базы и конфига
find "$BACKUP_DIR" -name "db_*.db" -mtime +"$KEEP_DAYS" -delete
find "$BACKUP_DIR" -name "config_*.tar.gz" -mtime +"$KEEP_DAYS" -delete

# 5. Ротация снапшотов restic
restic -r s3:https://s3.example.com/owncast-backup forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Ставим в cron на ночное время, желательно вне часов регулярных эфиров — снапшот базы через sqlite3 .backup безопасен и во время трансляции, но синхронизация тяжёлого архива видео лучше не конкурирует за канал с активным вещанием:

crontab -e
# 0 4 * * * /usr/local/bin/owncast-backup.sh >> /var/log/owncast-backup.log 2>&1

Если предпочитаете готовое решение вместо самописного скрипта поверх restic, посмотрите на BorgBackup — там из коробки есть дедупликация, сжатие и удобное управление ретеншеном; установка на Ubuntu разобрана в статье про BorgBackup.

Восстановление Owncast на новом сервере

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

1. Установите Docker и подготовьте директорию на новом сервере так же, как при первичной установке — структура каталогов должна совпадать с тем, что было на старом сервере (/opt/owncast/data).
2. Разверните docker-compose.yml из бэкапа конфига или создайте заново — файл небольшой, ошибиться сложно, но проще восстановить из архива, если он есть.
3. Восстановите архив данных (записи, медиатеку) до первого запуска контейнера:

   mkdir -p /opt/owncast/data
   restic -r s3:https://s3.example.com/owncast-backup restore latest \
     --target /opt/owncast/data

или разверните последний rsync-снимок тем же способом, каким снимали.

1. Положите файл базы на место, поверх того, что мог быть распакован из архива данных (свежий дамп важнее, чем то, что попало в предыдущий инкрементальный снимок архива):

   cp /var/backups/owncast/db_2026-08-30_0400.db /opt/owncast/data/owncast.db

1. Проверьте права на файлы — если контейнер работает не от root, владелец файлов на хосте должен совпадать с UID, под которым Owncast пишет в volume.
2. Запустите контейнер и проверьте лог:

   cd /opt/owncast
   docker compose up -d
   docker compose logs -f owncast

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

1. Проверьте стрим-ключ и повторно привяжите OBS — даже при успешном восстановлении базы стоит зайти в Config → Server Setup и свериться, что ключ тот же, что был в OBS до аварии, и трансляция стартует без ошибки авторизации.

Если старый сервер ещё жив, а вы просто переезжаете, переключайте DNS-запись домена на новый IP только после того, как убедились, что восстановленный Owncast поднялся корректно и админка открывается.

Частые ошибки бэкапа и восстановления Owncast

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

• Бэкап только конфига без базы. Стрим-ключ, история трансляций и настройки чата хранятся не в docker-compose.yml, а в owncast.db — бэкап одного файла компоуза защищает разве что от лени пересоздавать проброс портов, но не от потери самого сервера.
• Копирование owncast.db во время активной записи обычным cp. SQLite не гарантирует целостность файла при копировании «вживую» без снапшота — используйте .backup через sqlite3 или останавливайте контейнер на момент копирования.
• Бэкап директории с временными HLS-сегментами. Раздувает объём бэкапа без всякой пользы — это транзитные данные текущего эфира, а не архив.
• Восстановление на другой версии Owncast без проверки. Схема базы между мажорными версиями может измениться. Перед восстановлением поставьте ту же версию образа, что была на старом сервере (зафиксированный тег вместо latest в docker-compose.yml упрощает эту задачу), а обновляйтесь уже после успешного восстановления, поэтапно.
• Отсутствие проверки целостности дампа. Бэкап, который ни разу не пробовали восстановить, — это не бэкап, а надежда. PRAGMA integrity_check на базе и тестовое восстановление архива раз в несколько месяцев снимают большую часть неожиданностей.

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