Бэкап был, восстановить негде: что показала осень 2026 и как устроен теплый резерв

Октябрьская авария проверила планы восстановления у клиентов пострадавших дата-центров. Среди компаний, которые обратились к нам в эти дни, у одних плана не было, у других копии лежали рядом с рабочими серверами. Эта статья для собственников, которым важна непрерывная работа бизнеса, но которые не готовы погружаться в технические детали. Разберу базовые вещи, без которых не принять решение о резерве: почему запасной дата-центр того же провайдера не всегда спасает, чем теплый резерв отличается от бэкапа и какие семь вопросов задать ИТ-отделу. Настройку резерва потом возьмут на себя ИТ-специалисты.
Привет, на связи Авдей Мартынович, руководитель подразделения по работе с СМБ в ALP ITSM. До ALP я был ИТ-директором региональной компании, теперь моя команда сопровождает ИТ таких же компаний.
Что авария значит для клиентов облака
В октябре атаки беспилотников вывели из строя три дата-центра Яндекса. Сроки восстановления оборудования провайдер пока не называет.
Атаки теперь в перечне форс-мажора. В редакции пользовательского соглашения Яндекса от 10 октября атаки с применением БПЛА и ракет относятся к форс-мажорным обстоятельствам. Если аварию признают форс-мажором, убытки от простоя несет сам клиент. Плату за облако провайдер отменил: с 8 по 31 октября сервисы Yandex Cloud бесплатны для текущих клиентов, но потерянную выручку это не возвращает.
Ремонт затянется. Поставка оборудования для замены занимает до полугода, а в четвертом квартале один из производителей электроники ждет роста цен из-за дефицита («Коммерсантъ»). Серверы и системы хранения данных за несколько дней уже подорожали на 10–15%, по аналитике, которую приводит «Фонтанка».
В первом полугодии 2026 года у Yandex Cloud было около 64 000 клиентов. Если авария задела хотя бы один процент из них, это уже сотни компаний, которым пришлось на деле проверить свой план восстановления.
Копии были, развернуть было негде
Вот случай одной из них.
Сайты и часть инфраструктуры компании работали в облаке во Владимире. Там же лежали резервные копии, там же оказалась и запасная копия серверов — в соседнем дата-центре того же провайдера. У каждой владимирской площадки своя инженерная инфраструктура, но стоят они рядом.
Провайдер ответил, что восстановить ресурсы на месте нельзя, и предложил переезд. Обычно подъем из копий занимает несколько дней, но в период, когда мощности одновременно ищут многие клиенты, может растянуться на недели: найти площадку, развернуть серверы, перенести данные, проверить запуск.
Запасные копии отключились вместе с системами, которые должны были их защищать. Бизнес не остановился только потому, что учетная система работала на другой площадке. Сейчас резерв переносят к независимому провайдеру в другом регионе.
Сценарий не новый. В марте 2021 года во французском Страсбурге сгорел дата-центр OVHcloud, и у части клиентов резервные копии хранились в том же дата-центре, что и рабочие серверы. В 2023 году коммерческий суд Лилля обязал провайдера выплатить двум таким клиентам 100 и 150 тысяч евро (провайдер обжаловал, и в 2025 году апелляционный суд снизил выплату одному из клиентов до 1 800 евро). Данные клиентов эти деньги не вернули.
Запасные копии спасают, только: а) если лежат на другой площадке и б) там есть мощности, чтобы их развернуть.
Чем бэкап отличается от теплого резерва и двух площадок
Я бы начинал выбор способа резервирования с двух вопросов: как быстро система должна вернуться в работу и период, данные которого бизнес готов потерять.
Подход | Что лежит на второй площадке | Время восстановления | Потеря данных | Кому подходит |
Резервное копирование | Только копии данных | Дни: найти мощности, развернуть, проверить | С последней копии, часто сутки | Системам, без которых можно прожить несколько дней |
Теплый резерв | Копии серверов, бизнес-данные постоянно обновляются, серверы выключены до аварии | Часы: включить серверы по готовому сценарию | Последние минуты до аварии | Учетным системам, складу, сайту, которые не могут стоять дольше дня |
Две рабочие площадки | Полная копия, обе площадки работают одновременно | Минуты | Почти ноль | Тем, кто не может остановиться и на час |
Бэкап похож на запасное колесо в багажнике, а теплый резерв — на запасную машину с полным баком в гараже в другом районе: уехать на ней можно в тот же день, но ее нужно время от времени заводить.
Для малого и среднего бизнеса я считаю теплый резерв разумной серединой. Он заметно дешевле второй рабочей площадки, а простой сокращает с нескольких дней до нескольких часов.
Почему запасной дата-центр того же провайдера не всегда спасает
На первый взгляд запасная копия в соседнем дата-центре того же провайдера надежна. И она правда спасает, если в одном здании отказали оборудование, питание или сеть.
Дата-центры одного провайдера связаны общим управлением, правилами и часто географией, поэтому при аварии сразу на нескольких площадках запасной может пострадать вместе с основным. В октябре провайдер сам советовал клиентам задействовать любые доступные планы восстановления, не ограничиваясь переключением между его дата-центрами.
Даже там, где запасная копия в соседнем дата-центре сработала, поднять новые серверы было трудно: провайдер приостановил выдачу дополнительных ресурсов.
Поэтому у резервной площадки я бы проверял две вещи:
Другой провайдер. Иначе резерв упрется в те же ограничения на выдачу ресурсов, что и основная площадка.
Другой регион. Резерв в соседней области может попасть под то же событие, поэтому регион выбирают так же внимательно, как провайдера. Искать его стоит внутри страны: запись и хранение персональных данных граждан России закон требует вести в базах данных на территории страны (ч. 5 ст. 18 152-ФЗ).
Переезжать целиком не нужно. Основная площадка остается там, где удобно, а в другом месте готовят только запасную инфраструктуру.
Как устроен теплый резерв
1. Копирование. Серверы компании постоянно копируются на резервную площадку с отставанием в несколько минут.
2. Режим ожидания. Пока все в порядке, запасные серверы выключены, а компания оплачивает только хранение копий.
3. Переключение. При аварии администраторы включают запасные серверы по готовому сценарию, и сотрудники продолжают работать уже на резервной площадке.
Сложнее всего здесь само переключение. Серверы запускают в строгом порядке, сотрудникам нужен доступ к резерву, а банк, маркетплейсы и оператор электронного документооборота должны узнать новый адрес. Поэтому сценарий записывают пошаговой инструкцией и проверяют тестом.
Как составить План аварийного восстановления и о чем спросить ИТ-отдел, пока все работает, мы разбирали в отдельной статье.
Теплый резерв защищает только системы, которыми управляет сама компания: учетную систему, склад, сайт и файлы. Облачную CRM, телефонию и внешнюю почту он не спасет: для их данных нужны отдельные копии, а для внешних сервисов вроде отчетности стоит заранее продумать запасной канал.
Это было видно по сервисам 1С. Сервер 1С:Хаб, через который 1С-ЭДО связывается с операторами, тоже стоял в дата-центре Яндекса. Перебои в 1С-ЭДО и 1С-Отчетности начались 11 октября. Отчетность, кроме обмена с СЭДО СФР, восстановили поздно вечером 16 октября, обмен в 1С-ЭДО через оператора «Калуга Астрал» — 17 октября, полностью сервисы заработали 20 октября. Своя 1С на резерве в эти дни работала бы, а отправка отчетов и документов все равно зависела бы от чужой инфраструктуры.
Зачем проверять резерв
Как показывает наш опыт, первый тест переключения почти никогда не проходит гладко. Выясняется, что программа стартует раньше базы данных, в ярлыке бухгалтерии зашит старый адрес, а пароль к резервному VPN знает один человек.
Тест проводят в отдельном от рабочей системы контуре, поэтому процессы в компании не прерываются. Критерий успеха: главный бухгалтер сформировал в резервной базе оборотно-сальдовую ведомость, а кладовщик провел тестовую отгрузку. Время переключения из протокола испытаний и есть реальное время восстановления, какой бы норматив ни стоял в договоре.
Сценарий теста лучше брать неудобный. Как пишет Хабр со ссылкой на Яндекс, октябрьский сбой оказался серьезнее сценария потери одного дата-центра, который компания регулярно отрабатывала на учениях.
Инфраструктура меняется, поэтому восстановление из резерва проверяют регулярно: для критичных систем небольшой компании раз в квартал или в полгода.
Семь вопросов, чтобы оценить свою защиту
Задайте их своему ИТ-специалисту или подрядчику. Если на какой-то вопрос он отвечает неуверенно, с него и начинайте реформу резервирования.
1. Где физически лежат резервные копии? Хорошо, если на другой площадке, у другого провайдера и в другом регионе. Если слышите «в том же облаке» или «на соседнем диске», при большой аварии копии можно потерять вместе с серверами.
2. Компания хранит только копии данных или готовые копии серверов на резервной площадке? С копиями файлов и баз 1С развертывание займет несколько дней. С готовыми серверами обычно хватает нескольких часов, если сценарий переключения проверен тестами.
3. Куда восстанавливаться, если площадка недоступна целиком? Нужна заранее подготовленная резервная площадка. Ответы «купим новый сервер» или «переедем, когда понадобится» значат, что ее нет, а поиск и аренда при аварии основной займут несколько дней.
4. Когда компания последний раз переключалась на резерв? Правильный ответ содержит дату теста и фактическое время выхода на рабочий режим по протоколу. А «бэкапы делаются каждую ночь, ошибок нет» — уже повод насторожиться.
5. Кто нажимает кнопку восстановления и кто заменит нажимающего кнопку, если того нет на месте? Правильный ответ: сценарий записан, доступ к нему есть у нескольких человек. Если слышите «все знает наш админ», это плохой знак.
6. Что написано в договоре с провайдером про форс-мажор? Перечитайте этот пункт сами. Если атаки и другие внешние причины названы там форс-мажором, убытки от простоя по ним провайдер, скорее всего, не возместит.
7. Сколько стоит час простоя? Сложите выручку за час, зарплату простаивающих сотрудников и штрафы по договорам. Без этой цифры непонятно, сколько тратить на защиту.
Как считать, нужен ли резерв
Компании часто экономят на резервировании в надежде, что «прокатит и так». Проверить уровень риска проще всего цифрами, сравнив две суммы.
Первая: цену часа простоя умножаем на время восстановления без резерва. Из копий это несколько дней, а при массовой аварии неделя и больше.
Вторая: во сколько резервирование обходится за год. Сюда входят хранение копий, настройка, тесты и сопровождение.
Дальше первую сумму умножаем на вероятность аварии за год. Если резерв стоит меньше, он окупается. Если больше, достаточно бэкапа с проверенным восстановлением.
Считайте по сегодняшним ценам, а не по прошлогоднему прайсу: серверы, по оценке аналитика, уже подорожали на 10–15%, а в четвертом квартале возможен новый рост.
Для ориентира по рынку: в обзоре Uptime Institute по опросу 2025 года 57% респондентов по всему миру оценили последний серьезный сбой дороже 100 тысяч долларов, а каждый пятый — дороже миллиона. Опрашивали в основном крупные компании и операторов дата-центров. У небольшой компании суммы скромнее, так что считайте и оценивайте риски.
Что делать прямо сейчас
Ответьте на семь вопросов выше и посчитайте две суммы из предыдущего раздела. Решение о резерве принимает собственник, а не только ИТ-отдел. И держите в голове: если договор с провайдером относит определенные классы аварий к форс-мажору, убытки от простоя лягут на компанию.
Если ответы устраивают, назначьте дату следующего теста восстановления из резерва. Если нет, составьте список критичных систем, определите допустимый простой по каждой и решите, где будет резерв и какой это будет резерв. При допустимом простое в несколько дней хватит копий на другой площадке с проверенным восстановлением. Если же остановка учетной системы или склада дольше рабочего дня бьет по выручке, нужен теплый резерв у другого провайдера в другом регионе. Пока план не прошел тест, сколько на самом деле займет переключение, не скажет никто. Осень 2026 года это хорошо показала: копия данных сама по себе работу не возвращает. Нужны место, где ее развернуть, и проверенный порядок действий.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.