Документация Резервное копирование и восстановление

Резервное копирование и восстановление

Это руководство показывает, как сделать резервную копию, из которой можно
заново собрать узел Mockarty, как её проверить и как восстановить после сбоя.

Что нужно защищать

Что Где хранится Как копируется
База данных PostgreSQL или файл SQLite mockarty --backup (ниже) или плановые копии в панели администратора
Сохранённые файлы: вложения, файлы отчётов Папка на диске или объектное хранилище mockarty --backup включает папку; бакет объектного хранилища копируйте средствами самого хранилища (версионирование или зеркалирование)
Ключи шифрования Ваше хранилище секретов Храните сами — в резервную копию они никогда не попадают
Конфигурация Переменные окружения, файлы Compose или values Helm Храните в системе контроля версий

Ключи шифрования — это MOCKARTY_PII_ENCRYPTION_KEY, MOCKARTY_PII_HMAC_PEPPER
и CHAOS_ENCRYPTION_KEY, если вы их используете. Данные, записанные с ключом,
читаются только тем же ключом: база, восстановленная без своих ключей, теряет
все зашифрованные значения. Храните каждую версию ключа с датой её ввода, чтобы
сопоставить её с резервной копией. После смены ключа держите прежний ключ в
MOCKARTY_PII_ENCRYPTION_KEY_PREVIOUS на узле, куда восстанавливаете, пока смена
не завершена: копия, сделанная раньше, всё ещё нуждается в нём, и восстановление
назовёт его, если его нет. Задайте CHAOS_ENCRYPTION_KEY до того, как делать
резервные копии: без него сохранённые учётные данные хаос-кластеров привязаны к
исходному подключению к базе, и восстановление на другой сервер баз данных
сообщит, что ключ учётных данных хаос-кластеров другой. Чтобы восстановить всё
равно, добавьте --restore-ignore-key-mismatch, а после подключите
хаос-кластеры заново.

Два вида резервных копий

  • Плановые копии в Панель администратора > Backup копируют
    базу, пока Mockarty работает. Используйте их для повседневной защиты от
    ошибок. См. Руководство администратора.
  • Полная копия узла командой mockarty --backup забирает базу и
    сохранённые файлы в одну папку с манифестом, который закрепляет каждый файл
    контрольной суммой и записывает, какими ключами шифрования были записаны
    данные. Используйте её для аварийного восстановления: потерянный сервер,
    сломанный диск, переезд на новое оборудование.

Полная резервная копия

Запустите бинарник Mockarty с теми же настройками, что у сервера (DB_USE,
DB_DSN, MOCKARTY_BLOB_BACKEND, MOCKARTY_BLOB_FS_ROOT и ключи), и укажите
новую пустую папку:

mockarty --backup /backups/mockarty-2026-09-26

Backup written to /backups/mockarty-2026-09-26: pg database at schema version 438.
Stored files (attachments, reports): 1204, included.
Encryption keys are not in the backup. Keep them, from the same moment, in your secret store: a restore needs the same keys.

Копия согласована, даже пока Mockarty продолжает работать: для PostgreSQL
используется pg_dump, для SQLite — транзакционный снимок. Для копий
PostgreSQL на машине, где выполняется команда, нужны клиентские утилиты
PostgreSQL (pg_dump, pg_restore) той же основной версии, что и сервер, или
новее — в официальном образе Mockarty они уже есть. В Kubernetes выполните
команду внутри пода администрирования и пишите на подключённый том:

kubectl exec deploy/mockarty -- /app/mockarty --backup /app/data/backups/2026-09-26

В папке будут manifest.json, база (database.dump или database.sqlite) и,
при файловом хранилище, blobs.tar.gz. Скопируйте всю папку в хранилище за
пределами сервера.

Проверка копии

Непроверенная копия — это надежда, а не копия. Проверяйте каждую после
переноса и время от времени восстанавливайте одну на запасной узел:

mockarty --verify-backup /backups/mockarty-2026-09-26

Проверка не проходит, если какой-либо файл отсутствует, изменён или лишний; для
SQLite дополнительно выполняется встроенная проверка целостности базы.

Восстановление после сбоя

  1. Подготовьте узел: тот же релиз Mockarty, что и у копии, или новее, те же
    ключи шифрования и настройки базы и файлового хранилища, которые он будет
    использовать. Для PostgreSQL создайте пустую базу.

  2. Остановите Mockarty на этом узле.

  3. Восстановите:

    mockarty --restore /backups/mockarty-2026-09-26

  4. Запустите Mockarty. Если копия сделана более старым релизом, он применит
    изменения базы своего релиза.

  5. Откройте веб-интерфейс и проверьте недавние моки, тестовые прогоны и вложения.

Mockarty проверяет всё до того, как что-либо менять. Восстановление
отклоняется, если:

В сообщении сказано Что делать
копия не соответствует своему манифесту Копия повреждена. Используйте другую
pg_restore не может прочитать копию Установите клиентские утилиты PostgreSQL той же основной версии, что сервер, или новее, либо используйте другую копию
ключи шифрования отличаются Задайте ключи, с которыми делалась копия. --restore-ignore-key-mismatch восстановит всё равно, но зашифрованные значения останутся нечитаемыми
база новее, чем этот бинарник Установите релиз, которым сделана копия, или новее
в целевой базе уже есть таблицы Укажите в DB_DSN пустую базу или добавьте --restore-replace, чтобы заменить существующую
другой вид базы или файлового хранилища Восстанавливайте на узел того же вида (PostgreSQL или SQLite; папка или объектное хранилище)

Существующие файл базы SQLite и файловое хранилище не удаляются: восстановление
переносит их в сторону и показывает, где они лежат. Удалите их, когда узел
заработает.

Восстановление из одного файла копии (SQLite)

Плановые копии узла с SQLite в панели администратора — это отдельные файлы
базы. Скачайте файл, остановите Mockarty и восстановите так же:

mockarty --restore backup_daily_20260926_020000_4f1c2a.db

Один файл содержит только базу: вложений и файлов отчётов в нём нет, а ключи
шифрования проверить нельзя.

Перед обновлением

Делайте полную копию перед каждым обновлением. Если новый релиз придётся
откатить, а откат не сможет сохранить базу, эта копия — путь назад, см.
Обновление и откат.

Предыдущая
Лицензионная модель