Як відновити базу даних SQL за допомогою відновлення командного рядка за допомогою NMM

У цій статті описано процедуру, якої слід дотримуватися для успішного відновлення бази даних SQL, резервну копію якої було створено за допомогою NMM за допомогою VDI

Відновлення бази даних SQL із резервної копії за допомогою командного рядка може знадобитися, якщо виникла проблема з відновленням із графічного інтерфейсу (користувач Networker для графічного інтерфейсу SQL сервера або плагіна SSMS). Або завдання перегляду з графічного інтерфейсу працює повільно, або необхідна база даних не відображається в графічному інтерфейсі для відновлення.


Як правило, при резервному копіюванні однієї бази даних створюються наступні набори збережень:

Повна резервна копія однієї БД матиме такі збереження:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:26:41 119 MB 3209027663 cb full MSSQL$FINANCE:testdb ==> Повне резервне копіювання saveset
SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:29:16 5 КБ 3192250597 cb incr MSSQL$FINANCE: testdb ==> Набір збереження метаданих.


Інкрементна резервна копія однієї бази даних матиме такі збереження:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:34:14 PM 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb ==> Збереження резервної копії
журналу SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:40:31 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb ==> набір збереження


метаданих Зверніть увагу, що кожна резервна копія має набір збереження метаданих, який завжди створюється на рівні 'incr' і зазвичай дуже малий. Цей набір збережень містить інформацію, яка дозволяє побачити список БД у графічному інтерфейсі "Networker User for SQL server". Цей набір збережень створюється з кожною резервною копією SQL VDI. Втім, можливо, що цього набору збережень може не існувати, якщо процес ручного клонування неправильно не включив цей набір збережень для клонування і якщо початкові набори збережень більше не існують. Якщо це так, то відновлення командного рядка є єдиним варіантом.

Після того, як ви визначите, з якої резервної копії вам потрібно відновитися, ви можете створити командний рядок. Нижче наведено приклад команди відновлення:

nsrsqlrc -s nsr-server -c sql12srv1 -t "25.05.2016 13:34:14" -d "MSSQL$FINANCE:testdb-recovered" -C " 'testdb' = 'c:\recover\testdb.mdf', 'testdb_log' = 'c:\recover\testdb_log.ldf', 'testdb_log1' = 'c:\recover\testdb_log1.ldf'" "MSSQL$FINANCE:testdb"

У наведеному вище варіанті command-s

вказати ім'я сервера Networker,
Параметр -c використовується для визначення початкового клієнта (якщо відновлення виконується на вузлі, відмінному від початкового клієнта),
-d вказати цільову базу даних для відновлення. Ця БД не існуватиме. Процес відновлення створить БД у цільовому екземплярі.
-C визначає, що це відновлення копії. Параметри після -C визначають логічні назви файлів у базі даних.  Зауважте, що ці імена мають точно збігатися з логічними іменами бази даних, що відновлюється.  Якщо база даних існує, то виконайте властивості назви БД з графічного інтерфейсу SSMS і загляньте в розділ 'Files'.

Якщо відновлення виконується на кластерному сервері SQL, додайте "-A "virtual-Server name" " до команди відновлення.

Останнім компонентом команди є ім'я бази даних, що відновлюється, наприклад MSSQL$
FINANCE:testdb

Якщо ви не впевнені в логічних іменах файлів бази даних, ви можете надати неповну команду, як показано нижче:

nsrsqlrc -s nsr-server -c sql12srv1 -t "25.05.2016 13:34:14" -d "MSSQL$FINANCE:testdb-recovered" -C " 'mydb' = 'c:\ recover\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(pid 2144):Час початку: Ср травня 25 15:37:42 2016
43621:(pid 2144):Ім'я комп'ютера: SQL12SRV1 Ім'я користувача: administrator
NSR_CLIENT: sql12srv1.jets.local;
                  NSR_SERVER: nsr-сервер;
37725:(pid 2144):Відновлення бази даних 'testdb' у 'testdb-recovered' ...
142468:(PID 2144):[2292]NSR/db_apps/BSMSQL/rcstripes.c(222): Пошук резервної копії для saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Пропущено переміщення логічного файлу testdb.
37945:(pid 2144):Пропущено переміщення логічного файлу testdb_log.
37945:(pid 2144):Пропущено переміщення для логічного файлу testdb_log1.
37946:(pid 2144):Немає логічного файлу з ім'ям mydb у вихідній базі даних
29401:(pid 2144):D помилка списку переміщення файлів atabase. Фактичний список файлів:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log.ldf
37947:(pid 2144):       testdb_log1 = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
142468:(pid 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Пошук резервної копії для saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Пропущено переміщення логічного файлу testdb.
37945:(pid 2144):Пропущено переміщення логічного файлу testdb_log.
37945:(pid 2144):Пропущено переміщення логічного файлу testdb_log1.
37946:(pid 2144):Немає логічного файлу з ім'ям mydb у вихідній базі даних
29401:(pid 2144):D помилка списку переміщення файлів atabase. Фактичний список файлів:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log.ldf
37947:(pid 2144):       testdb_log1 = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
Операція відновлення завершена з помилками. Зверніться до файлу журналу резервного копіювання модуля для отримання детальної інформації. невідома помилка XBSA 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442): Введення cleanUp(). nsr/db_apps/bsmsql/rcovmain.cpp(500): Вихід cleanUp().
43709:(pid 2144):Час зупинки: Ср травня 25 15:37:49 2016


***********************

У наведеній вище команді я дав випадкове логічне ім'я 'mydb', і команда випльовує справжнє логічне ім'я файлів БД та їх початкове розташування. Ці відомості можна використовувати для створення команди відновлення. Зауважте, що вам слід вказати інший шлях для відновлення даних. Ви не можете і не повинні вказувати вихідний шлях у команді відновлення, щоб уникнути ризику перезапису наявних даних.

Час резервного копіювання для відновлення можна отримати за допомогою команди mminfo. Можна скористатися або збереженням, як показано у виведених даних, або ви можете створити звіт про nsavetime і використати цей час.

Наприклад:
mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday"

SQLbackups.001 Домен даних sql12srv1 25.05.2016 13:26:41 119 MB 3209027663 cb full MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:29:16 5 КБ 3192250597 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Домен даних sql12srv1 25.05.2016 13:34:14 PM 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Домен даних sql12srv1
25.05.2016 13:40:31 5 КБ 3125142409 cb incr MSSQL$FINANCE:testdb

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday" -r volume,client,sumflags,sumsize,level,savetime(25),nsavetime,name

SQLbackups.001 sql12srv1 cb 119 MB Повністю 25.05.2016 13:26:41 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB вкл 25.05.2016 13:29:16 1464197356 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 1320 MB incr 25.05.2016 13:34:14 1464197654 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 25.05.2016 13:40:31 1464198031 MSSQL$FINANCE:testdb

Примітка: ви можете вказати nsavetime/savetime для набору збереження метаданих або фактичного набору збереження даних. Будь-який з них спрацює.

Сценарій 2:

Якщо резервні копії зареєстровані в базі даних носіїв без імен БД, то час необхідного резервного копіювання буде не таким очевидним. Наприклад, усі резервні копії БД мають однакові назви наборів збережень, як показано нижче:

SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:43:15 151 КБ 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:45:26 PM 151 KB 2655391455 cb incr MSSQL$FINANCE:

З наведеного вище не можна сказати, який набір збережень містить потрібну вам резервну копію.

Якщо існує набір для збереження даних medata, то резервні копії можна буде переглядати з графічного інтерфейсу, і ви можете знайти ім'я бази даних і час резервного копіювання з графічного інтерфейсу. Наприклад, якщо потрібна DB24, графічний інтерфейс показує час резервного копіювання як «25.05.2016 16:49». 



Якщо набору збереження метаданих немає, вам потрібно буде виконати команду nsrinfo, щоб знайти час збереження для відновлення. Наприклад, якщо mminfo показує набори збережень, як показано нижче:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 4:4:43:15 PM 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:45:26 151 KB 2655391455 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:47:34 PM 151 KB 2638614367 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:49:42 151 KB 2621837279 cb incr MSSQL$FINANCE:

SQLbackups.001 Data Domain sql12srv1 25.05.2016 4:4:11:50 PM 151 KB 2605060191 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:53:58 151 KB 2588283103 cb incr MSSQL$FINANCE:

Запустіть nsrinfo на час збереження, як показано нижче, щоб отримати інформацію про базу даних, яка є частиною save set:

nsrinfo -n mssql -t "25.05.2016 16:43:15" sql12srv1
скануючий клієнт 'sql12srv1' для savetime 1464208995(25.05.2016 16:43:15) з простору
імен mssql MSSQL$FINANCE:/ DB21
MSSQL$FINANCE:/DB21%/files.1464208995.1464209044
Знайдено

2 об'єкти nsrinfo -n mssql -t "25.05.2016 16:49:42" sql12srv1
скануючий клієнт 'SQL12SRV1' для збереження 1464209382(25.05.2016 16:49:42) з простору
імен mssql MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
Знайдено

2 об'єктиОскільки набори збереження не показують імена БД, вищесказане може бути спробою і помилкою, у випадку, коли набору збереження метаданих не існує. Використовуйте приблизний розмір бази даних як підказку, щоб звузити запит nsrinfo до декількох наборів збережень.