Когда перестаёт открываться сайт, бизнесу нужен ответ на простой вопрос: когда снова можно принимать заказы? Если недоступен целый дата-центр, ответ зависит в том числе от того, есть ли у компании копия сайта за пределами этой площадки.
9 октября РБК опубликовал обращение «Яндекса» после атак на два дата-центра. В ночь с 7 на 8 октября серьёзные повреждения получил объект в Сасово Рязанской области, его работа полностью остановлена. Утром 9 октября была повреждена инфраструктура в Калуге. По сообщению компании, сотрудники на обеих площадках не пострадали. На момент обращения сроки восстановления оборудования оставались неопределёнными.
Из этой новости нельзя сделать вывод, что клиентские данные утрачены. Но она даёт вполне практический повод проверить свой сайт: сможете ли вы восстановить его, если доступ к основной площадке исчезнет на неопределённое время?
Редакционная иллюстрация. Изображение не показывает реальные объекты «Яндекса».
Сайт можно перенести. Если есть что переносить
Представим обычный интернет-магазин. На сервере лежат файлы сайта, фотографии товаров и база с заказами. Там же каждую ночь создаётся архив. В панели хостинга всё выглядит спокойно: резервное копирование включено.
Теперь сервер недоступен вместе с площадкой. Взять новый VPS можно. Скачать архив со старого — уже нет.
Разработчик найдёт исходный код в Git, дизайнер пришлёт макеты, менеджер восстановит часть каталога из выгрузки. Но заказы за последние дни, изменения в личных кабинетах и загруженные документы придётся искать отдельно. В репозитории этих данных обычно нет.
Поэтому проверять нужно весь комплект для восстановления: код и доработки, пользовательские файлы, базу данных, настройки окружения и интеграций. Для сайта на 1С-Битрикс копия файлов без базы не вернёт заказы и содержимое инфоблоков, а база без загруженных изображений и документов даст неполный сайт.
В штатном инструменте резервного копирования Битрикса состав архива настраивается. Наличие готового файла ещё не говорит о том, что в него включили всё необходимое.
Копия должна пережить недоступность основной площадки
Папка с архивами на рабочем сервере удобна для быстрого отката после неудачного изменения. При недоступности сервера она окажется недоступна вместе с ним.
Для аварийного восстановления нужна копия на другой площадке. Причём слово «другая» стоит проверить: отдельный каталог, бакет или тариф сам по себе не доказывает, что данные физически находятся в другом дата-центре.
Например, в документации Yandex Cloud виртуальные машины и диски относятся к ресурсам конкретной зоны доступности. У разных сервисов отличаются устройство хранения и гарантии. Их нужно выяснить для своей схемы.
Проверять стоит сценарий целиком: основной сервер недоступен, а копию можно получить и развернуть без его участия.
Если требуется снизить зависимость ещё и от одного провайдера, дополнительную копию можно хранить у другого. Доступы к ней тоже должны быть отдельными. Компрометация рабочего сервера не должна автоматически давать возможность удалить всю историю бэкапов.
Один свежий архив не заменяет историю
Последняя копия может оказаться уже повреждённой. Ошибку в каталоге заметили через неделю, а ночной процесс успел несколько раз сохранить неправильные данные. Синхронизация без версий способна так же аккуратно перенести удаление файлов на запасное хранилище.
Поэтому нужны несколько точек восстановления и заранее выбранная глубина хранения. Она зависит от того, как быстро на вашем сайте обнаруживают ошибки и сколько места занимают копии.
Для защиты от удаления пригодятся неизменяемые версии, отдельные права доступа или отключённая от рабочей системы копия. Такие меры дополняют географическое разделение: удалённый архив тоже можно уничтожить, если доступ к нему открыт с заражённого сервера.
CISA рекомендует хранить изолированные зашифрованные копии критичных данных и регулярно проверять их восстановление. В облачных хранилищах ведомство также советует использовать защиту от удаления и версионирование.
Какой объём данных можно потерять
Возьмём условный магазин: копия базы создана в 02:00, сбой произошёл в 18:00. Если других сохранённых данных нет, восстановление из этого бэкапа вернёт магазин к состоянию шестнадцатичасовой давности.
Для редко обновляемого сайта это может быть приемлемо. Для магазина с постоянным потоком заказов — уже проблема. Частоту копирования нужно выбирать по допустимой потере данных.
Обсудить с бизнесом стоит два ограничения:
- RPO — за какой период допустимо потерять изменения: сутки, час, несколько минут.
- RTO — сколько времени есть на восстановление работы сайта.
Если заказы нельзя терять за целый день, одной ночной копии недостаточно. Нужны более частые согласованные копии базы или восстановление по журналам изменений — с настройкой и проверкой под конкретную СУБД.
Если сайт должен вернуться за минуты, одного архива также может не хватить: потребуется заранее подготовленное резервное окружение. AWS в рекомендациях по аварийному восстановлению связывает выбор стратегии с допустимым простоем, потерей данных, стоимостью и сложностью решения. Бэкапы остаются необходимыми, но не обещают мгновенного переключения.
Проверка заканчивается восстановлением
Уведомление «архив создан» подтверждает только завершение операции. Следующая проверка — развернуть копию на отдельном сервере.
После этого нужно открыть сайт, войти в административную часть, проверить изображения, каталог, последние сохранённые заказы и работу основных функций. В тестовом окружении следует отключить реальные платежи, рассылки и автоматические обмены, чтобы проверка не запустила действия на рабочем проекте.
Заодно станет понятно, сколько времени занимает восстановление и чего не хватает: нужной версии PHP, настроек веб-сервера, ключа расшифровки или доступа к DNS. Эти зависимости лучше обнаружить заранее.
Результат такой проверки можно сформулировать конкретно: из копии за определённую дату сайт восстановлен на другой площадке, данные проверены, запуск занял столько-то времени. При изменении инфраструктуры проверку стоит повторить.
Что проверить сейчас
Начать можно с пяти вопросов:
- Где находится последняя успешно созданная копия и насколько она свежая?
- Можно ли получить её при недоступности основного сервера и дата-центра?
- Включены ли в неё база, пользовательские файлы и доработки?
- Есть ли предыдущие версии и защита от удаления всей истории?
- Когда сайт последний раз восстанавливали из этой копии на отдельной площадке?
Если ответы приходится искать уже во время сбоя, восстановление начнётся с выяснения этих деталей.
Подробнее о способах копирования, правиле 3-2-1 и выборе хранилища мы рассказали в статье «Бэкапы сайта и базы: как пережить аварию без потери данных».
Делать бэкапы нужно до аварии
Остановка дата-центра не обязательно означает потерю данных. Однако бизнесу может потребоваться вернуться к работе раньше, чем восстановится основная площадка.
Для этого нужны свежие резервные копии, доступные за её пределами, и проверенный порядок запуска сайта в другом месте. Бэкапы нужно создавать автоматически, сохранять с историей и регулярно проверять восстановлением. Тогда у команды будет исходный материал и понятная последовательность действий, даже если сроки возвращения основного сервера неизвестны.
Нужно проверить бэкапы вашего сайта?
Проверим состав и свежесть резервных копий, место хранения и доступы. Выполним тестовое восстановление и подготовим план запуска сайта на другой площадке.
Обсуждение
Поделитесь мнением — первый комментарий задаст тон.