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

Резервные копии

Редакция 24 сентября 2026, дополнена 9 ноября 2026

Для администратораНастраивается один раз, проверяется регулярно

Копия снимается по расписанию со всех хранилищ сразу, а архив секретов в ней шифруется. Отдельно и тоже по расписанию платформа проверяет целостность этой копии, то есть описание копии, контрольные суммы файлов и то, что копия снята с вашей платформы. Саму копию платформа при этом не разворачивает. Копия, которую ни разу не разворачивали, копией не считается.

Что попадает в копию

• Основная база. Организации, сотрудники, автоматизации, дела, очереди, журнал действий.
• Файлы. Загруженные документы, выгрузки и результаты запусков из объектного хранилища.
• Записи хода запусков. По ним потом разбирают, что происходило.
• Конфигурация платформы. Тот самый собранный слепок, по которому поднимаются сервисы.

Пароли и ключи служб входят в копию отдельным архивом секретов. Архив шифруется ключом, имя которого названо в описателе, а значение лежит в хранилище секретов. Потеря ключа означает потерю архива секретов. Расшифровать архив без ключа нельзя, и это свойство шифрования, а не оговорка.

Чего в копии нет

Знать это так же важно, как знать состав копии, потому что от этого зависит, что придется восстанавливать руками.

• Образов платформы. Они приезжают поставкой и восстанавливаются установкой нужной версии, а не из копии.
• Секретов в открытом виде. Пароли и ключи входят в копию только зашифрованным архивом.
• Ключа шифрования самой копии. Класть ключ рядом с зашифрованными данными бессмысленно.
• Ваших систем. Все, что автоматизация записала в вашу учетную систему, живет там и восстанавливается ее средствами.

Расписание и хранение

Все значения задаются вашим слоем описателя. Режим с возможностью вернуться на момент времени обязателен для промышленного и закрытого профилей. Простой ночной снимок допустим только для показного, потому что у него нет точки возврата внутри суток.

Шифрование копий

Архив секретов в копии шифруется ключом, который лежит в секретах платформы отдельно от самих копий. Шифруется только архив секретов. База, файлы, записи хода запусков и конфигурация лежат в копии без шифрования ключом копий. Ключ задается при развертывании, и у него простое, но неприятное свойство.

Второй экземпляр ключа стоит завести до первой копии, а не после первого инцидента. Проверить, что ключ рабочий, можно тем же способом, что и копии, то есть восстановлением на отдельном сервере.

Окно возврата на точку времени

База данных копируется в режиме, который позволяет вернуться не только на момент ночной копии, но и на произвольный момент внутри окна. Окно по умолчанию тридцать суток.

Держится оно на непрерывном архиве журнала базы. Если архив перестал пополняться, окно начинает сжиматься, и платформа предупреждает об этом отдельным оповещением про возраст архива. Это оповещение критическое именно потому, что копии при этом продолжают сниматься и внешне все выглядит нормально.

Проверка целостности копии

По расписанию платформа берет последнюю копию и проверяет ее целостность, то есть описание копии, контрольные суммы файлов и то, что копия снята с вашей платформы. Разворачивание копии в отдельное место ради проверки не выполняется. У копии, которую ни разу не разворачивали, шанс оказаться нерабочей заметно выше нуля, поэтому на деле копию проверяют восстановлением на отдельном сервере.

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

Если проверка давно не делалась, платформа сообщает об этом отдельным оповещением. Молчание здесь опаснее отказа.

Восстановление

Восстановление запускается командой с указанием копии. Платформа сначала проверяет описание копии, а именно подпись, состав и суммы. Недоверенное описание отклоняется до распаковки.

bm-deploy restore --backup-id <номер копии>

Восстановление стирает текущее состояние, поэтому требует явного подтверждения. Команда без подтверждения возвращает код, который прямо говорит, что не хватает согласия на опасное действие, и ничего не делает.

Порядок восстановления на новом сервере такой.

1. Поднять сервер и поставить ту же версию платформы

   Копия не несет образов. Версия должна совпадать с той, на которой копия снималась, иначе схема данных не сойдется с кодом.

2. Положить ключ шифрования копий в секреты

   Без него дальше идти некуда, и это выяснится на первом же шаге распаковки.

3. Принести копию и запустить восстановление

   Платформа проверит описание копии до распаковки и откажет на недоверенном, ничего не развернув.

4. Проверить, что все части поднялись

   Экран обзора платформы и экран миграций. Непримененные изменения схемы означают, что восстановление прошло не до конца.

5. Проверить автоматизации

   Настройка автоматизаций, состояние каждой. Подключения к вашим системам могут требовать новых учетных данных, если старые отозваны вместе со сервером.

Три случая, когда копия нужна

Ради третьего случая план перехода и называет необратимые шаги до начала работы, а платформа требует подтвержденную копию. Подробнее об этом на странице обновления и отката.

Копии при установке в кластер

Выше описана платформа на одном сервере. Если платформа стоит в кластере Kubernetes (так называют несколько серверов под общим управлением), копии снимаются и восстанавливаются другим способом. Снятие копии и восстановление установки проверено на кластере RKE2. RKE2 - это сборка Kubernetes проекта Rancher. Для других сборок Kubernetes проверка и возможные доработки - отдельная работа по заказу.

Установку в кластер и работу с копиями в нем ведет БизнесМатика по проекту. Команда восстановления, описанная выше, на кластер не распространяется. В кластере копию снимает и восстанавливает инженер БизнесМатики своими средствами.

Что входит в копию

Копия кластера снимается по частям. Затем собирается манифест - запись о копии всей установки. В ней названы все части копии, время снятия и контрольные суммы малых служебных файлов. В копию входят:

• Основная база (PostgreSQL). Базовую копию снимают с реплики (запасного экземпляра базы), чтобы не нагружать рабочий экземпляр. Рядом в хранилище копий непрерывно архивируется журнал изменений базы, поэтому базу можно вернуть на выбранный момент.
• Записи хода запусков и журнал аудита (ClickHouse). Копию снимают с одной из двух реплик.
• Файлы (MinIO). Документы, файлы автоматизаций и моделей, материалы базы знаний, вложения чата и якоря журнала аудита. В копию идут все версии каждого объекта, в том числе прежние, и отметки об удалении.
• Сведения об установке. Идентификатор, лицензия, перечень служб с версиями образов и размерами дисков.
• Секреты. Пароли и ключи служб одним зашифрованным архивом.

Где лежат копии

Копии лежат в хранилище копий. Это отдельное пространство имен (изолированная область кластера) с собственным экземпляром MinIO на собственном диске. Хранилище не принадлежит установке, поэтому копии переживают ее снятие, и из них можно восстановить установку в пустое пространство. Хранилище заводится до установки платформы. Если его не было, журнал PostgreSQL не архивируется, а копии ClickHouse не снимаются.

Границы хранилища копий:

• Оно находится в том же кластере и на тех же серверах. Если кластер потерян целиком, копии теряются вместе с ним.
• Оно работает в одном экземпляре на одном диске.
• Копирования во внешнее хранилище в этой поставке нет.
• Размер хранилища задается при его заведении, по умолчанию 20 ГиБ на все копии в нем.
• База PostgreSQL размером больше 4 ГиБ в копию не берется, потому что хранилище принимает файл копии одним запросом. Копия в этом случае не снимается, и операция называет причину.

Как часто снимается копия и сколько она хранится

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

Как шифруется копия

Шифруется только архив секретов. Его шифрует ключ копий до того, как архив попадет в хранилище. База, журнал базы, данные ClickHouse и файлы MinIO лежат в хранилище копий в открытом виде. Защищает их только ограничение доступа. К хранилищу копий обращаются только службы платформы, помеченные для копирования.

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

Что не входит в копию

• Redis. Это быстрое хранилище в памяти, в котором платформа держит счетчики лимитов и бюджетов и шину событий. После восстановления Redis пуст. Счетчики лимитов запросов начинаются с нуля. Счетчики бюджетов моделей платформа восстанавливает из последнего снимка в базе, поэтому теряется расход после этого снимка. События шины, не доставленные на момент копии, пропадают.
• Образы платформы. Они поставляются отдельно от копии. При восстановлении версия образов должна совпадать с версией копии, иначе операция отказывает до начала работ.

Как восстанавливают

Восстановление ведет инженер БизнесМатики. Установка целиком восстанавливается в пустое пространство имен, то есть в то, где она стояла до снятия, или в другое. Если пространство занято, операция отказывает и ничего не удаляет. Порядок такой:

1. Перед изменениями платформа проверяет, что части копии на месте. Малые служебные файлы сверяются по контрольной сумме и размеру, файлы базовой копии PostgreSQL - по наличию и размеру.
2. Восстанавливаются сведения об установке и секреты, затем PostgreSQL, MinIO и ClickHouse. После этого службы запускаются поверх восстановленных данных.
3. В конце платформа сверяет восстановленную установку и печатает отчет о том, что сошлось, что нет и что проверить не удалось.

PostgreSQL возвращается на момент копии или на последнюю запись журнала, которая успела попасть в хранилище копий. Только базу PostgreSQL можно вернуть и на выбранный момент внутри журнала, это отдельная операция. MinIO возвращается на момент окончания базовой копии PostgreSQL, ClickHouse - на момент своей копии.

Восстановленная установка получает тот же идентификатор и ту же лицензию, что исходная. Две работающие установки с одним идентификатором недопустимы.

В поставке для кластера копии не проверяются по расписанию и не разворачиваются ради проверки. Восстановление в пустое пространство с итоговым отчетом сверки - способ проверить копию на деле.