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

MAATRIX

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

Что входит в бэкап Emby

Emby хранит рабочие данные отдельно от самой медиатеки, в каталоге программных данных (Program Data Path). При установке через официальный .deb/.rpm-пакет на Linux это, как правило, /var/lib/emby; при установке через Docker-образ (emby/embyserver или сборки на его основе) это содержимое смонтированного volume /config. Внутри — несколько подкаталогов, и не все из них одинаково важны:

• data/ — здесь лежат SQLite-базы, главная из которых library.db: полное описание медиатеки (фильмы, сериалы, эпизоды, актёры, коллекции), история просмотров, точки возврата, избранное. Рядом обычно лежат playback_reporting.db (если включён соответствующий плагин статистики) и другие служебные базы. Это критическое ядро бэкапа.
• config/ — настройки сервера в XML (в разных версиях файл называется system.xml либо просто хранится как часть конфигурации сервера), профили пользователей и их права, а главное — уникальный Server ID, который Emby использует для Emby Connect и удалённого доступа. Потеряете этот файл при переустановке — получите новый Server ID и придётся заново привязывать сервер к аккаунту Emby Connect и перенастраивать удалённый доступ у всех пользователей.
• metadata/ — скачанные постеры, фан-арт, описания, NFO-файлы, которые Emby подтягивает из внешних баз (TMDb, TheTVDB) при сканировании библиотеки. Технически всё это можно перекачать заново повторным сканированием, но на большой коллекции это часы работы и лишняя нагрузка на внешние API — бэкапить стоит.
• plugins/ — установленные плагины и их собственные конфиги (субтитровые провайдеры, интеграции, статистика просмотров). Без бэкапа плагины придётся переустанавливать и настраивать заново по одному.
• cache/ и transcoding-temp/ — исключайте из бэкапа целиком. Это временные файлы транскодирования и кэш изображений, которые Emby пересоздаёт сам при следующем обращении. Бэкапить их — только раздувать архив без всякой пользы.

Сама медиатека (файлы фильмов и сериалов) физически лежит отдельно — обычно на отдельном диске или сетевом хранилище, подключённом как медиа-папка. Её бэкап — отдельный вопрос, разберём его ниже.

Встроенный бэкап и восстановление в Dashboard

В современных версиях Emby Server есть штатный инструмент бэкапа прямо в панели администратора: Dashboard → Advanced → Backup/Restore (в некоторых версиях пункт может называться иначе, но логика та же). Там можно:

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

Это удобный вариант для быстрого старта: не нужно разбираться, какие подкаталоги включать, а какие исключать — сервер сам знает свою структуру. Ограничение в том, что архив по умолчанию складывается на тот же сервер (или в указанную сетевую папку) — сам по себе это не защита от отказа диска или всего сервера целиком. Синхронизируйте папку с архивами на внешнее хранилище тем же rclone или restic, просто как дополнительный шаг поверх штатного механизма.

Ручной бэкап конфигурации и базы данных

Ручной способ даёт больше контроля: понятный формат архива, возможность зашифровать, положить сразу в S3-совместимое хранилище и не зависеть от версии встроенного инструмента. SQLite не любит, когда файл копируют «на лету» при активной записи — поэтому либо ненадолго останавливаем сервис, либо используем безопасный онлайн-бэкап через сам SQLite.

Вариант с остановкой сервиса (самый надёжный, пара секунд простоя):

sudo systemctl stop emby-server

tar czf /var/backups/emby/emby_$(date +%F_%H%M).tar.gz \
  --exclude='cache' \
  --exclude='transcoding-temp' \
  -C /var/lib/emby .

sudo systemctl start emby-server

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

sqlite3 /var/lib/emby/data/library.db ".backup '/var/backups/emby/library_$(date +%F_%H%M).db'"

tar czf /var/backups/emby/config_$(date +%F_%H%M).tar.gz \
  -C /var/lib/emby config metadata plugins

Для восстановления полной картины после аварии нужны оба архива: снапшот базы и упаковка конфига/метаданных/плагинов.

Бэкап в Docker-инсталляции

Если Emby запущен в контейнере, вся структура data/config/metadata/plugins лежит внутри смонтированного volume, обычно указанного как /config в docker-compose.yml:

services:
  emby:
    image: emby/embyserver
    volumes:
      - /opt/emby/config:/config
      - /mnt/media:/media
    ports:
      - "8096:8096"

Бэкап в этом случае — это архивирование каталога на хосте, без необходимости лезть внутрь контейнера:

docker compose stop emby

tar czf /var/backups/emby/emby_docker_$(date +%F_%H%M).tar.gz \
  --exclude='cache' \
  --exclude='transcoding-temp' \
  -C /opt/emby/config .

docker compose start emby

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

Нужно ли бэкапить саму медиатеку

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

Для больших объёмов (сотни гигабайт и терабайты) практичнее не полный tar, а инкрементальная синхронизация через rclone или дедуплицирующий restic — они копируют только новые и изменённые файлы:

restic -r s3:https://s3.example.com/emby-media backup /mnt/media \
  --exclude "*.tmp"

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

Автоматизация: скрипт и ротация

Собираем оба типа бэкапа (без остановки сервиса) в один cron-скрипт с ротацией старых копий:

#!/bin/bash
set -euo pipefail

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

mkdir -p "$BACKUP_DIR"

# 1. Снапшот базы без остановки сервиса
sqlite3 "$EMBY_DATA/data/library.db" ".backup '$BACKUP_DIR/library_$DATE.db'"

# 2. Конфиг, метаданные и плагины
tar czf "$BACKUP_DIR/config_$DATE.tar.gz" \
  -C "$EMBY_DATA" config metadata plugins

# 3. Ротация локальных копий
find "$BACKUP_DIR" -name "*.db" -mtime +"$KEEP_DAYS" -delete
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +"$KEEP_DAYS" -delete

# 4. Синхронизация на внешнее хранилище
rclone sync "$BACKUP_DIR" remote:emby-backup/ --transfers 4

Ставим в cron на ночное время, когда активных просмотров и фонового сканирования библиотеки меньше всего:

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

Правило 3-2-1 (минимум три копии, на двух разных носителях, одна — вне основной площадки) применимо к Emby так же, как к любой боевой системе: локальная копия на том же диске не спасёт от отказа сервера целиком, только от случайной порчи файла.

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

Порядок восстановления имеет значение — конфиг и база должны быть на месте раньше первого старта сервиса, иначе Emby создаст новую пустую базу и новый Server ID вместо того, чтобы подхватить восстановленные данные:

1. Установите Emby Server той же мажорной версии, что была на исходном сервере (или новее — Emby обычно применяет миграции базы вперёд, но не назад). Версию можно было увидеть внизу страницы Dashboard старого сервера.
2. Остановите сервис сразу после установки, до первого запуска с пустыми данными:

   sudo systemctl stop emby-server

1. Разверните данные в каталог программных данных:

   sudo tar xzf /var/backups/emby/emby_2026-08-30_0400.tar.gz -C /var/lib/emby

Если бэкапили отдельно базу и конфиг — сначала распакуйте config_*.tar.gz, затем положите library_*.db на место data/library.db.

1. Верните права на файлы — сервис Emby на Linux обычно работает от системного пользователя emby:

   sudo chown -R emby:emby /var/lib/emby

1. Подключите медиа-папки — если пути к медиатеке на новом сервере отличаются от исходных (другой сервер хранения, другая точка монтирования), это единственное, что придётся поправить в настройках библиотек через веб-интерфейс после старта; сами записи о фильмах в базе сохранятся, Emby попросит только указать новый путь при несовпадении.
2. Запустите сервис и проверьте логи:

   sudo systemctl start emby-server
   journalctl -u emby-server -f

Веб-интерфейс должен открыться на порту 8096 с теми же пользователями, коллекциями и историей просмотров, что были на старом сервере.

1. Проверьте Server ID и Emby Connect — зайдите в Dashboard → General и убедитесь, что сервер отображается под тем же именем и продолжает быть привязанным к аккаунту Emby Connect. Если конфиг восстановился корректно, повторной привязки не потребуется и удалённый доступ у пользователей продолжит работать без пересоздания приглашений.

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

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