Как сохранить данные редакции при аварии в дата-центре: бэкапы, резервный хостинг и требования 152-ФЗ

Пожар в дата-центре OVHcloud отключил 3,6 млн сайтов, а резервные копии части клиентов сгорели вместе с серверами. Практическое руководство для редакции: правило 3-2-1-1-0, RPO и RTO, офсайт-копии в России, резервный хостинг и учения.

Резервная копия, которая лежит в том же здании, что и сервер, — это не резервная копия. Эту истину многие клиенты европейского хостинга OVHcloud выучили в марте 2021 года, а некоторые потом доказывали её в суде. Для редакции потеря данных означает не только простой сайта. Это исчезнувший архив публикаций, база подписчиков, эфирные записи, которые закон требует хранить, и почта с перепиской с источниками. Ниже — практическое руководство: что копировать, куда, как часто и сколько это стоит.

Что происходит, когда дата-центр выходит из строя

Ночью 10 марта 2021 года на площадке OVHcloud в Страсбурге случился пожар. Дата-центр SBG2 был уничтожен полностью, в соседнем SBG1 пострадали четыре зала из двенадцати, питание отключили на всех четырёх зданиях площадки. По подсчётам Netcraft, без связи остались около 3,6 млн сайтов на 464 тыс. доменов. Среди них — онлайн-банки, почтовые сервисы, новостные сайты, интернет-магазины и государственные порталы нескольких стран. Только во французской зоне .fr перестали отвечать около 1,9% всех доменов. OVH сообщила, что данные из SBG2, скорее всего, восстановить не удастся, а на восстановление части инфраструктуры может уйти около двух недель. Клиентам со страсбургскими серверами предложили замену на других французских площадках компании.

Самые болезненные последствия проявились позже. Коммерческий суд Лилля обязал OVHcloud выплатить двум клиентам в сумме 250 тыс. евро. Резервные копии этих компаний хранились в том же SBG2, что и рабочие серверы, и сгорели вместе с ними. Суд счёл, что хостинг не обеспечил обещанную услугу резервного копирования. Один из клиентов требовал более 6,5 млн евро, получил 100 тыс.; компания-хостинг обжаловала решения. Даже выигранный суд не возвращает данные: компенсация всегда меньше потерь. Отсюда первый практический урок для редакции, которая пользуется услугой резервного копирования от хостера: прочитать договор и выяснить, где физически хранятся копии. Если в том же дата-центре или даже на той же площадке, это защита от случайного удаления файла, но не от выхода из строя всего здания. Такая услуга полезна, однако не заменяет собственной копии у другого провайдера, которой редакция управляет сама и может проверить в любой момент.

Второй хрестоматийный случай — не про дата-центр, а про сами бэкапы. В январе 2017 года сервис GitLab.com потерял около шести часов данных: проекты, комментарии, учётные записи, задачи. Пострадали примерно 5 тыс. проектов и 700 аккаунтов, сервис был недоступен около 18 часов. В публичном разборе компания признала, что резервные копии никто не тестировал, потому что у них не было ответственного. Ежедневный дамп базы молча не создавался из-за несовпадения версий, а письма об ошибках не доходили до получателей. Пригодной оказалась только копия, сделанная для другой цели примерно за шесть часов до сбоя. Отдельный вывод из разбора: репликация — не резервная копия.

RPO, RTO и правило 3-2-1-1-0

Прежде чем покупать хранилище, редакции нужно ответить на два вопроса.

RPO (recovery point objective) — момент времени, на который данные должны быть восстановлены после сбоя. Проще говоря, сколько последних изменений редакция готова потерять. Для новостного сайта, который публикует десятки материалов в день, потеря суток — это десятки текстов, которые придётся восстанавливать вручную. Разумная цель для базы данных — от часа до нескольких часов.

RTO (recovery time objective) — сколько времени система может оставаться в восстановлении, прежде чем это начнёт серьёзно бить по работе организации. Для новостного сайта простой в несколько часов неприятен, в несколько дней — опасен для аудитории и рекламных контрактов.

Цели нужно ставить отдельно для каждой системы. Сайт и база публикаций, медиафайлы, эфирный архив, почта, бухгалтерия и база подписчиков — у каждой свои RPO и RTO и своя цена простоя.

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

• 3 копии данных — рабочая и две резервные;
• 2 разных типа носителей, одним из них может быть объектное хранилище;
• 1 копия вне основной площадки (офсайт);
• 1 копия офлайн, изолированная или неизменяемая;
• 0 ошибок: регулярная проверка восстановления.

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

Неизменяемость сегодня доступна в российских облаках без специального оборудования. В Object Storage Yandex Cloud, например, есть блокировка версий объектов. Она работает только при включённом версионировании и бывает трёх видов: управляемая (её может снять администратор с явным подтверждением), строгая (её нельзя снять или сократить до истечения срока) и бессрочная. Заблокированную версию нельзя изменить или удалить, но можно прочитать и восстановить. Для резервных копий логично использовать строгую блокировку на 30–90 дней.

Что именно копировать

База данных CMS. Самое ценное и самое маленькое: тексты, заголовки, метаданные, комментарии, пользователи. Копировать как минимум ежечасно, хранить ежедневные копии за месяц и ежемесячные — за год.

Медиафайлы. Фото, видео, аудио — самое объёмное. Их удобнее синхронизировать в объектное хранилище инкрементально: копируются только новые и изменённые файлы.

Код сайта и конфигурация. Тема, плагины, настройки веб-сервера, SSL, cron-задачи. Всё это должно лежать в репозитории или хотя бы в архиве с описанием, как развернуть сайт с нуля.

Эфирный архив. Для радио это не только вопрос удобства. Закон о СМИ обязывает вещателя хранить записи собственных передач, вышедших в эфир, не менее месяца, а регистрационный журнал — не менее года с даты последней записи. Копия эфирных записей у второго провайдера защищает от ситуации, когда при споре нечего предъявить.

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

Доступы. Пароли к регистратору домена, DNS, хостингу, соцсетям — в менеджере паролей с резервной копией. Без доступа к регистратору домена восстановленный сайт некуда направить.

Персональные данные: копии — только в России

Редакция почти всегда оператор персональных данных: подписчики рассылки, участники конкурсов, авторы комментариев, сотрудники. С 1 июля 2025 года действует обновлённая норма части 5 статьи 18 закона «О персональных данных»: при сборе данных граждан России запрещено использовать базы данных за рубежом для записи, систематизации, накопления, хранения, уточнения и извлечения.

Минцифры в письме от 12 мая 2025 года уточнило, что хранение персональных данных граждан России, «в том числе их копий», должно осуществляться с использованием баз данных в России. Трансграничная передача данных, ранее собранных с использованием российских баз, при этом возможна в случаях, предусмотренных законом. О такой передаче нужно уведомлять Роскомнадзор. За нарушение требований о локализации КоАП предусматривает для юрлиц штраф от 1 до 6 млн рублей, за повторное — от 6 до 18 млн.

Практический вывод: все резервные копии, где есть персональные данные — база CMS с пользователями и комментариями, база подписчиков, кадровые документы, почта, — должны храниться у провайдеров с площадками в России. Это не мешает правилу 3-2-1: у крупных российских облачных и хостинг-провайдеров есть дата-центры в разных городах.

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

Резервный хостинг, DNS и статическое зеркало

Резервная копия отвечает на вопрос «что восстановить», но не «где». На случай долгого простоя основной площадки нужен заранее подготовленный план.

Резервная площадка. Аккаунт у второго провайдера, где сайт можно развернуть из бэкапа за несколько часов. Инструкция по развёртыванию должна быть проверена на практике, а не написана «на всякий случай».

DNS. Если DNS-зона обслуживается тем же провайдером, что и сайт, при аварии можно потерять и возможность переключить домен. Лучше держать DNS у отдельного провайдера или у регистратора. Время жизни записей (TTL) для основных записей сайта имеет смысл держать небольшим — тогда переключение на резервную площадку разойдётся по сети быстрее.

Статическое зеркало. Даже если динамический сайт с CMS восстановить быстро не удаётся, можно показать читателю статическую копию: главную, последние материалы, контакты. Такую копию можно регулярно выгружать и держать в объектном хранилище. В документации Yandex Cloud описана, например, схема, где статический сайт лежит в бакете Object Storage, а запросы к нему идут через балансировщик и Cloud CDN. Там же предупреждают, что изменения DNS могут расходиться несколько часов. Важно: статическое зеркало не должно содержать персональных данных пользователей.

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

Сколько это стоит

Резервное копирование редакции обходится дешевле, чем кажется. По тарифам Yandex Object Storage на октябрь 2026 года хранение одного гигабайта в месяц с НДС стоит около 2,38 рубля в стандартном классе, около 1,27 рубля — в холодном и около 0,63 рубля — в «ледяном». Первые 100 ГБ исходящего трафика в месяц бесплатны, дальше — около 1,68 рубля за гигабайт. У «ледяного» класса есть условие: минимальное тарифицируемое время хранения объекта — 12 месяцев, поэтому туда стоит класть только то, что хранится долго, например годовой эфирный архив.

Объёмы в таблице — пример для небольшого регионального холдинга, а не норматив: свои объёмы нужно посчитать. Расчёт по тарифам без учёта операций и восстановления. Главные затраты — не хранилище, а время администратора на настройку, проверки и учения, и резервный сервер, если редакция хочет держать его постоянно включённым.

Проверка, документы и учения

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

Минимальный регламент для редакции:

• Мониторинг. Каждое задание резервного копирования должно сообщать об успехе и об ошибке в канал, который реально читают. Отсутствие сообщения — тоже сигнал тревоги.
• Ежемесячная проверка. Восстановить базу из случайной копии на тестовый сервер и убедиться, что сайт открывается и последние материалы на месте.
• Учения раз в полгода. Сценарий «основная площадка недоступна»: развернуть сайт у резервного провайдера, переключить DNS, засечь время. Сравнить с целевым RTO.
• Документ на одну-две страницы. Где лежат копии, как восстановить каждую систему, кто отвечает, телефоны провайдеров, где доступы. Документ должен храниться не только на том сервере, который может выйти из строя.
• Ответственный. Конкретный человек, а не «IT-отдел».

Что делать редакции

1. Составить список систем — сайт, база, медиафайлы, эфирный архив, почта, бухгалтерия, база подписчиков — и для каждой записать RPO и RTO.
2. Проверить, где лежат текущие бэкапы. Если в том же дата-центре, что и сервер, — это первая задача.
3. Завести второго провайдера с площадкой в другом городе России и настроить туда ежедневное копирование.
4. Включить неизменяемость хотя бы для одной копии: версионирование и блокировку объектов на 30–90 дней.
5. Проверить локализацию. Все копии с персональными данными — только на российских площадках.
6. Вынести DNS к отдельному провайдеру, снизить TTL основных записей.
7. Подготовить статическое зеркало и инструкцию по развёртыванию сайта у резервного хостера.
8. Настроить уведомления об успехе и ошибках копирования.
9. Раз в месяц восстанавливать базу на тест, раз в полгода — проводить учения.
10. Записать всё в один короткий документ и хранить его вне основной инфраструктуры.

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