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

MAATRIX

Если OnlyOffice стоит у вас как редактор документов — сам по себе или в связке с Nextcloud, ownCloud, Confluence — потеря сервера означает не просто простой, а риск потерять все документы, которые редактировались в момент сбоя, плюс настройки шаблонов, шрифтов и лицензию. При этом бэкап OnlyOffice — это не «скопировать одну папку»: у него несколько мест хранения состояния, и если забыть хотя бы одно, восстановленный сервер откроется, но документы будут биться на «Document is corrupted» или редактор откажется подключаться к хранилищу. Ниже — рабочая схема бэкапа и восстановления для типового self-hosted OnlyOffice Document Server в Docker.

Что вообще нужно бэкапить в OnlyOffice

OnlyOffice Document Server — это не просто веб-приложение с одной базой. Официальный Docker-образ onlyoffice/documentserver держит внутри контейнера сразу несколько сервисов: сам сервер конвертации, PostgreSQL для хранения списка файлов и версий, RabbitMQ для очередей задач конвертации и файловую область для кэша и временных документов. При стандартном запуске всё это цепляется наружу через volume-маппинги:

docker run -i -t -d -p 80:80 --restart=always \
  -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice \
  -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data \
  -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
  -v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql \
  -v /app/onlyoffice/DocumentServer/fonts:/usr/share/fonts/truetype/custom \
  -v /app/onlyoffice/DocumentServer/forgotten:/var/lib/onlyoffice/documentserver/App_Data/cache/files/forgotten \
  --name onlyoffice-document-server onlyoffice/documentserver

Для бэкапа критичны три вещи из этого списка:

• /var/www/onlyoffice/Data — здесь лежат сертификаты, JWT-секрет (если сгенерирован автоматически) и, для платных редакций, файл лицензии license.lic. Потерять эту папку — значит потерять привязку к лицензии и ключи, которыми редактор подписывает запросы.
• /var/lib/postgresql (или внешняя БД, если вы её вынесли) — реестр документов, версии, история совместного редактирования.
• /app/onlyoffice/DocumentServer/fonts — если вы докидывали кастомные шрифты для корректного открытия документов, без них шрифты в файлах будут подменяться на дефолтные при повторной генерации.

Сами документы (.docx, .xlsx, .pptx) в чистом Document Server физически не хранятся — они лежат в системе, которая его вызывает (Nextcloud, ownCloud, ваше собственное приложение). Поэтому если у вас связка с Nextcloud, бэкап документов делается отдельно — см. бэкап и восстановление Nextcloud, а этот материал закрывает именно сам Document Server: конвертер, очередь и его внутреннюю базу.

Ручной бэкап: тома, БД, JWT-секрет

Первый бэкап лучше сделать руками, чтобы увидеть, что именно куда попадает, прежде чем автоматизировать. Правильный порядок — сначала снять дамп PostgreSQL «изнутри» (через pg_dumpall, а не просто скопировать файлы БД на живую), затем остановить контейнер и заархивировать тома.

# 1. Дамп PostgreSQL из работающего контейнера
docker exec onlyoffice-document-server bash -c \
  "su postgres -c 'pg_dumpall'" > /backup/onlyoffice/db_$(date +%F).sql

# 2. JWT-секрет и лицензия — они читаются из окружения контейнера
docker inspect onlyoffice-document-server \
  --format '{{range .Config.Env}}{{println .}}{{end}}' \
  | grep -E 'JWT_SECRET|JWT_ENABLED' > /backup/onlyoffice/env_$(date +%F).txt

# 3. Останавливаем контейнер, чтобы тома не менялись во время архивации
docker stop onlyoffice-document-server

tar -czf /backup/onlyoffice/data_$(date +%F).tar.gz \
  -C /app/onlyoffice/DocumentServer data lib fonts

docker start onlyoffice-document-server

Дамп базы снимается на лету, а вот data/lib/fonts архивируются с остановленным контейнером — иначе можно поймать файлы в промежуточном состоянии (особенно кэш конвертации). Простой обычно занимает секунды-десятки секунд в зависимости от объёма шрифтов и кэша, для боевого сервера с активным редактированием лучше запускать это ночью.

Отдельно сохраните JWT_SECRET — если он не задан явно через переменную окружения при первом запуске, Document Server генерирует его сам и хранит внутри /var/www/onlyoffice/Data. При восстановлении на новый сервер именно рассинхронизация этого секрета между Document Server и системой, которая его вызывает (Nextcloud/ownCloud/ваш backend), — самая частая причина «редактор не открывается» после переноса.

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

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

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

DEST=/backup/onlyoffice
DATE=$(date +%F)
CONTAINER=onlyoffice-document-server
RETENTION_DAYS=14

mkdir -p "$DEST"

docker exec "$CONTAINER" bash -c "su postgres -c 'pg_dumpall'" \
  > "$DEST/db_$DATE.sql"

docker stop "$CONTAINER"
tar -czf "$DEST/data_$DATE.tar.gz" \
  -C /app/onlyoffice/DocumentServer data lib fonts
docker start "$CONTAINER"

# чистим то, что старше RETENTION_DAYS
find "$DEST" -type f -mtime +"$RETENTION_DAYS" -delete

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

# бэкап OnlyOffice каждую ночь в 03:20
20 3 * * * /usr/local/bin/onlyoffice-backup.sh >> /var/log/onlyoffice-backup.log 2>&1

Пара нюансов, о которые спотыкаются в проде: если у вас несколько сайтов на одном VPS и Document Server крутится не один — держите отдельный DEST и отдельную запись cron на каждый инстанс, иначе архивы будут перезаписывать друг друга по одному и тому же имени файла. И проверяйте, что окно бэкапа (docker stop + архивация) не пересекается с часами активного редактирования — на время простоя все открытые в этот момент документы теряют соединение и пользователю нужно будет обновить страницу.

Храним копии отдельно от сервера

Бэкап, который лежит на том же диске, что и сам сервер, не бэкап — при отказе диска или компрометации сервера вы теряете и данные, и их копию одновременно. Простой вариант — синхронизировать /backup/onlyoffice на S3-совместимое хранилище через rclone:

rclone sync /backup/onlyoffice remote-s3:onlyoffice-backups \
  --transfers 4 --checksum

Добавьте эту команду отдельной строкой в cron сразу после скрипта бэкапа, или встройте вызов rclone sync в конец onlyoffice-backup.sh. Если предпочитаете инкрементальные снапшоты с дедупликацией и шифрованием из коробки — посмотрите restic на VPS, он экономнее по трафику на повторных бэкапах, чем плоская синхронизация. Общие грабли с бэкапом Docker-томов (права доступа, символические ссылки, незамеченные bind-mount) разобраны в статье про бэкап Docker-томов на сервере — они актуальны и для OnlyOffice, поскольку весь его стейт живёт именно в томах.

Отдельно храните файл с JWT_SECRET и лицензией — не в общем архиве с базой (её может понадобиться расшарить с подрядчиком для диагностики), а в защищённом месте, доступ к которому ограничен. Скомпрометированный JWT-секрет позволяет подделывать подписанные запросы к Document Server.

Восстановление и перенос на новый сервер

Восстановление на том же сервере после сбоя — это разворачивание архива в исходные пути и накат дампа БД:

docker stop onlyoffice-document-server
docker rm onlyoffice-document-server

rm -rf /app/onlyoffice/DocumentServer/{data,lib,fonts}
tar -xzf /backup/onlyoffice/data_2026-08-20.tar.gz \
  -C /app/onlyoffice/DocumentServer

# запускаем контейнер заново тем же docker run, что и при первой установке
docker run -i -t -d -p 80:80 --restart=always \
  -e JWT_SECRET="<тот_же_секрет_из_env_файла>" \
  -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice \
  -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data \
  -v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
  -v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql \
  -v /app/onlyoffice/DocumentServer/fonts:/usr/share/fonts/truetype/custom \
  --name onlyoffice-document-server onlyoffice/documentserver

# накатываем дамп базы поверх свежесозданной
cat /backup/onlyoffice/db_2026-08-20.sql | \
  docker exec -i onlyoffice-document-server bash -c "su postgres -c psql"

Ключевой момент — явно указать тот же JWT_SECRET, который был на старом сервере, если он был задан вручную (или восстановить его из сохранённого env_*.txt, если генерировался автоматически). Если этого не сделать, Document Server поднимется, но откажется принимать подписанные запросы от Nextcloud/ownCloud, и вы получите ошибку авторизации при попытке открыть документ.

Перенос на новый VPS делается точно так же плюс два дополнительных шага: обновить DNS-запись (или прокси-конфиг) на новый IP и синхронизировать URL Document Server в настройках связанной системы — в Nextcloud это поле «Document Editing Service address» в приложении ONLYOFFICE. Если менялась связка портов или добавился reverse-proxy с SSL, проверьте, что docservice и spellchecker за прокси проксируются с поддержкой WebSocket — без этого совместное редактирование в реальном времени перестаёт работать, хотя открытие файлов на просмотр остаётся рабочим.

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

Отдельно стоит держать в голове: восстановленный pg_dumpall нужно накатывать на пустую базу — если в свежем контейнере уже успела создаться служебная схема при первом старте, накат дампа поверх неё может выдать конфликты по существующим объектам. Проще всего — накатывать дамп сразу после первого запуска контейнера, до того как через него прошёл хоть один реальный документ.

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