Veeam Backup & Replication V11: Instant MSSQL Recovery
Осень 2020 года, и я снова начинаю публикацию серию статей о функционале новой версии Veeam Backup & Replication v11. Сегодня моя первая часть будет посвящена Instant MSSQL Recovery.
У нас может быть ряд ситуаций, когда нам необходимо быстро восстановить доступ к какой-то нашей БД:
- Повреждение одной конкретной базы, при этом сам сервер работает корректно, как и остальные БД, и нам нет необходимости восстанавливать сервер целиком, но размер этой базы не позволяет нам восстановить (классическим способом) её в приемлемый срок и необходимо восстановить её работоспособность как можно скорее.
- Полный отказ сервера БД, но у нас есть резервный (другой) сервер БД на котором мы можем в короткие сроки восстановить доступность к базе. Например, имея большой физический сервер БД, мы можем иметь холодный резерв в виде виртуальной машины на которой в случае выхода из строя основного сервера мы сможем оперативно запустить критичный набор баз.
- Также возможен вариант миграции базы с одного сервера на другой с минимальным простоем.
Если вы уже работали с Veeam, то знаете о технологии Instant VM Recovery которая позволяет запустить виртуальную машину на прямую из файла резервной копии с последующим переносом её на продуктивную СХД. Здесь подход аналогичный.
И так, у нас есть некий сервер с БД MSSQL, в моём случае это мой домашний боевой сервер Veeam с 10-й версией (база конечно совсем маленькая, но для демонстрации принципа работы этого будет достаточно). Естественно, чтобы иметь возможность восстанавливать БД, как и прежде, у нас должна быть включена поддержка application-aware processing — иначе не видать нам никакой БД. И так, после успешного бекапа я просто удаляю на своём сервере БД, которую потом будут восстанавливать.
Теперь мы переключаемся на сервер с V11 Beta 2. Не ищите Instant recovery в панели VBR — её там нет. Первым делом выбираем Restoring Application Items -> Microsoft SQL Server. И уже в Veeam Explorer для нужной нам базы мы выбираем Instant Recovery.
У нас есть 2 варианта запуска БД:
- На том же сервере
- На другом сервере
И первое о чём нас спросят — вариант переключения. Собственно, есть 3 варианта:
- Переключиться на продуктивные данные автоматически, т.е. сразу после завершения копирования данных на прод
- Вручную, когда мы решим, что пора это сделать
- По расписанию, в назначенное время
После чего запускается процесс восстановления. Первым этапом резервная копия монтируется на наш сервер БД в директорию FLR (то же название, что и у FLR модуля на базе Linux, который разворачивается при файловом восстановлении файлов на Linux машинах) по iSCSI (iSCSI инициатор Windows запускается и настраивается автоматически, а после завершения работы IR выключается). БД «публикуется» на сервере используя в качестве файлов БД данные томов из директории FLR. После чего наша база становится доступна для работы.
Все изменения, которые происходили во время IR, пишутся на сам сервер БД, а параллельно работе с виртуализованными файлами БД происходит их копирование в первоначальное месторасположение. По окончании копирования со стороны Veeam мы увидим (в случае, если у нас выбран не автоматический switchover), что наша база скопирована на продуктив и готова к переключению. Единственное — пока мне неизвестно в какой именно момент накатываются изменения на восстановленную базу. Происходит ли это один раз во время switchover или при накоплении определённой дельты, изменения периодически накатываются на прод, после того как БД уже скопирован, но switchover ещё не произведён. Об этом мы сможем узнать только ближе к релизу, когда появится документация.
В консоли самого VBR так же видно запущенный процесс IR.
Но следует учитывать, что если вы закроете окно Veeam Explorer, вы потеряете возможность выполнить switchover. База продолжит работать, но из консоли VBR можно только остановить публикацию базы (т.е. просто оторвать её от сервера, без каких-либо переключений), а клик по заданию не открывает обратно Veeam Explorer. Это можно отнести к одному из недочётов и, вполне вероятно, к релизу будет исправлено. Но сегодня, чтобы вернуться к необходимому нам функционалу, придётся снова запустить Veeam Explorer для какого-то бекапа, а там по-прежнему будет наша запущенная база и мы уже сможем сделать switchover. Сам процесс switchover изменяет на сервере MSSQL путь по которому находятся файлы БД на их продуктивное расположение и убирает мапинг бекапа к серверу.
Схематично этот процесс выглядит вот так. Единственное уточнение, что под Primary Storage подразумевается не какая-то СХД, а то место, где у вас лежали файлы БД на конкретной машине.
Данный функционал позволяет минимизировать RTO для конкретных БД, но при этом не стоит забывать о том, какую нагрузку на СХД под хранение резервных копий может создавать Instant Recovery. Если вы планируете использовать этот функционал и понимаете примерную нагрузку, которую создаёт работа вашей БД, стоит правильно подобрать производительную СХД для хранения резервных копий, которые планируется запускать при помощи Instant Recovery, чтобы в критический момент не столкнуться с ситуацией, что необходимый функционал есть и работает, но производительность железа просто не позволяет его использовать и моментальный запуск из резервной копии вашей БД не позволяет её использовать из-за недостатка производительности.
Что есть ещё из плюшек:
- Поддерживаются кластеры MSSQL
- Восстановление возможно и с Capaticy tier, но, естественно, нужно понимать какая при этом у базы будет производительность
Это первая ласточка из того обилия функционала, что ждём нас в 11-й версии, а пока ребята из Veeam очень ждут обратной связи. Все свои негодования, восторги и прочие эмоции относительно нового Instant MSSQL Recovery можно высказать у нас в чате, триггернув @andrewzhelezko.
