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

MAATRIX

Кажется логичным, что видеоконференции без установки приложений — штука почти без состояния: звонок закончился, и бэкапировать вроде бы нечего. На деле self-hosted Jitsi Meet — это связка из четырёх-пяти сервисов (веб-интерфейс, Prosody, Jicofo, JVB, опционально Jibri), которые держатся друг за друга общими паролями и сертификатами. Потеряете один файл .env или директорию конфигов Prosody — и после восстановления компоненты просто перестанут между собой договариваться, хотя каждый по отдельности запустится без единой ошибки в логах. Ниже — что реально нужно копировать и как поднять всё заново без часов на подбор паролей вручную.

Архитектура Jitsi Meet и что в ней хранится

Стандартный self-hosted вариант — docker-jitsi-meet, набор из нескольких контейнеров вокруг одного docker-compose.yml:

• web — nginx с фронтендом Jitsi и (опционально) сертификатами Let's Encrypt;
• prosody — XMPP-сервер, через него общаются все участники звонка и внутренние компоненты; здесь же, если включён secure domain или JWT-логин, живут учётные записи пользователей;
• jicofo — координатор конференций, распределяет участников по мостам;
• jvb (Jitsi Videobridge) — собственно пересылка видеопотоков;
• jibri и jigasi — опциональные модули записи встреч и SIP-звонков, есть не у всех инсталляций.

Само видео не сохраняется нигде, кроме RAM во время звонка — это правда стейтлесс. Но у Jicofo, JVB, Jigasi и Jibri есть свои XMPP-пароли и общий component secret, которыми они аутентифицируются друг перед другом в Prosody. Это не декоративные значения: если после восстановления пароль в .env не совпадёт с тем, что Prosody ожидает от JVB, видеобридж не подключится к XMPP, и звонки будут создаваться, но без видео — участники увидят только чёрные квадраты. Именно поэтому бэкап Jitsi Meet — это в первую очередь бэкап секретов и конфигов, а не данных в привычном смысле.

Что физически нужно копировать в типовой установке через docker-jitsi-meet:

• файл .env в корне репозитория — домен, флаги (ENABLE_LETSENCRYPT, ENABLE_AUTH, ENABLE_GUESTS и т.д.) и все пароли, сгенерированные скриптом gen-passwords.sh;
• директория, на которую указывает переменная CONFIG (обычно ~/.jitsi-meet-cfg) — в ней подпапки web, prosody/config, prosody/data, jicofo, jvb, jigasi, jibri;
• сам docker-compose.yml, если вы его правили (добавляли TURN, меняли порты, подключали свой nginx-конфиг для брендинга);
• записи Jibri, если модуль включён — отдельная история, ниже.

Если вы ставили Jitsi Meet классическим способом через .deb-пакеты, а не в Docker, набор файлов другой: /etc/prosody/conf.d/<домен>.cfg.lua и /var/lib/prosody/ (учётки и данные XMPP), /etc/jitsi/jicofo/, /etc/jitsi/videobridge/, /etc/jitsi/meet/<домен>-config.js, /etc/jitsi/jibri/ и сертификаты в /etc/letsencrypt/. Логика бэкапа та же — секреты и конфиг, — просто пути другие.

Бэкап `.env` и общих секретов компонентов

Это самая критичная и самая маленькая по объёму часть. В .env после ./gen-passwords.sh лежат значения вроде JICOFO_COMPONENT_SECRET, JICOFO_AUTH_PASSWORD, JVB_AUTH_PASSWORD, JIGASI_XMPP_PASSWORD, JIBRI_RECORDER_PASSWORD, JIBRI_XMPP_PASSWORD — их держит в согласованном состоянии сам генератор, вручную пересоздавать их после аварии не вариант: старый Prosody-конфиг будет ждать одни значения, а новый .env сгенерирует другие.

mkdir -p /opt/backups/jitsi
cp ~/docker-jitsi-meet/.env /opt/backups/jitsi/env-$(date +%F)
cp ~/docker-jitsi-meet/docker-compose.yml /opt/backups/jitsi/ 2>/dev/null || true

Файл небольшой, но в нём пароли открытым текстом, поэтому хранить его нужно так же осторожно, как приватный SSH-ключ — вне публичных репозиториев, желательно с шифрованием на удалённом хранилище. Общий подход к шифрованным бэкапам разобран в статье про бэкап с шифрованием на VPS.

Бэкап конфигурации: директория CONFIG

Директория, на которую указывает CONFIG в .env, — это постоянное состояние всех компонентов между перезапусками контейнеров. Архивируем её целиком:

CONFIG_DIR=$(grep -E '^CONFIG=' ~/docker-jitsi-meet/.env | cut -d= -f2 | envsubst)
tar czf /opt/backups/jitsi/config-$(date +%F).tar.gz -C "$(dirname "$CONFIG_DIR")" "$(basename "$CONFIG_DIR")"

Внутри этой директории — не только служебные файлы вроде jvb/sip-communicator.properties, но и то, что реально жалко потерять при кастомизации:

• web/ — если правили брендинг (свой логотип, interface_config.js, тексты, favicon) или подключали кастомный nginx.conf для welcome-страницы;
• prosody/config/ — конфигурация виртуального хоста, модулей аутентификации;
• prosody/data/ — если включён secure domain (ENABLE_AUTH=1 + AUTH_TYPE=internal) или JWT-логин со списком пользователей, добавленных через prosodyctl register, — сами учётные записи хранятся здесь;
• web/letsencrypt/ (или аналогичный путь, зависит от версии) — сертификаты, если Jitsi управляет ими сам через ENABLE_LETSENCRYPT=1, а не через внешний реверс-прокси.

Если сертификаты выпускает не сам Jitsi, а внешний Nginx или Traefik перед ним — это отдельная зона ответственности и отдельный бэкап, не пересекающийся с описанным здесь.

Бэкап Prosody отдельно: пользователи и secure domain

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

docker exec jitsi-prosody prosodyctl --config /config/prosody.cfg.lua mod_list_users <ваш-домен>

Точное имя команды листинга пользователей зависит от установленных модулей Prosody — на некоторых сборках проще выгрузить список напрямую из prosody/data, где для встроенного (internal) способа хранения каждый пользователь — это отдельный Lua-файл в поддиректории домена. Логика та же, что для бэкапа любого self-hosted сервиса на файлах состояния: копируем как есть, без "экспорта" через API, которого у Prosody для этого попросту нет.

Записи Jibri: где искать и как не потерять

Jibri — модуль, который через headless Chrome записывает конференцию в видеофайл. По умолчанию в базовом docker-compose.yml от docker-jitsi-meet директория для готовых записей не примонтирована наружу — это осознанное решение авторов проекта, потому что не все используют запись. Если вы включали Jibri, почти наверняка вы уже добавляли свой volume в docker-compose.override.yml — например:

services:
  jibri:
    volumes:
      - ~/jitsi-recordings:/config/recordings

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

rsync -a --remove-source-files ~/jitsi-recordings/ /mnt/storage/jitsi-recordings/

Флаг --remove-source-files уместен, если локальный диск сервера маленький и записи нужно сразу переносить в постоянное хранилище, а не держать копию на VPS. Если для этого используете S3-совместимое хранилище на своём сервере — принципы настройки и бэкапа такого хранилища подробно разобраны в статье про бэкап и восстановление MinIO.

Автоматизация и восстановление на новом сервере

Собираем всё в один скрипт под cron — секреты, конфиг и (опционально) свежие записи:

#!/bin/bash
set -euo pipefail

DATE=$(date +%F)
BACKUP_DIR="/opt/backups/jitsi"
JITSI_DIR="/root/docker-jitsi-meet"
mkdir -p "$BACKUP_DIR"

CONFIG_DIR=$(grep -E '^CONFIG=' "$JITSI_DIR/.env" | cut -d= -f2 | envsubst)

cp "$JITSI_DIR/.env" "$BACKUP_DIR/env-$DATE"
cp "$JITSI_DIR/docker-compose.yml" "$BACKUP_DIR/" 2>/dev/null || true
tar czf "$BACKUP_DIR/config-$DATE.tar.gz" -C "$(dirname "$CONFIG_DIR")" "$(basename "$CONFIG_DIR")"

tar czf "$BACKUP_DIR/jitsi-full-$DATE.tar.gz" \
  -C "$BACKUP_DIR" "env-$DATE" "config-$DATE.tar.gz" docker-compose.yml

rclone copy "$BACKUP_DIR/jitsi-full-$DATE.tar.gz" remote:jitsi-backups/

find "$BACKUP_DIR" -name "env-*" -mtime +7 -delete
find "$BACKUP_DIR" -name "config-*.tar.gz" -mtime +7 -delete

0 4 * * * /opt/scripts/backup-jitsi.sh >> /var/log/jitsi-backup.log 2>&1

Восстановление на новом сервере — по сути, обычный деплой docker-jitsi-meet с подменой конфигов до первого старта:

git clone https://github.com/jitsi/docker-jitsi-meet.git
cd docker-jitsi-meet

cp /opt/backups/jitsi/env-2026-08-28 .env
mkdir -p ~/.jitsi-meet-cfg
tar xzf /opt/backups/jitsi/config-2026-08-28.tar.gz -C ~/.jitsi-meet-cfg --strip-components=1

docker compose up -d
docker compose logs -f prosody jicofo jvb

В логах ищите строку об успешном коннекте JVB и Jicofo к Prosody (обычно это connected или logged in без последующих reconnect-циклов раз в несколько секунд — постоянные переподключения означают несовпадение секретов). Дальше — контрольный звонок с двух устройств: одно видео недостаточно, чтобы убедиться, что видеобридж действительно пробрасывает поток, а не просто держит соединение открытым. Если использовали Jibri, отдельно проверьте тестовую запись — модуль восстанавливает работоспособность автоматически при верных паролях, но зависит от Chrome-профиля внутри контейнера, который иногда полезно пересоздать с нуля, а не переносить из старого бэкапа.

Если поднимаете Jitsi Meet на новом VPS не поверх существующего Docker-хоста, а с нуля, общая последовательность настройки продакшен-окружения на Docker Compose — включая firewall и swap — описана в статье про Docker Compose для продакшена на Ubuntu 24.04. Отдельно не забудьте про порты: помимо обычных 80/443, JVB слушает UDP 10000 для медиапотоков — без него звонки будут создаваться, но видео не пойдёт даже при полностью верном восстановлении конфигов.

Для самих бэкапов — как конфигов, так и записей — держите хотя бы одну копию не на том же сервере, где крутится Jitsi: если сервер целиком недоступен, локальный архив бесполезен. Общие принципы выбора площадки под такое хранилище — в статье про VPS для бэкапов и архива.

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