Резервное копирование после виртуализации: почему старые схемы больше не помогают
Наличие резервных копий и способность восстановиться - это разные вещи. Виртуализация меняет оба параметра, и старые подходы к бэкапу часто создают иллюзию защиты там, где её нет.
В большинстве компаний резервное копирование воспринимается как решённая задача. Есть агент на каждом сервере, есть расписание, есть лента или сетевое хранилище. Галочка стоит. Когда приходит виртуализация, эту галочку часто оставляют на месте - и это ошибка. Виртуализация сама по себе не меняет принципиальной модели управления инфраструктурой - резервное копирование является ещё одним слоем, где это различие проявляется.
Проблема не в том, что резервные копии перестают создаваться. Проблема в том, что они перестают быть достаточными для восстановления - или восстановление становится намного дороже и медленнее, чем предполагалось.
Что меняется с виртуализацией
В физической среде каждый сервер - это отдельная сущность. Агент на нём делает копию файловой системы или базы данных. При отказе восстанавливаешь именно этот сервер.
В виртуальной среде появляются новые уровни:
- гипервизор управляет несколькими виртуальными машинами на одном хосте;
- хранилище общее - все ВМ могут лежать на одном SAN или NAS;
- сетевые настройки, политики, конфигурация гипервизора - это тоже данные, которые нужно восстанавливать;
- снапшоты ВМ не равны резервным копиям, хотя выглядят похоже.
Агент внутри виртуальной машины ничего из этого не захватывает. Он видит только файловую систему своей ОС - так же как раньше. Но теперь потеря хоста или хранилища означает потерю нескольких машин сразу.
Разница между "делаем бэкапы" и "умеем восстановиться"
Это два разных вопроса, и ответ на первый не отвечает на второй.
"Делаем бэкапы" - значит данные куда-то копируются по расписанию. Это необходимо, но недостаточно.
"Умеем восстановиться" - значит при конкретном сценарии отказа (упал хост, потеряли хранилище, зашифровали вирусом весь датацентр) мы знаем точно:
- что именно нужно восстановить и в каком порядке;
- сколько времени это займёт (RTO - Recovery Time Objective);
- за какой период мы потеряем данные (RPO - Recovery Point Objective);
- у кого есть доступ и навыки для выполнения восстановления.
В виртуальной среде без пересмотра этих параметров компания нередко обнаруживает на практике, что восстановление занимает не часы, а дни - потому что никто не пробовал делать это с нуля.
Типичные ловушки
Снапшоты вместо бэкапов. Снапшот ВМ - это быстро и удобно, но он лежит на том же хранилище что и оригинал. При потере хранилища теряются и снапшоты.
Агентский бэкап без учёта консистентности. Если база данных или приложение не переведены в состояние, подходящее для резервного копирования в момент снятия снапшота, резервная копия может быть несогласованной - и не подняться при восстановлении.
Отсутствие бэкапа конфигурации гипервизора. При потере хоста нужно не только восстановить ВМ, но и пересоздать всю среду: сети, политики, настройки кластера. Это тоже данные.
Никогда не проверяли восстановление. Бэкап, который никогда не тестировался, с неизвестной вероятностью не работает. Это не преувеличение.
Что нужно проверить
Практический список вопросов для руководителя или ИТ-директора:
- Покрываем ли мы бэкапом конфигурацию гипервизора и хранилища, а не только данные ВМ?
- Что происходит при потере всего хоста - есть ли план и сколько времени занимает восстановление?
- Когда последний раз проводилось полное восстановление из бэкапа в тестовой среде?
- Хранятся ли резервные копии отдельно от основного хранилища - физически или логически?
- Кто конкретно будет выполнять восстановление и знает ли он процедуру?
Если хотя бы на один из этих вопросов нет чёткого ответа - резервное копирование существует на бумаге, а не как рабочая процедура. Виртуализация не создала эту проблему, но она её обострила.