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

MAATRIX

Collabora Online падает редко сам по себе — обычно проблема прилетает извне: обновление контейнера ломает совместимость с Nextcloud, хостер переносит VPS на новый IP, или кто-то случайно затирает coolwsd.xml при правке конфига. И тут выясняется неприятная вещь: половина команд уже привыкла редактировать документы прямо в браузере, а «просто переустановить контейнер» не решает проблему — теряются кастомные шрифты, ограничения WOPI, пароль админ-консоли и вообще понимание, что именно нужно было сохранить. Ниже — рабочая схема бэкапа и восстановления, которая учитывает главную особенность Collabora Online: сам редактор документы не хранит, но без правильного бэкапа связки с Nextcloud восстановление всё равно сломается.

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

Ключевой момент, который путает многих: Collabora Online (он же COOL, Collabora Online Development Edition в старой терминологии) — это stateless-рендерер. Он открывает документ по протоколу WOPI, показывает его в браузере через LibreOffice-движок и сохраняет изменения обратно в хранилище — но сам файлы не держит. Хранилище — это Nextcloud (или другой WOPI-host: ownCloud, Seafile с плагином и т.д.).

Отсюда и список того, что реально нужно бэкапить на стороне Collabora:

• coolwsd.xml — главный конфиг: список разрешённых WOPI-хостов, настройки SSL, admin-console логин и хеш пароля, лимиты памяти на процесс.
• Сертификаты и приватные ключи, если Collabora сам терминирует TLS (не через отдельный nginx-прокси).
• Кастомные шрифты, если вы их докидывали в контейнер — иначе документы с нестандартными шрифтами после переустановки начнут «плыть» по вёрстке.
• docker-compose.yml и .env — тег образа, домен, aliasgroup, переменные окружения.
• Файлы брендинга, если меняли логотип/цвета интерфейса редактора.

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

Бэкап Docker-контейнера и volume Collabora

Почти всегда Collabora Online разворачивают в Docker — это единственный официально поддерживаемый способ для self-hosted версии. Типичный docker-compose.yml:

services:
  collabora:
    image: collabora/code:24.04.11.1.1  # уточните актуальный тег на Docker Hub перед разворачиванием
    restart: unless-stopped
    environment:
      - domain=nextcloud\\.example\\.com
      - username=admin
      - password=${COOL_ADMIN_PASSWORD}
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
    volumes:
      - ./coolwsd.xml:/etc/coolwsd/coolwsd.xml:ro
      - ./fonts:/usr/share/fonts/custom:ro
    cap_add:
      - MKNOD
    ports:
      - "127.0.0.1:9980:9980"

Если конфиги и шрифты подключены bind-mount’ом (как в примере выше), бэкап сводится к обычному копированию каталога с хоста — никакой магии с docker cp не нужно:

tar czf collabora-backup-$(date +%F).tar.gz \
  docker-compose.yml .env coolwsd.xml fonts/

Если вместо bind-mount используются именованные Docker volume, доставайте данные через временный контейнер:

docker run --rm \
  -v collabora_config:/data \
  -v $(pwd):/backup \
  busybox tar czf /backup/collabora-config-$(date +%F).tar.gz -C /data .

Сам образ collabora/code пересобирать из бэкапа не нужно — он тянется из реестра при docker compose up, бэкапить стоит только то, что вы реально настраивали руками.

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

coolwsd.xml — самый чувствительный файл в этой связке. В нём, помимо технических настроек, лежит хеш пароля admin-консоли (admin_console → username/password) и список доверенных WOPI-хостов (storage.wopi.host). Если этот файл попадёт в публичный репозиторий или незашифрованный бэкап на общем диске — это уже утечка доступа к консоли редактора.

Практика:

mkdir -p ~/backup/collabora
cp /etc/coolwsd/coolwsd.xml ~/backup/collabora/
cp -r /etc/coolwsd/proof_key* ~/backup/collabora/ 2>/dev/null || true
tar czf collabora-config-$(date +%F).tar.gz -C ~/backup collabora

proof_key и proof_key.pub — это ключевая пара, которой Collabora подписывает WOPI-запросы к Nextcloud. Если она потеряется и будет сгенерирована заново на новом сервере, Nextcloud начнёт отклонять запросы с ошибкой проверки подписи — придётся заново прописывать публичный ключ в настройках richdocuments. Проще сохранить оригинальную пару и восстановить её как есть.

Если TLS терминируется не в самом Collabora, а на внешнем nginx (рекомендуемая схема для продакшена), сертификаты бэкапятся отдельно — вместе с конфигом nginx и, если используется Let's Encrypt, каталогом /etc/letsencrypt. Это тот же принцип, что описан в статье про бэкап конфигов на сервере — не полагайтесь на то, что certbot сам всё восстановит на новом IP без телодвижений.

Что бэкапить отдельно на стороне Nextcloud

Если Collabora интегрирован с Nextcloud через плагин richdocuments (стандартная связка для этого редактора), реальные документы, версии файлов и права доступа хранятся именно в Nextcloud. Отдельно от Collabora нужно бэкапить:

• data-директорию Nextcloud (сами файлы пользователей);
• базу данных (MySQL/MariaDB или PostgreSQL);
• config/config.php, включая параметры интеграции: richdocuments хранит URL Collabora в таблице oc_appconfig (appid = 'richdocuments', ключ wopi_url), а не в самом config.php, так что бэкап БД здесь обязателен, файлового конфига недостаточно.

Полный процесс бэкапа и восстановления самого Nextcloud уже разобран отдельно — см. бэкап и восстановление данных Nextcloud и, если разворачиваете с нуля, установку Nextcloud на VPS. Здесь важно другое: бэкапы Collabora и Nextcloud должны восстанавливаться синхронно. Восстановили только Nextcloud, а Collabora подняли с чистого конфига — WOPI-хост в базе Nextcloud будет указывать на старый URL или ключ проверки подписи не совпадёт, и документы будут выдавать ошибку загрузки при попытке открыть их в браузере.

Автоматизация: cron + restic с шифрованием и ротацией

Ручной tar раз в квартал — плохая стратегия, потому что именно накопленные вручную правки в coolwsd.xml чаще всего и теряются. Разумная схема — ежедневный снапшот конфигурации в зашифрованный репозиторий restic на отдельном сервере (не на том же VPS, где крутится сам Collabora):

# на сервере с Collabora
export RESTIC_REPOSITORY=sftp:backup-user@backup-host:/srv/restic/collabora
export RESTIC_PASSWORD_FILE=/root/.restic-collabora-pass

restic backup /etc/coolwsd /root/collabora-stack --tag collabora
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Строка в cron:

15 3 * * * /usr/local/bin/restic-collabora-backup.sh >> /var/log/restic-collabora.log 2>&1

Подробный разбор установки и тонкостей restic — в статье restic на Ubuntu 24.04: пошаговая установка; там же объяснение, почему пароль репозитория нельзя хранить рядом с самим репозиторием. Если сравниваете инструменты для этой роли — есть отдельный разбор restic или BorgBackup: что выгоднее и когда.

Для бэкапа Nextcloud-стороны (БД + data) используйте отдельное задание с другим окном — база меняется постоянно, конфиг Collabora почти никогда, смешивать их в один снапшот неудобно при восстановлении по частям.

Восстановление на новом сервере — пошагово

1. Поднимите Docker на новом VPS (если сервер чистый — конкретные команды под дистрибутив есть в статье автоматические бэкапы с нуля на Ubuntu 24.04, там же логика организации бэкапной инфраструктуры).
2. Восстановите конфиг из restic:

   restic restore latest --target /restore-tmp
   cp -r /restore-tmp/etc/coolwsd/* /etc/coolwsd/

1. Разверните docker-compose.yml и .env из бэкапа, поднимите контейнер: docker compose up -d.
2. Проверьте, что домен в coolwsd.xml (domain=) и в переменных окружения соответствует новому адресу — если IP или домен сменились, старое значение приведёт к отказу WOPI-запросов.
3. Восстановите Nextcloud (БД + data) — обязательно до того, как переключать пользователей на новый Collabora, иначе первые открытия документов будут падать с ошибками.
4. Зайдите в Nextcloud → «Параметры» → «Office» (richdocoments) и заново укажите URL Collabora, даже если он визуально не изменился — форма пересохраняет значение в БД и форсирует повторную проверку соединения.
5. Откройте тестовый документ и одновременно смотрите логи: docker logs -f collabora. Ошибки вида WOPI host is not trusted означают, что домен Nextcloud не попал в allowlist coolwsd.xml; Proof key verification failed — не совпадает пара ключей, нужно либо восстановить оригинальный proof_key, либо обновить публичный ключ в Nextcloud.
6. Дайте связке поработать полдня под реальной нагрузкой перед тем, как выключать старый сервер — часть проблем (истечение сессий, кэш браузера пользователей) проявляется не сразу.

Честный нюанс: если между бэкапом и восстановлением вышла новая мажорная версия образа collabora/code, конфиг может частично не подойти — в changelog Collabora иногда меняют формат отдельных секций coolwsd.xml. Проверяйте diff между вашим файлом и coolwsd.xml.example из нового образа перед тем, как накатывать старый конфиг поверх.

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