Сегодня расскажу про две возможности Commvault для резервного копирования MS SQL, которые незаслуженно обходят стороной: гранулярное восстановление и плагин Commvault для SQL Management Studio.  Базовые моменты настройки рассматривать не буду. Пост скорее для тех, кто уже умеет устанавливать агент, настраивать расписание, политики и пр. О том, как устроен Commvault и что он умеет, рассказывал в этом посте.

Гранулярное восстановление

Опция table level restore появилась в свойствах Subclient  относительно недавно. Она позволяет включить возможность восстановления таблиц из базы данных, при этом не восстанавливая из бэкапа всю базу данных. Это удобно, когда знаешь, где конкретно ошибка или потеря данных. При этом сама база большая и восстанавливать ее всю займет много времени.



У этой опции есть ограничения:

• Таблицы нельзя восстановить в исходную базу данных, только в другую.  
• Все таблицы восстанавливаются в схему dbo. Таблицу нельзя восстановить в пользовательскую схему.
• Поддерживается только локальная учетная запись SQL-сервера с правами системного администратора.
• Целевой сервер, куда восстанавливаем таблицу, должен работать на ОС Windows.
• На целевом сервере, помимо агента SQL, должны быть установлены Media Agent и Java Runtime Environment.
• База данных должна использовать Recovery model в режиме Full.
• Если включена опция гранулярного восстановления БД, пропадает возможность запускать задания на дифференциальное резервное копирование.  

Опция table-level-restore выключена.


Опция table-level-restore выключена.

В моей практике был случай, когда у клиента для SQL-сервера было настроено следующее расписание: один полный бэкап раз в неделю и 6 дифференциальных бэкапов в будние дни. Он включил функцию table-level-restore, и задания на дифференциальный бэкап отрабатывались с ошибкой.

Посмотрим, как же будет выглядеть само восстановление.

1. Запускаем восстановление на нужном агенте.



2. В появившемся окне переходим во вкладку Advanced Options. Выбираем SQL Granular Browse — View Content.



3. В открывшемся списке выбираем базу, из которой будем восстанавливать таблицу, и нажимаем Restore Granular.



4. В диалоговом окне настраиваем точку монтирования базы данных из файлов резервного копирования (что-то вроде технологии Instant Recovery).

Указываем:

• имя для временной базы данных;
• как долго держать данную точку восстановления в днях;
• сервер, куда мы будем монтировать базу данных. В списке будут доступны только сервера, выполняющие все необходимые условия, про которые говорил выше: c ОС Windows, установленными Media Agent и Java Runtime Environment и пр.

Нажимаем ОК.



5. В новом окне нажимаем на List Recovery Points.



6. Откроется список примонтированных точек восстановления. Если база данных большая, то придется подождать. Затем нажимаем Browse. Появится окно для просмотра таблиц из выбранной базы данных.



Пока формируется список, часто диалоговое Recovery Points закрывают, а потом не могут туда вернуться снова. Все просто: кликните правой кнопкой по инстансу SQL-сервера, где был запущен процесс монтирования точки восстановления. Перейдите в All Tasks и выберите List Recovery Points.



7. Если таблиц много, для их отображения потребуется некоторое время. Например, для базы данных на 40 ГБ список формируется минут десять. Выбираем нужную таблицу, нажимаем Recover All Selected.



8. В новом окне выбираем базу, куда будем восстанавливать таблицу(ы). В нашем случае — это база GPI TEST.



9. После завершения восстановления в базе GPI TEST появятся выбранные таблицы.



После восстановления таблицы во временную базу данных ее можно перенести в исходную базу данных средствами Management Studio.

Plug-in от Commvault для SQL Management Studio

Администраторы баз данных не всегда имеют доступ в систему резервного копирования (СРК). Иногда нужно сделать что-то срочно, а администратора СРК нет на месте. С помощью плагина Commvault  для SQL Management Studio администратор БД сможет выполнить базовые действия по резервному копированию и восстановлению данных.

QL Management Studio Version	Command
SQL 2008 R2	CvSQLAddInConfig.exe /i 10 /r
SQL 2012	CvSQLAddInConfig.exe /i 11 /r
SQL 2014	CvSQLAddInConfig.exe /i 12 /r
SQL 2016	CvSQLAddInConfig.exe /i 13 /r
SQL 2017	CvSQLAddInConfig.exe /i 14 /r

Версии SQL-серверов, которые поддерживают Commvault Plug-in и команды, которые активируют работу плагина. Плагин поддерживается только на 64-битной версии ОС Windows.

1. Выполняем команду, которая соответствует нашей версии SQL server:



2. Теперь в Management Studio стали доступны опции по резервному копированию и восстановлению. Для этого нужно кликнуть правой кнопкой мыши на нужную базу данных.
У администратора, таким образом, появилась возможность напрямую взаимодействовать с резервными копиями данной базы данных без консоли Commvault и обращений к администратору СРК.



3. При запуске любой из доступных функций данного меню появится окно с запросом логина и пароля. Для подключения к CommServe используется SSO или же любая другая учетная запись из раздела Security в Commserve (Commcell login).





4. Если учетные данные были введены правильно и прав доступа хватает, администратор БД может:

• запустить внеочередное резервное копирование (Backup);
• восстановить базу из бэкапа (Restore);
• просмотреть историю выполненных заданий (View History) и прогресс по заданиям в процессе выполнения (Job monitor).

Вот так  в Management Studio выглядит история выполненных заданий резервного копирования по выбранной базе данных.


Меню для восстановления базы данных. Оно даже не отличается от меню консоли.

На этом все об этих двух возможностях агента SQL от Commvault. Добавлю, что резервное копирование средствами Commvault больше подойдет тем, у кого на обслуживании десятки серверов, с несколькими инстансами и БД, все это, возможно, на разных площадках и требует настройки разного расписания, глубины и пр. Если у вас пара серверов, то для бэкапа хватит и штатных средств MS SQL.

Источник