Переход на отечественный стек сместил вопрос отказоустойчивости из плоскости «купить вендорскую коробку» в плоскость «собрать и проверить самим». Astra Linux, РЕД ОС, Postgres Pro, отечественные гипервизоры и СХД дают все нужные кирпичи, но архитектуру надёжности придётся проектировать руками. Ниже – что мы закладываем в проекты для бизнеса и госсектора, чтобы система пережила отказ узла, диска или площадки.

Начните с RPO и RTO, а не с инструментов

Прежде чем выбирать утилиту бэкапа, зафиксируйте два числа по каждой системе. RPO – сколько данных вы готовы потерять (15 минут, час, сутки). RTO – за какое время сервис обязан вернуться в строй. Эти цифры диктуют всё остальное: суточный дамп Postgres Pro даёт RPO в сутки, а непрерывная архивация WAL с PITR опускает его до минут. Не усредняйте требования по всему ландшафту – биллинг и внутренняя вики живут по разным правилам.

Для СУБД мы комбинируем три уровня: логические дампы pg_dump для переноса и точечного восстановления схем, физические бэказы через pg_basebackup или pg_probackup для быстрого подъёма экземпляра целиком и архив WAL для восстановления на любой момент. pg_probackup от Postgres Pro закрывает инкрементальные копии и проверку целостности – это рабочая замена привычным проприетарным агентам.

Репликация и кластеризация без зарубежных лицензий

Резервная копия защищает от потери данных, но не обеспечивает доступность. Для этого нужна репликация. Потоковая репликация Postgres держит горячую реплику в другой стойке или ЦОД, а автоматический переключатель – Patroni поверх etcd или Consul – выполняет failover за секунды и исключает split-brain. Виртуализацию строим на отечественных платформах с живой миграцией и HA-кластером: при отказе хоста ВМ перезапускаются на соседнем узле.

Хранилища дублируем по схеме 3-2-1: три копии, два носителя, одна вне площадки. Объектное хранилище с поддержкой S3-API позволяет складывать бэкапы на независимый кластер и шифровать их по ГОСТ. Отдельно резервируем конфигурации и сами пайплайны: инфраструктуру описываем как код, а интеграционные потоки версионируем – мы подробно разбирали это в материале про оркестрацию интеграций. Восстановить узел из Git-репозитория за полчаса надёжнее, чем вспоминать настройки руками.

Проверяйте восстановление, а не существование бэкапа

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

Отдельное внимание – нестандартным нагрузкам. ML-сервисы хранят не только данные, но и веса моделей, векторные индексы и обучающие выборки. Их тоже нужно версионировать и резервировать: потеря дообученной модели обходится в недели работы, о чём мы писали в разборах RAG и дообучения и выбора отечественной LLM.

Вывод

Отказоустойчивость на российском стеке – это не один продукт, а дисциплина: измеримые RPO/RTO, многоуровневые бэкапы, репликация с автоматическим failover и регулярная проверка восстановления. Все компоненты доступны в реестре отечественного ПО уже сейчас. Дальше остаётся спроектировать и внедрить такую схему под конкретный ландшафт и требования регулятора.