На карте
8 октября 2026 года инцидент в дата-центре Яндекса в Сасово сделал недоступной одну из зон Yandex Cloud. Последствия почувствовали пользователи сторонних сервисов: у «Астрала» возникли перебои с электронной отчётностью, ЭДО и электронными перевозочными документами. Хронология Yandex Cloud, официальное письмо «Астрала».
Покупая облако у крупной компании, легко принять её надёжность за гарантию сохранности своего проекта. Но сервер всё равно находится в конкретном здании, которому нужны электричество и связь. Сбои бывают и у мировых гигантов: в октябре 2025 года проблема с DynamoDB вызвала цепочку отказов других сервисов AWS. Разбор AWS.
Для человека, который сделал сайт, бота или ИИ-агента для компании, такой сбой может остановить всю работу. Если единственная копия данных будет утрачена, восстановление может оказаться невозможным. Я бы начал подготовку с простого вопроса: из чего и где мы восстановим проект, если основная площадка станет недоступна?
Начните с двух чисел
Запишите, сколько времени проект может простаивать и за какой период допустимо потерять изменения. Например: пережить два часа без сайта и восстановить данные с отставанием не больше часа.
От этих требований зависят частота копирования и устройство резерва. Ежедневная копия может оставить вас без изменений почти за сутки. Для личного сайта это иногда приемлемо; для клиентских заказов последствия будут другими.
Если простой останавливает продажи, понадобится подготовленная запасная площадка. Если пауза допустима, можно начать с независимых копий и инструкции восстановления.
Сохраните всё, из чего собран проект
Составьте короткий список того, без чего система не заработает:
- база данных: клиенты, заказы, история операций;
- загруженные файлы и документы;
- код, настройки, версии программ и зависимостей;
- инструкции и база знаний агентов, расписания и состояние незавершённых задач.
Код в Git не заменяет копию рабочей базы. Сохранённый промпт тоже не восстановит агента вместе с его знаниями и историей.
Пароли, ключи шифрования и резервные коды входа храните в защищённом месте, доступном без основного сервера. Отметьте внешние зависимости: вход в систему, DNS (связь домена с сервером), поставщика модели для агента. Запасной сервер не устранит сбой у этого поставщика.
У готового онлайн-сервиса выясните условия копирования и восстановления, проверьте выгрузку данных и продумайте временный порядок работы. Закрытый сервис может быть невозможно самостоятельно перенести на другой сервер.
Бэкап и зеркало решают разные задачи
Эти меры полезно различать.
| Мера | Что она даёт | Что ещё нужно учесть |
| Резервная копия с историей | Возврат к сохранённому состоянию данных | Для запуска ещё нужны программа, настройки и площадка |
| Реплика или зеркало | Копия данных для продолжения работы при отказе основной | Ошибка или удаление могут распространиться на копию |
| Подготовленная запасная площадка | Место и порядок запуска проекта | Нужны пригодные данные и проверка всего сценария |
Зеркало дополняют историей резервных копий. Два сервера с одной общей базой всё ещё зависят от её доступности. Эти различия разобраны и в руководстве AWS по аварийному восстановлению.
Минимальная подготовка без отдельного ИТ-отдела
1. Включите автоматическое копирование. Выберите расписание по допустимой потере данных. Для базы используйте штатный способ резервного копирования: копия её файлов во время записи может оказаться непригодной. Пояснение в документации PostgreSQL.
2. Вынесите копию за пределы основной площадки. Проверьте физическое размещение: разные названия услуг ещё не означают разные дата-центры. Для защиты от отказа провайдера полезна копия за пределами его инфраструктуры.
3. Сохраняйте историю и защищайте резерв. Единственная копия может перезаписаться повреждёнными данными. Для важных проектов предусмотрите офлайн- или неизменяемую копию. Ограничьте возможность удалить резерв с рабочего сервера; включите уведомления об ошибках копирования. Рекомендации CISA.
4. Запишите порядок запуска. Где взять копию, что установить, как восстановить данные, подключить доступы, переключить домен. Проверьте совместимость с запасной площадкой. Для облачных сервисов перенос может требовать экспорта данных и изменения настроек.
5. Проверьте восстановление в отдельном окружении. Перед запуском отключите тестовую копию от реальных рассылок и оплат. Затем откройте нужный документ или выполните тестовую задачу агента. Замерьте время восстановления и запишите, чего не хватило.
У Yandex Cloud во время инцидента возникали ограничения на создание ресурсов и в других зонах. План «если что, быстро арендуем сервер» тоже нуждается в проверке. Запасное место и доступ к нему лучше подготовить заранее.
Как это устроено у меня
У меня система разнесена по разным машинам. Сайт мы уже отдаём с нескольких VPS (арендованных виртуальных серверов). Резервные копии я храню в том числе дома на Synology, сетевом хранилище (NAS).
Мне важно, чтобы после отказа площадки оставались данные для восстановления. Домашнему NAS тоже нужна защита от потери данных. А возможность хранить на нём данные компании зависит от требований к их обработке.
Резерв можно разместить внутри России
Совет «скопируйте всё в зарубежное облако» подходит не каждому проекту. Код сайта и клиентская база с персональными данными требуют разного подхода.
При сборе персональных данных граждан России закон запрещает записывать, хранить и выполнять ряд других операций с ними в зарубежных базах, кроме установленных исключений. Трансграничная передача регулируется отдельно и требует выполнения установленных условий, включая уведомление Роскомнадзора. Статья 18, статья 12 закона № 152-ФЗ.
Резерв можно организовать на независимых площадках внутри России: в разных дата-центрах, при необходимости у разных провайдеров. Требования к защите данных, договорам и доступу сохраняются; шифрование копии их не отменяет. Схему для клиентской базы проверьте с ответственным за персональные данные.
Что проверить сегодня
Выберите один важный проект. Найдите последнюю успешную копию, откройте её без основного сервера и попробуйте восстановить рабочий сценарий. Начать можно с одного документа или тестовой задачи; затем проверить весь проект.
Если авария уже произошла, сверяйтесь со статусом поставщика, сохраните доступные данные и сообщите пользователям о ситуации. При восстановлении агентов проверьте незавершённые операции: повторный запуск не должен дублировать уже отправленные сообщения или оформленные заказы.
Такая проверка покажет, чего вам не хватает для восстановления, пока есть время это исправить.
Следующий шаг
Правило 3-2-1: рабочая схема резервного копирования — подробный разбор независимых копий, истории хранения и проверки восстановления.
Если у вас небольшой проект и пока неясно, что сохранять и как возвращать его в работу, эту схему можно разобрать применительно к вашим данным и ограничениям.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
