Куда сохраняются бэкапы
Источник: OpsVault / portalwiki.world, сервер 37.114.63.11, приложение /opt/opsvault.
Получатель: сервер 169.255.57.42, SSH-порт 22. Зашифрованные копии restic находятся в /srv/backups/opsvault/restic.
Пароли и ключи здесь не публикуются. Конфигурация доступна root в /etc/opsvault-backup/ на обоих серверах. Ключ расшифровки repository.password нужно дополнительно сохранить в независимом защищённом хранилище владельца.
Что копируется
- Согласованный PostgreSQL dump OpsVault.
- Код и requirements.txt, .env с исходными VAULT_KEY/DJANGO_SECRET_KEY, media, private_uploads и постоянные файлы приложения.
- Конфигурации Nginx, PostgreSQL, Redis, сертификаты, systemd, cron, firewall, SSH-сервера и backup runner.
Виртуальные окружения, статика после сборки, старые локальные архивы, Git, кэш и *.log исключены. Redis с прежними заданиями не восстанавливается: перед включением workers надо сверить незавершённые операции.
Расписание и защита
Каждый час в :10 МСК, задержка до двух минут, независимый systemd timer opsvault-backup.timer. Дополнительная копия перед deploy включается после доставки изменения workflow; ошибка полной копии останавливает активацию.
Production подключается через отдельный SSH-ключ с разрешением только на туннель к приёмнику. Приёмник слушает localhost и работает в append-only: production не может удалить старые копии.
На сервере хранения каждые 15 минут проверяется свежесть (не старше двух часов) и свободное место (не менее 5 GiB). Ежедневно в 05:40 МСК выполняется полная проверка данных и затем ротация: 24 часовые, 30 дневных, 8 недельных, 12 месячных точек. История накапливается с момента включения.
Как проверить
На production: systemctl list-timers opsvault-backup.timer; sudo cat /var/lib/opsvault-backup/status.json. Успех означает status=success, непустые last_success_at и snapshot_id.
На 169.255.57.42: /var/lib/opsvault-backup/monitor.json и maintenance.json; список снимков restic. ID и время снимка должны совпасть с подтверждением на production. Активный timer сам по себе не доказывает наличие копии.
Восстановление
- Выбрать конкретный снимок, проверить restic check --read-data, восстановить его в новый пустой каталог.
- Подготовить изолированный сервер с совместимым PostgreSQL. Создать роль/пустую базу из DB-настроек .env; роли, пароли и ACL базы в dump не включены. Установить зависимости и восстановить файлы/права.
- Восстановить /var/lib/opsvault-backup/staging/postgres.dump через pg_restore --exit-on-error --no-owner --no-acl.
- Проверить пользователей, статьи, вложения и расшифровку контрольного доступа с исходным VAULT_KEY. До проверки оставить workers/Beat и внешние записи выключенными.
- Перед реальным запуском сверить незавершённые операции и состояние внешних сервисов; запустить пустой Redis, затем web/workers и один Beat. Зафиксировать время восстановления и фактическую потерю данных.
Ограничения и следующие этапы
Пока защищён OpsVault, а не весь контур: Binom, лендинги, OpsBot и остальные серверы требуют отдельного подключения. База и файлы копируются онлайн без единого атомарного снимка. Потеря данных до 15 минут не обеспечивается: для неё нужны WAL/PITR. Полное восстановление web на чистом сервере пока не подтверждено.
Контроль ошибок пишет status/systemd journal; уведомления в Telegram/email ещё не подключены. Дополнительная offline/immutable копия и независимое хранение ключа остаются отдельными этапами.
Полная инструкция, команды и источники в репозитории.
Живая проверка 5 октября 2026
Удалённый снимок 195df77a проверен и восстановлен в изолированный PostgreSQL 16 без сети. Подтверждены восстановление таблиц, совпадение хэша dump, восстановление файлов и расшифровка контрольного доступа без вывода секрета. Это проверка базы и файлов, не полного запуска web.