Резервне копіювання MS SQL: пара корисних функцій Commvault, про які не всі знають

Сьогодні розповім про дві можливості 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. У вікні, що з'явилося, переходимо у вкладку Додаткові параметри. Вибираємо SQL Granular Browse - View Content.


3. У списку вибираємо базу, з якої будемо відновлювати таблицю, і натискаємо Restore Granular.


4. У діалоговому вікні налаштовуємо точку монтування бази даних із файлів резервного копіювання (щось на зразок технології Instant Recovery).
Вказуємо:

• ім'я для тимчасової бази даних;
• як довго тримати цю точку відновлення днями;
• сервер, куди ми монтуватимемо базу даних. У списку будуть доступні лише сервери, які виконують всі необхідні умови, про які говорив вище: c Windows, встановлені Media Agent і Java Runtime Environment та ін.

Натискаємо ОК.


5. У новому вікні натискаємо List Recovery Points.


6. Відкриється список точок відновлення. Якщо база даних велика, доведеться почекати. Потім натискаємо перегорнути. З'явиться вікно, щоб переглянути таблиці з вибраної бази даних.


Поки формується список, часто діалогове 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.

Джерело: documentation.commvault.com

Джерело: habr.com