В VBR 11 у инструментов Veeam Explorer for SQL Server и Veeam Explorer for Oracle появилась возможность мгновенного восстановления базы данных (Instant recovery). Подход здесь напоминает всем знакомое мгновенное восстановление виртуальной машины - быстро смонтировать файлы на рабочий сервер, чтобы, например, достать нужные отчеты для бухгалтерии, и в это же время в фоновом режиме спокойно копировать файлы бэкапа и по готовности переключиться на полноценную машину.
Рассмотрим эту фичу более подробно на примере SQL Server database.
Для моментального восстановления Veeam Explorer for Microsoft SQL Server задействует Veeam Explorers Recovery Service , который и будет выполнять все нужные операции - а сам Veeam Explorer после старта сессии восстановления можно и закрыть.
Сам же процесс восстановления проходит так:
(1) Veeam Explorer запускает параллельно 2 сессии монтирования файлов бэкапа по iSCSI (iSCSI mount sessions). В ходе одной из них база из бэкапа публикуется на продакшен сервер и аттачится к нужному инстансу SQL Server. (При публикации БД выполняется ее временный аттач к выбранному серверу без собственно восстановления). В ходе второй в фоновом режиме идет копирование файлов из бэкапа на продакшен сервер.
Примечание: Пока пользователи работают с опубликованной базой (“запаской”), все изменения файлов базы сохраняются в кэш на маунт-сервере.
(2) После того, как все файлы из бэкапа скопировались на целевой сервер, происходит синхронизация изменений, накопившихся в кэше.
(3) На финальном этапе выполняется переключение на актуальную базу, поднятую из бэкапа на продакшене и успешно синхронизированную. Переключение можно запустить вручную или автоматически.
Примечание: Лично я считаю это большим достижением в юзабилити продукта, ибо тут софт работает за пользователя. А ведь сколько тикетов было открыто, когда при мгновенном восстановлении ВМ люди попросту забывали выполнить финальные шаги и так и ехали на “запаске”, из-за чего начинались проблемы с ресурсами.
В ходе переключения Veeam Explorer автоматически выполняет вот такие шаги:
Останавливает публикацию базы.
Использует содержимое кэша, чтобы синхронизировать восстановленную базу с той, которая была опубликована.
Выполняет drop для опубликованной базы.
Запускает восстановленную базу.
Примечание: Сессия мгновенного восстановления устойчива по отношению к отказам маунт-сервера, бэкап сервера или к сетевым проблемам. Если происходит такой сбой, то процесс застывает в режиме ожидания и пытается возобновить работу каждые 5 минут. Если 10 автоматических попыток завершились неудачей, можно повторить вручную после починки проблемных мест.
Мгновенное восстановление можно выполнять:
На исходный или на другой сервер (инстанс).
Для одной или нескольких баз.
На последнее доступное состояние.
На выбранный момент времени.
На состояние, в котором база была до конкретной транзакции.
Важные нюансы
Если вы работаете с зашифрованными БД, то имейте в виду, что перед тем, как вам потребуется восстановить базу, нужно будет восстановить сертификат шифрования. Для этого нужно иметь под рукой бэкап сертификата, а создать его можно так:
USE master
BACKUP CERTIFICATE <certificate name> TO FILE = 'path_to_file'
WITH PRIVATE KEY(ENCRYPTION BY PASSWORD='******', FILE='path_to_private_key_file');
Подробности о работе с такими базами можно найти в этой статье базы знаний Veeam.
Если вы рассчитываете выполнять мгновенное восстановление базы с ноды AlwaysOn availability group, имейте в виду, что Veeam Explorer восстановит ее как отдельную БД.
Если у вас десктопная версия Microsoft Windows (7, 8, 8.1, 10), то мгновенное восстановление для нескольких баз нужно выполнять последовательно - ибо для десктопных версий поддерживается не более 20 подключений по TCP/IP одновременно. (Про это ограничение написано, например, в Microsoft Windows 10 License Terms.) Впрочем, тут у нас есть work-around - для параллельного восстановления нескольких баз можно использовать командлет Restore-VESQLIRDatabase .
Если планируется публикация базы на кластер SQL Server, то нужно обеспечить незанятое имя драйва на всех нодах кластера в соответствии с числом кластеризованных дисков в бэкапе. Для мгновенного восстановления незанятых имен потребуется вдвое больше.
Если планируется восстановление на момент времени с точной настройкой, убедитесь, что все ноды AlwaysOn availability group находятся в одном часовом поясе. И имейте в виду, что такой сценарий восстановления нельзя выполнить для импортированного бэкапа.
Для бэкапа логов транзакций нужно, чтобы имелся хотя бы один бэкап SQL Server-а. Поэтому сразу после полного восстановления SQL Server-а бэкапа логов у вас не будет. Кроме того, бэкап логов не поддерживается для ВМ с гостевой ОС Windows Server 2008 (и младше) на Hyper-V 2012 R2.
Graph Tables не поддерживаются для SQL Server 2017 и выше.
Пример сценария: Мгновенное восстановление для нескольких баз
Как и другие виды восстановления, этот сценарий выполняется с помощью мастера - его можно запустить, найдя в дереве нужный бэкап сервера или инстанса и выбрав на табе Database пункт меню Instant Recovery > Instant Recovery of databases с соответствующим уточнением:
latest state to original - на самое свежее состояние, в исходное место
point-in-time state to original - на конкретный момент времени в исходное место
to another server - на другой сервер
Затем на шаге Specify restore point можно уточнить, в какое состояние восстанавливать базу:
Restore to the point in time of the selected image-level backup - на момент создания выбранной точки восстановления (той, с которой вы сию минуту работаете в Veeam Explorer).
Если вы решили восстановиться на другой сервер (инстанс), то вам нужно будет указать этот сервер (инстанс) и аккаунт для доступа к нему.
Важно! У аккаунта должна быть роль sysadmin на выбранном сервере, а также как минимум права Read и Write на админскую шару (\\myserver\ADMIN$) на нём.
Подробнее про переключение будет рассказано ниже.
После того, как вы нажмете Recover, Veeam Explorer for Microsoft SQL Server начнет публикацию базы на выбранный сервер, а вам останется только наблюдать, как проходит сессия восстановления:
Кстати, здесь можно поменять настройки переключения на восстановленную базу, если вы передумали:
В дереве слева выбираем ноду Instant Recovery и под ней базу, которая сейчас опубликована.
Кликаем по ней правой кнопкой и выбираем Edit. В уже знакомом диалоге устанавливаем нужную настройку Switchover.
Переключение на восстановленную БД
Как было сказано выше, в ходе переключения для опубликованных в ходе мгновенного восстановления файлов базы выполняется detach, а база, скопированная из бэкапа, наоборот, аттачится к целевому инстансу SQL Server. После detach всегда выполняется "финальная" синхронизация файлов.
Важно! Если вы хотите восстановиться на исходный сервер, помните, что восстановленная база перезатрет исходную. Кроме того, в ходе всех этих операций база будет в офлайне.
После того, как файлы БД скопированы с маунт-сервера, Veeam Explorer проверяет размер не синхронизированных изменений маунт-кэша (где хранятся изменения БД, сделанные с момента публикации). Понятно, что размер маунт-кэша растёт всегда, а вот размер несинхронизированных нас интересует именно в свете того, как будет выполняться переключение.
Автоматическое переключение: :
Если несинхронизированных изменений в кэше меньше, чем 100 MB, то начинается переключение.
Если больше 100 MB, то выполняется синхронизация изменений и затем новая проверка кэша. Если стало менее 100 MB, то (см. предыдущий пункт) начинается переключение, в противном случае выполняется еще один цикл синхронизации, и так далее.
Этот режим переключения обеспечивает минимальный даунтайм.
Ручное переключение: После того, как файлы БД скопированы с маунт-сервера, Veeam Explorer раз в минуту проверяет размер несинхронизированных изменений в кэше. Если их больше 100 МВ или с момента последней синхронизации прошло более 5 минут, то Veeam Explorer начинает синхронизацию изменений. После ее завершения вы можете запустить переключение вручную - для этого в дереве слева выберите под узлом Instant Recovery опубликованную базу и из ее контекстного меню выберите Switchover now.
Переключение по расписанию: Аналогично режиму с ручным переключением, кэш проверяется каждую минуту. Если накопилось несинхронизированных изменений больше, чем 100 МВ, или с момента последней синхронизации прошло более 5 минут, то Veeam Explorer начинает синхронизацию изменений. После ее завершения Veeam Explorer ожидает указанного в расписании момента, чтобы начать переключение. Если он наступает до завершения синхронизации, программа дает закончить синхронизацию и лишь затем выполняет переключение.
После того, как переключение завершится, сессия Instant Recovery считается оконченной и будет закрыта.
Вот, в общем-то, и всё на сегодня. Вопросы и комментарии, как всегда, приветствуются.
Полезные ссылки
Руководство пользователя (на англ. языке)
Статья базы знаний о работе с зашифрованными БД
Видео о возможностях мгновенного восстановления (на русском языке)
