Мгновенное восстановление баз данных с Veeam

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

В 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 автоматически выполняет вот такие шаги:

  1. Останавливает публикацию базы.

  2. Использует содержимое кэша, чтобы синхронизировать восстановленную базу с той, которая была опубликована.

  3. Выполняет drop для опубликованной базы.

  4. Запускает восстановленную базу.

Примечание: Сессия мгновенного восстановления устойчива по отношению к отказам маунт-сервера, бэкап сервера или к сетевым проблемам. Если происходит такой сбой, то процесс застывает в режиме ожидания и пытается возобновить работу каждые 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 начнет публикацию базы на выбранный сервер, а вам останется только наблюдать, как проходит сессия восстановления:

Кстати, здесь можно поменять настройки переключения на восстановленную базу, если вы передумали: 

  1. В дереве слева выбираем ноду Instant Recovery и под ней базу, которая сейчас опубликована.

  2. Кликаем по ней правой кнопкой и выбираем 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 считается оконченной и будет закрыта.

Вот, в общем-то, и всё на сегодня. Вопросы и комментарии, как всегда, приветствуются.

Полезные ссылки

Руководство пользователя (на англ. языке)

Статья базы знаний о работе с зашифрованными БД

Видео о возможностях мгновенного восстановления (на русском языке)

Источник: https://habr.com/ru/company/veeam/blog/566274/


Интересные статьи

Интересные статьи

Прим. перев.: в этой статье сербский «инженер по масштабируемости» нагруженного онлайн-проекта в подробностях рассказывает о своем опыте оптимизации большой БД на базе MySQL. Проведена он...
Данных становится все больше. По исследованиям International Data Corporation (международная исследовательская компания) прирост объема хранимой в электронном виде информ...
Чтобы быстро решать вопросы пользователей без вмешательства человека, эффективный чат-бот требует огромного количества обучающих данных. Однако основное узкое место в разработке чат-бота ...
Некоторые компании проводят собеседования с online написанием кода. Требуется решить олимпиадную задачку на скорость. В таких условиях нет времени посмотреть подробности реализации структур дан...
Одной из «киллер-фич» 12й версии Битрикса была объявлена возможность отдавать статические файлы из CDN, тем самым увеличивая скорость работы сайта. Попробуем оценить практический выигрыш от использова...