Где хранить данные
После недавних инцидентов с российскими дата-центрами вопрос для бизнеса заключается не столько в поиске самого надежного облачного провайдера, сколько в возможности сохранить данные при полной недоступности основной инфраструктуры. Просто перенести сайт в другой ЦОД недостаточно, поскольку аналогичные риски существуют практически у любого поставщика услуг.
Начать стоит с проверки того, где физически находятся данные и их резервные копии. Причем важно выяснить не только название провайдера, но и конкретный регион размещения, а также принадлежность самого дата-центра. Разные облачные компании могут использовать одну физическую площадку. Поэтому мы бы рекомендовали запросить у подрядчика схему хранения данных и проверить, действительно ли резервные копии изолированы от основного сервера.
Для большинства небольших компаний можно рассмотреть схему из трех копий: рабочие данные на основном сервере, резервная копия в независимом российском дата-центре и дополнительная зашифрованная копия на физическом носителе, который хранится отдельно и не подключен постоянно к сети. Например, это может быть внешний SSD или NAS в другом офисе или городе. При этом само устройство тоже необходимо защищать от несанкционированного доступа.
Для автоматизации резервного копирования необязательно разрабатывать собственную систему. Существуют готовые решения, например Restic и Rclone, которые позволяют сохранять данные в S3-совместимые хранилища. Среди российских сервисов такую инфраструктуру предоставляют Selectel S3 и Timeweb Cloud S3. У обоих документирована поддержка Object Lock, которая помогает защитить резервные копии от удаления и перезаписи. Однако выбор конкретного поставщика необходимо делать после проверки текущей доступности ресурсов и их физического размещения.
Какие технические нюансы надо учесть
Обычная синхронизация файлов не равнозначна резервному копированию. Если файл случайно удалят на основном сервере, синхронизация может удалить его и в резервном хранилище. Поэтому необходимо сохранять предыдущие версии данных и использовать отдельные учетные записи с ограниченными правами доступа. Дополнительно стоит настроить уведомления об ошибках резервного копирования, чтобы проблема обнаруживалась сразу, а не во время аварии.
Отдельное внимание стоит уделить базам данных интернет-магазинов. Ежедневного копирования здесь может быть недостаточно. Если сайт восстановят из вчерашнего архива, последние заказы могут оказаться потеряны. Для PostgreSQL можно использовать pgBackRest и архивирование журналов WAL, для MySQL предусмотрено восстановление с использованием бинарных журналов. Такие механизмы позволяют восстанавливать базу на более близкий к моменту сбоя период при условии правильной настройки и сохранности журналов.
Важно заранее определить, сколько времени бизнес может находиться без сайта и какой объем последних данных допустимо потерять. От этого зависят частота копирования, способ хранения и необходимость резервного сервера.
Что делать с персональными данными
При работе с персональными данными российских граждан нужно учитывать требования локализации, сформулированные в Федеральном законе от 14 июля 2022 года № 266-ФЗ «О внесении изменений в ФЗ „О персональных данных“…». В соответствии с действующими ограничениями хранение клиентских баз и их резервных копий необходимо организовывать на территории России, если не применяются предусмотренные законом исключения. Шифрование архива само по себе не позволяет обойти эти требования. При этом публичные изображения, тексты и программный код, не содержащие персональных данных и иной информации с ограничениями на размещение, можно резервировать отдельно, в том числе за пределами России.
Как проверить восстановление сайта
Совет владельцу бизнеса - попросите подрядчика продемонстрировать восстановление сайта при полной недоступности основного хостинга. Для этого заранее должны быть подготовлены резервная инфраструктура, исходный код, настройки, доступы к домену, необходимые ключи и инструкции по запуску.
На тесте важно проверить не только открытие страниц, но и оформление заказов, работу каталога, интеграции с CRM и платежными системами. Желательно проводить такие проверки регулярно, например раз в квартал, и фиксировать фактическое время восстановления и актуальность данных.
В конечном счете безопасность информации определяется не количеством резервных копий и не известностью провайдера, а тем, сможет ли бизнес самостоятельно восстановить свои данные и возобновить работу без доступа к основной инфраструктуре.
Чек-лист: где и как безопасно хранить важные для бизнеса данные, чтобы не зависеть от инцидентов в дата-центрах.
1. Начните с инвентаризации критически важных данных
- Составьте список того, без чего бизнес встанет: контент, товарный каталог, заказы, клиентская база, код, настройки сайта.
- Определите, какие доступы и интеграции нужны для работы сайта — без них восстановленные данные не помогут.
- Зафиксируйте, где сейчас хранится каждая категория данных и кто отвечает за доступ.
2. Настройте резервное копирование по правилу 3-2-1
- Держите 3 копии данных: рабочую и две резервные.
- Используйте 2 разных типа хранения (например, диск и облако).
- Храните минимум 1 копию за пределами основной площадки — в другом дата-центре или у другого провайдера (не храните сайт и его резервные копии в одном дата-центре).
3. Подготовьте альтернативную инфраструктуру для
восстановления
- Заранее сохраните код, базы данных, настройки и необходимые доступы в месте, независимом от основного дата-центра.
- Определите площадку, на которой сможете поднять сайт, если основной дата-центр недоступен.
- Настройте автоматическое резервное копирование в независимое хранилище.
4. Проверьте восстановление на практике
- Оцените, за какое время вы сможете восстановить работу сайта.
- Проверьте, насколько свежими будут данные после восстановления.
- Убедитесь, что сохраняются ключевые функции: оформление и оплата заказов, личный кабинет, каталог.
- Проведите тестовое восстановление до реального сбоя, а не во время него.
5. Защитите SEO-видимость на случай простоя
- Заранее предусмотрите выдачу HTTP-статуса 503 на независимой инфраструктуре — чтобы обозначить временную недоступность для поисковых роботов.
- Настройте возможность быстрого переключения трафика на резервную площадку.
- Проверьте сценарий восстановления сайта целиком: не только данные, но и доступность страниц для поиска.
- Помните: 503 не гарантирует сохранение индексации при длительном простое, поэтому скорость восстановления важнее самой заглушки.
Ранее «Подушка» объяснила, как повысить видимость бренда в нейровыдаче.
