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

MAATRIX

PeerTube — не просто набор видеофайлов, а связка из базы данных, объектного хранилища и криптографических ключей федерации ActivityPub. Потерять диск с видео обидно, но потерять базу PostgreSQL — значит потерять сам канал: подписчиков, комментарии, плейлисты и саму идентичность instance в сети. Разберём, что именно нужно бэкапить в PeerTube, как это делать без даунтайма и как поднять инстанс заново на чистом сервере, если старый умер целиком.

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

PeerTube хранит данные в трёх разных местах, и бэкап только одного из них — это не бэкап, а иллюзия бэкапа:

• PostgreSQL — вся метаинформация: пользователи, видео (названия, описания, теги, статистика), подписки, комментарии, плейлисты, abuse-репорты, права модераторов. Без базы файлы видео превращаются в набор безымянных .mp4 без единой связи между собой.
• Файловое хранилище — каталог storage из config/production.yaml (по умолчанию /var/www/peertube/storage при classic-установке или volume data в Docker). Внутри — videos/, streaming-playlists/ (HLS-сегменты), avatars/, videos-playlist/ (превью плейлистов), captions/ (субтитры), torrents/ и well-known/ с nodeinfo.
• Конфигурация и секреты — config/production.yaml (или .env для Docker-установки) и особенно приватный/публичный ключ ActivityPub-актора инстанса. Этот ключ определяет, что для остальной федерации ваш сервер — «тот самый» сервер; потеряв его, вы не восстановите доверие подписанных другими instance подписок, придётся заново отстраивать федерацию с нуля.

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

Каталоги tmp/ и cache/ внутри storage — тоже мусор для бэкапа: tmp/ содержит недокачанные/недокодированные файлы, cache/ — временные превью и HLS-фрагменты, которые пересоздаются автоматически. Исключайте их явно — иначе бэкап раздувается в разы без всякой пользы.

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

Данные для подключения лежат в config/production.yaml в секции database (host, port, name, username, password) — они понадобятся, если делаете дамп не из-под пользователя postgres. Само резервное копирование — стандартный pg_dump в custom-формате, он компактнее plain SQL и позволяет восстанавливать выборочно:

sudo -u postgres pg_dump -Fc -Z 5 peertube_prod > /var/backups/peertube/db_$(date +%F_%H%M).dump

Для Docker-инсталляции (образ chocobozzz/peertube) дамп снимается через docker compose exec:

docker compose exec -T postgres pg_dump -U peertube -Fc peertube > /var/backups/peertube/db_$(date +%F_%H%M).dump

Дамп в custom-формате весит немного даже на инстансах с десятками тысяч видео — там только метаданные, а не сами файлы. Проверить дамп на целостность без реального восстановления можно так:

pg_restore --list /var/backups/peertube/db_2026-08-30_0300.dump | head -20

Если команда вернула список объектов базы, а не ошибку — дамп читаемый.

Бэкап хранилища видео

Хранилище — самая тяжёлая часть бэкапа, и здесь выбор инструмента зависит от объёма. Для инстансов до пары сотен гигабайт достаточно rclone или restic с исключением служебных каталогов:

rclone sync /var/www/peertube/storage/ remote:peertube-backup/storage/ \
  --exclude "tmp/**" \
  --exclude "cache/**" \
  --transfers 8 \
  --checkers 16

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

restic -r s3:https://s3.example.com/peertube-backup init
restic -r s3:https://s3.example.com/peertube-backup backup \
  /var/www/peertube/storage \
  --exclude "storage/tmp" \
  --exclude "storage/cache"

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

Важный нюанс именно для видеохостинга: если у вас включено объектное хранилище как основной storage PeerTube (S3 вместо локального диска — настраивается в object_storage секции production.yaml), то бэкап уже не файловая копия, а репликация бакета в другой регион или к другому провайдеру — политики версионирования и жизненного цикла бакета настраиваются на стороне самого S3, а не через rclone/restic.

Бэкап конфигурации, ключей и Redis-очереди

Конфиг и ключи федерации — маленькие по объёму, но критичные по значимости файлы. Собираем их отдельным лёгким архивом, который стоит хранить в нескольких копиях сразу:

tar czf /var/backups/peertube/config_$(date +%F).tar.gz \
  /var/www/peertube/config/production.yaml \
  /var/www/peertube/.env 2>/dev/null

Приватный ключ актора инстанса лежит не отдельным файлом, а в базе (таблица actor, поле privateKey), так что при полном дампе PostgreSQL он уже включён — отдельно копировать его не нужно, если база бэкапится регулярно. Отдельно стоит вынести переменные окружения, которые не лежат в git и не хранятся в конфиге явно: SMTP-пароль, если он задан через переменную окружения, и секреты для интеграции с внешними сервисами (например, ключи для reCAPTCHA или объектного хранилища).

Redis-очередь бэкапить не нужно — PeerTube сам пересоздаёт её при старте, копировать туда нечего.

Скрипт автоматизации и хранение бэкапов

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

#!/bin/bash
set -euo pipefail

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

mkdir -p "$BACKUP_DIR"

# 1. База данных
sudo -u postgres pg_dump -Fc -Z 5 peertube_prod > "$BACKUP_DIR/db_$DATE.dump"

# 2. Конфиги
tar czf "$BACKUP_DIR/config_$DATE.tar.gz" \
  /var/www/peertube/config/production.yaml 2>/dev/null

# 3. Хранилище — через restic, инкрементально
restic -r s3:https://s3.example.com/peertube-backup backup \
  /var/www/peertube/storage \
  --exclude "storage/tmp" \
  --exclude "storage/cache" \
  --tag "$DATE"

# 4. Ротация локальных дампов и конфигов
find "$BACKUP_DIR" -name "*.dump" -mtime +"$KEEP_DAYS" -delete
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +"$KEEP_DAYS" -delete

# 5. Ротация снапшотов restic (хранилище)
restic -r s3:https://s3.example.com/peertube-backup forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Поставьте его в cron на ночное время, когда трафик и активная загрузка видео минимальны — транскодинг в PeerTube нагружает CPU, и параллельный снятие дампа/синк лучше не накладывать на пиковую очередь:

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

Дамп базы во время работы PostgreSQL безопасен сам по себе — pg_dump снимает консистентный снапшот через MVCC и не блокирует запись. А вот rsync/restic по живому хранилищу видео теоретически может зацепить файл в процессе записи (например, идёт загрузка нового ролика) — на практике PeerTube пишет во временный файл в tmp/ и переименовывает в целевой каталог только по завершении, так что рабочие видео в момент бэкапа уже статичны.

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

Порядок восстановления должен строго соответствовать порядку установки — если развернуть PeerTube «поверх» пустой базы, а потом залить дамп, легко получить конфликт версий миграций. Последовательность:

1. Разверните PeerTube той же версии, что была на исходном сервере (проверить версию можно было в package.json старого инстанса или в футере админ-панели). Смешение версий — частая причина, почему восстановленный дамп не применяется: свежая мажорная версия PeerTube может ожидать уже применённые миграции, которых в старом дампе ещё нет.
2. Поднимите чистый PostgreSQL и Redis, создайте пустую базу peertube_prod с тем же владельцем-пользователем, что был в оригинале.
3. Восстановите дамп базы:

   sudo -u postgres pg_restore -d peertube_prod --clean --if-exists /var/backups/peertube/db_2026-08-30_0300.dump

1. Верните конфигурацию — распакуйте архив config_*.tar.gz в config/production.yaml, поправьте в нём хосты базы/Redis, если они изменились (новый IP сервера, новый пароль PostgreSQL).
2. Восстановите хранилище:

   restic -r s3:https://s3.example.com/peertube-backup restore latest \
     --target /var/www/peertube/storage

или rclone sync remote:peertube-backup/storage/ /var/www/peertube/storage/, в зависимости от того, чем бэкапили.

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

   chown -R peertube:peertube /var/www/peertube/storage

1. Запустите сервис и проверьте миграции:

   systemctl start peertube
   journalctl -u peertube -f

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

1. Проверьте федерацию — зайдите в админку в раздел «Federation» и убедитесь, что follow/followers не потерялись. Если приватный ключ актора восстановился вместе с базой (а он восстанавливается вместе с ней), другие инстансы продолжат доверять вашему серверу как прежде и разрыва подписок быть не должно.

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

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