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

Одна потребность: платформа должна иметь явные политики резервного копирования и восстановления (частота, хранение, RPO/RTO), процедуры восстановления из бэкапа и их регулярную проверку, а не только UI для ручного экспорта/импорта.

Зачем это нужно (мировой опыт)

• Enterprise и регуляторика: требования к сохранности данных и к восстановлению после сбоя (RPO — сколько данных допустимо потерять, RTO — за какое время восстановить работу).
• AWS, GCP, Azure: рекомендуют автоматические бэкапы БД с retention policy, тесты восстановления, кросс-регион при необходимости.
• Low-Code платформы: конфигурация (модель, сценарии, настройки) — критичный актив; бэкапы домена и данных — стандартная функция, часто с расписанием и версиями.
• SRE: восстановление из бэкапа — часть runbook при потере данных или сбое деплоя.

Текущее состояние

• В приложении есть Backup/Restore для домена: экспорт в файл (bundle/plain), импорт с выбором сущностей (BackupRestore_Singleton, backup-restore.ts). Поддерживаются сущности: settings, project, type, query, component, action, parameter, filter, converter, integration, environment, tenant, bindings, policy, style, vocabs, page-template, page, navigation.
• Это ручной «сохранить/загрузить снимок»; нет зафиксированных политик: как часто делать бэкапы, где хранить, сколько хранить, кто и когда проверяет восстановление.
• Нет автоматического расписания бэкапов на бэкенде; нет разделения «бэкап конфигурации домена» и «бэкап данных приложения» (если они в разных хранилищах).
• Нет документированных RPO/RTO и процедур «восстановление из бэкапа за вчера» для операторов.

Что сделать

1. Политики бэкапов

• Частота: по средам (prod — ежедневно или чаще, staging — реже, dev — по необходимости). Зафиксировать в документации или в настройках платформы.
• Retention: сколько копий хранить (например, последние 7 дней + еженедельный снимок за месяц). Очистка старых по политике.
• Хранение: куда класть (объектное хранилище, отдельный диск, другой регион для disaster recovery). Шифрование и доступ по ролям.
• Объём: что именно бэкапить — снимок домена (конфигурация), снимок данных (Payload/БД приложения), оба; раздельно для быстрого восстановления только конфигурации или только данных.

2. Автоматизация на бэкенде

• Планировщик (cron, queue) для создания бэкапов по расписанию. Сохранение в настроенное хранилище с именем/тегом (дата, среда, тип).
• Опционально: API для ручного запуска бэкапа и для получения списка доступных бэкапов (для экрана восстановления).

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

• Документированная процедура: как выбрать точку восстановления, как восстановить домен и/или данные, в каком порядке (например, сначала конфигурация, потом данные), что делать после восстановления (проверка, инвалидация кэша).
• В UI админки: возможность выбора бэкапа из списка (если бэкенд отдаёт список) и запуск восстановления с подтверждением. Ограничение по ролям (только админ/оператор).
• Тесты восстановления: регулярно (раз в квартал или по регламенту) выполнять восстановление из бэкапа в тестовую среду и проверять работоспособность; фиксировать в runbook.

4. RPO и RTO

• Зафиксировать целевые RPO (например, «потеря не более 24 ч данных») и RTO («восстановление в течение 4 ч») для критичных сред.
• Подстроить частоту бэкапов и процедуры под эти цели; при необходимости добавить репликацию или транзакционные логи поверх бэкапов.

Риски и ограничения

• Автоматические бэкапы и хранение требуют ресурсов и мониторинга (место, сбои записи). Восстановление в prod — критичная операция; обязательно тестировать процедуру в тестовой среде. Связь с Versioning_And_Updates: снимки версий домена могут быть частью политики бэкапов.

Вывод

• Политики бэкапов: частота, retention, хранение, объём (домен vs данные).
• Автоматизация создания бэкапов на бэкенде по расписанию.
• Документированные процедуры восстановления и регулярные тесты восстановления.
• Явные RPO/RTO для enterprise и соответствия требованиям.