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

MAATRIX

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

Что нужно бэкапить в BigBlueButton

У BBB нет единой базы, где лежит всё — состояние размазано по файловой системе и нескольким СУБД. Если бэкапить наугад «весь /var», объём улетит в сотни гигабайт за счёт временных файлов рендеринга. Разумный список того, что реально нужно:

• Готовые записи — /var/bigbluebutton/published/ (презентация, доска, видео, чат — всё, что видит пользователь после обработки).
• Сырые записи (опционально) — /var/bigbluebutton/recording/raw/, нужны только если вы перегенерируете форматы записи; для обычного архива не критичны и занимают много места.
• База Greenlight — PostgreSQL с комнатами, пользователями, ролями и настройками интерфейса.
• Конфигурация BBB — /etc/bigbluebutton/ целиком: bbb-web.properties, turn-stun-servers.xml, настройки FreeSWITCH, значения securitySalt и bbb-html5.yml.
• SSL-сертификаты — /etc/letsencrypt/ (если используете Let's Encrypt через bbb-conf --setip).
• Docker-волюмы Greenlight — если Greenlight развёрнут через docker compose (стандартно для BBB 2.6+/3.x), это отдельные volume'ы, не файлы на хосте напрямую.

Проверить текущую версию и базовую конфигурацию можно так:

bbb-conf --version
bbb-conf --salt

Второй вызов покажет securitySalt и адрес API — эти значения нужны при восстановлении на новый сервер, чтобы существующие интеграции (LMS, внешние плагины) продолжили работать без переконфигурации.

Бэкап записей конференций

Записи — самая объёмная и самая ценная часть. Формат подкаталогов внутри published/ такой: presentation/<meeting-id>/, video/<meeting-id>/ и так далее, по одному ID встречи на каталог. Для инкрементального бэкапа с дедупликацией подходит restic:

restic -r /mnt/backup/bbb-repo init
restic -r /mnt/backup/bbb-repo backup /var/bigbluebutton/published \
  --tag bbb-recordings

Если храните бэкап на удалённом сервере (что разумно — если сгорит диск основного сервера, локальный бэкап рядом не поможет), тот же restic умеет писать напрямую по SFTP или в S3-совместимое хранилище:

export RESTIC_REPOSITORY=sftp:backup-user@backup-host:/data/bbb
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic backup /var/bigbluebutton/published --tag bbb-recordings

Ключевой момент — записи не меняются после публикации, поэтому инкрементальный бэкап после первого полного прохода будет захватывать только новые встречи, и время бэкапа не растёт линейно с накопленным архивом. Сколько именно места займут записи — сильно зависит от длительности занятий и того, включена ли запись видео с камер или только доска с аудио; ориентируйтесь не на чужие цифры, а на реальный размер /var/bigbluebutton/published на вашем сервере после недели работы.

Если записей мало и хочется решения проще restic, подойдёт обычный rsync в режиме зеркала на внешний диск или второй сервер:

rsync -avz --delete /var/bigbluebutton/published/ \
  backup-host:/data/bbb-recordings/

Флаг --delete синхронизирует удаления — если запись стёрли в Greenlight, она пропадёт и из бэкапа. Это удобно, если бэкап — просто зеркало для быстрого восстановления, но не годится как единственная копия: без версионирования случайное удаление в проде уедет и в бэкап. Для архивной копии либо убирайте --delete, либо держите отдельный архивный снапшот раз в неделю без синхронизации удалений.

Бэкап базы данных Greenlight

Greenlight в актуальных версиях BBB работает в Docker и хранит данные в PostgreSQL-контейнере. Дамп базы снимается через docker exec, без остановки сервиса:

cd /root/greenlight-v3   # каталог с docker-compose.yml Greenlight
docker compose exec postgres pg_dump -U postgres greenlight_production \
  | gzip > /backup/greenlight_$(date +%F).sql.gz

Название контейнера и базы уточните в вашем docker-compose.yml — они могут отличаться в зависимости от того, как разворачивали Greenlight (через официальный install.sh или вручную). Посмотреть список запущенных контейнеров:

docker compose ps
docker compose exec postgres psql -U postgres -l

Отдельно стоит забрать переменные окружения из .env в каталоге Greenlight — там лежат SECRET_KEY_BASE, ключи для интеграции с BBB API и настройки OAuth, если используется вход через сторонний провайдер. Потеря этого файла означает, что после восстановления все пользователи будут разлогинены, а внешние интеграции придётся настраивать заново.

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

Бэкап конфигурации и сертификатов

Конфигурация BBB — это не только один файл, а набор XML и properties-файлов, которые bbb-install.sh генерирует и правит под конкретный домен и IP при установке. Пересобирать их с нуля вручную долго и легко ошибиться в мелочи вроде порта TURN-сервера. Проще архивировать каталог целиком:

tar czf /backup/bbb-config_$(date +%F).tar.gz \
  /etc/bigbluebutton \
  /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties \
  /etc/letsencrypt

Обратите внимание на securitySalt в bigbluebutton.properties — это общий секрет между BBB-сервером и всеми клиентами API (включая Greenlight и любые внешние интеграции с LMS). Если он потеряется и при восстановлении сервер сгенерирует новый через bbb-conf --setsecret, все внешние интеграции придётся перевыпускать заново — старые API-ключи перестанут работать.

Сертификаты Let's Encrypt из /etc/letsencrypt можно не бэкапить отдельно, если при восстановлении вы всё равно планируете перевыпустить их через certbot на новом IP — но если домен и старый сервер продолжают существовать параллельно (миграция без даунтайма), сохранённые сертификаты сэкономят время и не упрутся в rate limit Let's Encrypt.

Автоматизация бэкапа по расписанию

Ручной бэкап рано или поздно забудется — особенно перед выходными, когда сбой обиднее всего. Собираем всё в один скрипт и вешаем на cron:

#!/bin/bash
# /usr/local/bin/bbb-backup.sh
set -euo pipefail

BACKUP_DATE=$(date +%F)
DEST=/backup/bbb

mkdir -p "$DEST"

# 1. Записи (инкрементально через restic)
restic -r /mnt/backup/bbb-repo backup /var/bigbluebutton/published \
  --tag bbb-recordings

# 2. База Greenlight
cd /root/greenlight-v3
docker compose exec -T postgres pg_dump -U postgres greenlight_production \
  | gzip > "$DEST/greenlight_${BACKUP_DATE}.sql.gz"

# 3. Конфиги и .env Greenlight
tar czf "$DEST/bbb-config_${BACKUP_DATE}.tar.gz" \
  /etc/bigbluebutton \
  /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties \
  /root/greenlight-v3/.env

# 4. Чистка старых локальных дампов (старше 14 дней)
find "$DEST" -name "*.sql.gz" -mtime +14 -delete
find "$DEST" -name "*.tar.gz" -mtime +14 -delete

chmod +x /usr/local/bin/bbb-backup.sh
crontab -e

# Каждую ночь в 3:20, вне часов занятий
20 3 * * * /usr/local/bin/bbb-backup.sh >> /var/log/bbb-backup.log 2>&1

Флаг -T в docker compose exec отключает выделение псевдо-TTY — без него cron-запуск дампа может зависнуть или упасть с ошибкой, потому что у cron нет интерактивного терминала. Это частая причина, почему бэкап «работал руками, а по расписанию не сработал» — стоит проверить в первую очередь, если лог cron пустой, а файла дампа нет.

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

Хранить копию бэкапа стоит не на том же физическом сервере — принцип тот же, что при бэкапе любых Docker-сервисов: частые ошибки при бэкапе Docker volume на сервере разбирает похожие грабли с правами доступа и путями внутри контейнеров, применимые и к связке BBB + Greenlight.

Восстановление BigBlueButton из бэкапа

Восстановление всегда начинается с чистой установки той же версии BBB, а не с распаковки бэкапа поверх произвольного окружения — версии BBB между собой не всегда совместимы по формату конфигов и схеме БД.

Шаг 1. Установка BBB той же версии на новый сервер тем же способом, каким ставили исходный (обычно bbb-install.sh с указанием домена):

wget -qO- https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh \
  | bash -s -- -w -v focal-300 -s conf.example.com -e admin@example.com

Версию (-v) берите точно ту же, что была на исходном сервере — узнать её можно было заранее через bbb-conf --version, и хорошая практика — фиксировать эту версию в файле рядом с бэкапом.

Шаг 2. Остановка сервисов перед подменой конфигов и данных:

bbb-conf --stop
cd /root/greenlight-v3 && docker compose down

Шаг 3. Восстановление записей:

restic -r /mnt/backup/bbb-repo restore latest \
  --target / --include /var/bigbluebutton/published
chown -R bigbluebutton:bigbluebutton /var/bigbluebutton/published

Шаг 4. Восстановление базы Greenlight:

cd /root/greenlight-v3
docker compose up -d postgres
sleep 10
gunzip -c /backup/bbb/greenlight_2026-08-30.sql.gz | \
  docker compose exec -T postgres psql -U postgres greenlight_production

Шаг 5. Восстановление конфигов и .env:

tar xzf /backup/bbb/bbb-config_2026-08-30.tar.gz -C /

Шаг 6. Применение конфигурации и запуск:

bbb-conf --setip conf.example.com
bbb-conf --restart
cd /root/greenlight-v3 && docker compose up -d

Шаг 7. Проверка:

bbb-conf --check

Команда пройдётся по всем компонентам — FreeSWITCH, веб-серверу, TURN — и покажет, что не запустилось. Отдельно зайдите в Greenlight через браузер и убедитесь, что старые комнаты и пользователи на месте, а тестовая конференция создаётся и подключается со звуком.

Если восстанавливаетесь на сервер с другим IP (миграция, а не просто пересоздание после сбоя), обязательно перевыпустите или обновите TURN-конфигурацию — bbb-conf --setip сам обновит большинство ссылок, но за DNS-записью на новый IP нужно проследить отдельно, иначе клиенты будут резолвить старый адрес до истечения TTL.

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