Как восстановить базу данных SQL с помощью восстановления из командной строки с помощью NMM

В этой статье описана процедура, которую необходимо выполнить для успешного восстановления базы данных SQL, резервная копия которой была создана с помощью NMM с помощью VDI

. Восстановление базы данных SQL из резервной копии с помощью командной строки может потребоваться при возникновении проблемы с восстановлением из графического интерфейса пользователя (пользователя NetWorker для графического интерфейса SQL Server или подключаемого модуля SSMS). Либо задача просмотра из графического интерфейса работает медленно, либо нужная база данных не отображается в графическом интерфейсе пользователя для восстановления.


Как правило, при резервном копировании одной БД создаются следующие наборы сохранения:

Полная резервная копия одной БД содержит следующие наборы сохранения:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:26:41 119 МБ 3209027663 cb полный MSSQL$FINANCE:testdb ==> Набор полной резервной копии
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 1320 Мбайт 3141919250 cb incr MSSQL$FINANCE:testdb ==> Сохранить
резервную копию журнала SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:40:31 5 КБ 3125142409 cb incr MSSQL$FINANCE:testdb ==> набор


сохранений метаданных Обратите внимание, что у каждой резервной копии есть набор сохранений метаданных, который всегда создается на уровне 'incr' и обычно очень мал. Этот набор сохранений содержит информацию, которая позволяет увидеть список БД в графическом интерфейсе пользователя NetWorker для SQL Server. Этот набор данных сохранения создается при каждом резервном копировании SQL VDI. Однако существует вероятность того, что этот набор сохранений может не существовать, если в процессе клонирования вручную он не был включен для клонирования и если исходные наборы сохранений больше не существуют. В этом случае восстановление из командной строки будет единственным вариантом.

После того, как вы определили, из какой резервной копии вам нужно выполнить восстановление, вы можете создать командную строку. Ниже приведен пример команды восстановления:

nsrsqlrc -s nsr-server -c sql12srv1 -t "5/25/2016 13:34:14 PM" -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"

В приведенной выше команде

-s можно указать имя сервера NetWorker,
-c используется для указания исходного клиента (если восстановление выполняется на хосте,
отличном от исходного клиента), -d указывает целевую базу данных для восстановления. Этой базы данных не будет. В процессе восстановления база данных будет создана в целевом экземпляре.
-C указывает, что это восстановление путем копирования. Параметры после -C задают логические имена файлов в базе данных.  Обратите внимание, что эти имена должны точно совпадать с логическими именами восстанавливаемой базы данных.  Если база данных существует, сделайте свойства имени БД из графического интерфейса SSMS и найдите раздел «Файлы».

Если восстановление выполняется на кластеризованный сервер SQL, добавьте к команде восстановления пометку «-A "virtual-Server name"».

Последним компонентом в команде является имя восстанавливаемой базы данных, например MSSQL$
FINANCE:testdb

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

nsrsqlrc -s nsr-server -c sql12srv1 -t "25.05.2016 13:34:14 PM" -d "MSSQL$FINANCE:testdb-recovered" -C " 'mydb' = 'c:\ recover\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(pid 2144):Время начала: Ср Май 25 2016
15:37:42 43621:(pid 2144):Имя компьютера: SQL12SRV1 Имя пользователя: 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. ФИНАНСЫ\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. ФИНАНСЫ\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 мая 2016


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

15:37:49, я дал случайное логическое имя 'mydb', и команда выдала фактическое логическое имя файлов БД и их исходное расположение. Эту информацию можно использовать для создания команды восстановления. Обратите внимание, что необходимо указать другой путь для восстановления данных. Вы не можете и не должны указывать первоначальный исходный путь в команде восстановления, чтобы избежать риска перезаписи существующих данных.

Время резервного копирования для восстановления можно узнать с помощью команды mminfo. Можно использовать время сохранения, как показано в выходных данных, или создать отчет о nsavetime и использовать это время.

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

SQLbackups.001 Data Domain sql12srv1 25.05.2016 13:26:41 119 МБ 3209027663 cb полный MSSQL$FINANCE:testdb
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 1320 МБ 3141919250 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain 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 full 25.05.2016 13:26:41 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 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 151 КБ 2655391455 cb incr MSSQL$FINANCE:

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

Если существует набор для сохранения данных medata, то резервные копии будут доступны для просмотра из графического интерфейса, а имя базы данных и время резервного копирования вы сможете найти в графическом интерфейсе. Например, если требовалась DB24, в графическом интерфейсе отображается время резервного копирования «5/25/2016 4:49 PM». 



Если набор для сохранения метаданных отсутствует, необходимо выполнить команду nsrinfo, чтобы найти время сохранения для восстановления. Например, если mminfo показывает наборы сохранений, как показано ниже:
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 151 КБ 2655391455 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:47:34 151 КБ 2638614367 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:49:42 151 КБ 2621837279 cb incr MSSQL$FINANCE:

SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:51:50 151 КБ 2605060191 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25.05.2016 16:53:58 151 КБ 2588283103 cb incr MSSQL$FINANCE:

Выполните nsrinfo по времени сохранения, как показано ниже, чтобы получить информацию о БД, которая является частью набора сохранения:

nsrinfo -n mssql -t "25.05.2016 16:43:15" sql12srv1
сканирующий клиент sql12srv1 для времени сохранения 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" for savetime 1464209382(25.05.2016 16:49:42) из пространства
имен mssql MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
Найдено

2 объектовПоскольку наборы сохранений не показывают имена БД, вышеописанное может быть методом проб и ошибок в сценарии, когда набора сохранения метаданных не существует. Используйте приблизительный размер базы данных в качестве подсказки, чтобы сузить запрос nsrinfo до нескольких наборов сохранения.