Компании годами делают резервные копии, уверенные в том, что данные находятся под защитой. Когда случается инцидент и нужно срочно восстановить работу — выясняется, что копии есть, но восстановление займёт месяц или вовсе невозможно. Разберем типичные заблуждения, из-за которых бэкап превращается в имитацию защиты, и рассмотрим, как проверить систему резервного копирования, не дожидаясь инцидента.
Заблуждение первое: репликация заменяет резервное копирование
Репликация — это зеркало системы на текущий момент. Данные основной площадки копируются на резервную в режиме реального времени, и обе всегда синхронизированы. Есть вторая копия, всё актуально, на случай сбоя, есть куда переключиться — и репликация начинает казаться достаточной мерой защиты.
Проблема возникает там, где реплика бессильна — например, при ошибке человека. Если данные случайно удалили или повредили на основной площадке, это мгновенно реплицируется на вторую. Обе площадки содержат уже испорченные данные, так как синхронизированы. Откатиться к состоянию до ошибки невозможно: снимка прошлого состояния нет.
Резервная копия решает эту задачу — она фиксирует состояние данных в определённый момент времени и позволяет к нему вернуться. Репликация и резервное копирование не взаимозаменяемы: одно обеспечивает доступность, другое — возможность восстановления. Когда одно заменяют другим, защиты от потери данных нет.
Заблуждение второе: зелёные отчёты вместо тестового восстановления
Нередко компании убеждены: раз задания выполняются по расписанию и отчёты зелёные — резервные копии в порядке. Тестовое восстановление откладывается на потом, потому что всё работает и повода проверять нет.
Цена этой уверенности выясняется в момент инцидента. При первой необходимости срочно восстановить большой объём данных оказывается, что перекачка займёт месяц: слишком большой объём, слишком медленный канал, хранилище не выдерживает нагрузку на чтение. То, что в планах должно было занимать часы, растягивается на недели. Плановый RTO расходится с реальным: никто заранее не проверил скорость восстановления.
Зелёный статус в отчёте говорит только о том, что задание завершилось без ошибок на этапе копирования. Он ничего не говорит о том, цела ли цепочка копий и пригодны ли данные для восстановления. Блоки могут быть повреждены, цепочка инкрементов разорвана, метаданные битые — при этом процесс копирования отработал штатно. Всё это проверяется только тестовым восстановлением — пока оно не сделано, состояние копий под вопросом.
Заблуждение третье: изолировать бэкап — достаточно
Изоляция резервной копии — необходимая база, но не конечная цель. Представим: резервные копии отделены физически — например, в облаке провайдера. Сетевой доступ ограничен изолированным сегментом. Управление доступно только через отдельные учётные записи вне основной инфраструктуры, с обязательным MFA. Даже взломав основную сеть, злоумышленник не может добраться до копий.
Но, если изоляция не сработает, следующий уровень защиты — неизменяемость копии. Реализуется это через принцип WORM: в S3-хранилищах — с помощью Object Lock, при котором система на уровне политики отказывается выполнять команду удаления до истечения заданного срока. Даже получив права администратора или root, уничтожить защищённую копию невозможно, пока не истёк заданный срок.
На этом моменте легко поставить галочку «защищено» и закрыть вопрос. Но этой меры недостаточно, если срок хранения копии короткий. Злоумышленник, не имея возможности повредить копии, остаётся в инфраструктуре незамеченным и методично повреждает данные в основной системе. Новые бэкапы записывают уже испорченную информацию, а старые — единственные чистые — уходят за пределы глубины хранения и затираются. Когда атака обнаружена, восстанавливаться не из чего: все доступные копии содержат повреждения, а неизменяемость честно охраняла уже бесполезные файлы.
Поэтому изоляцию и неизменяемость необходимо дополнять достаточной глубиной хранения. Облако упрощает эту задачу: ёмкость наращивается без закупки оборудования, а старые копии перемещаются в более дешёвые классы хранения.
Как проверить главное в системе бекапа за два часа
При ограниченном времени стоит сосредоточиться на трёх вопросах: изолирован ли доступ к управлению хранилищем, есть ли действительно неизменяемая резервная копия и когда с неё в последний раз проводилось восстановление.
Если вход идёт под теми же учётными данными, что и в основной инфраструктуре, компрометация сети открывает путь и к управлению копиями. Доступ выносится в отдельные учётные записи, закрывается вторым фактором, а интерфейс управления отделяется от остальной сети.
Следующий вопрос — настроена ли неизменяемость. Ответа «да, настроена» недостаточно. Важно понять, как именно она реализована. WORM-блокировка файловой системы или S3 Object Lock обеспечивают защиту, которую нельзя снять даже с правами администратора. Если же неизменяемость сводится к галочке в интерфейсе, которую тот же администратор может убрать, — это не защита. Отдельный вопрос — срок. Три дня блокировки копии при месячной глубине хранения не перекрывают окно обнаружения атаки. Здесь сталкиваются задачи эксплуатации и безопасности. Администраторы сокращают срок лока до
Наконец, необходимо убедиться, что из неизменяемой копии реально можно восстановиться. Единственный способ — тестовое восстановление. Если оно проводилось давно или с тех пор менялась инфраструктура, стоит запустить его немедленно. Полноценно поднять систему за два часа нереально, но восстановить что-то небольшое — можно для диагностики механизма. Тест проверяет ключевые предположения: цепочка копий цела, каталог метаданных исправен, хранилище отдаёт данные. Ломается, как правило, сам механизм — и это выясняется только при реальной проверке.
Что делать, если нашли критическое нарушение
Критические нарушения бывают разными. Например, сервер вовсе не включён в задание резервного копирования, или полная копия не делалась больше года, а всё это время копировались только изменения.
Первый импульс — быстро перенастроить задание и считать задачу закрытой. Добавить пропущенный сервер или принудительно запустить полную копию — необходимый первый шаг, но не финальный. Обнаружив проблему, ее нужно превратить в правило, чтобы она не повторилась. Например, регулярно сверять список серверов в задании бэкапа с тем, что реально есть в инфраструктуре, — это исключит ситуацию, когда сервер просто забыли добавить. А правило о том, что полная копия должна обновляться регулярно, не даст инкрементам накопиться до состояния, когда восстановление уже невозможно.
После того как точечные нарушения закрыты, проверяем главное: рабочая ли копия. Убедиться в этом можно только тестовым восстановлением. Разовая проверка закрывает вопрос сегодня, но не завтра. Тестовое восстановление должно быть регулярной процедурой, закреплённой в регламенте, — иначе его снова отложат до инцидента.
