Så här återställer du en SQL-databas med hjälp av kommandoradsåterställning med NMM

I den här artikeln beskrivs hur du går tillväga för en lyckad återställning av en SQL-databas som har säkerhetskopierats med NMM med hjälp av VDI

: Det kan vara nödvändigt att återställa en SQL-databas från säkerhetskopian med hjälp av kommandoraden om det uppstår problem med återställning från det grafiska användargränssnittet för Networker-användare för SQL-servern eller SSMS-plugin-programmet). Antingen är bläddringsuppgiften från det grafiska användargränssnittet långsam eller så visas inte den databas som krävs i det grafiska användargränssnittet för återställningen.


Vanligtvis skapas följande sparuppsättningar när en enskild databas säkerhetskopieras:

En fullständig säkerhetskopia av en enskild databas har följande sparade uppsättningar:
SQLbackups.001 Data Domain sql12srv1 2016-05-25 13:26:41 119 MB 3209027663 cb full MSSQL$FINANCE:testdb ==> Fullständig sparad
säkerhetskopia SQLbackups.001 Data Domain sql12srv1 2016-05-25 13:29:16 5 KB 3192250597 cb incr MSSQL$FINANCE: testdb ==> Sparade metadata.


En inkrementell säkerhetskopia av en enskild databas kommer att ha följande savesets:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 1:34:14 PM 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb ==> Log backup saveset
SQLbackups.001 Data Domain sql12srv1 5/25/2016 1:40:31 PM 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb ==> metadata saveset


Observera att varje säkerhetskopia har en metadatasparuppsättning, som alltid skapas som "incr"-nivå och normalt är mycket liten. Den här sparade uppsättningen innehåller information som gör det möjligt att se DB-listan i det grafiska användargränssnittet för Networker User for SQL Server. Den här sparade uppsättningen skapas med varje SQL VDI-säkerhetskopia. Det är dock möjligt att den här sparuppsättningen inte finns om den manuella kloningsprocessen felaktigt inte inkluderade den sparade uppsättningen för kloning och om de ursprungliga sparuppsättningarna inte längre finns. Om så är fallet är kommandoradsåterställning det enda alternativet.

När du har bestämt vilken säkerhetskopia du behöver återställa från kan du skapa kommandoraden. Nedan visas ett exempel på ett återställningskommando:

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

I ovanstående kommando-s

alternativ är att ange Networker-serverns namn,
-c används för att ange källklienten (om återställningen görs på en annan värd än källklienten),
-d ange måldatabasen att återställa till. Denna DB kommer inte att finnas. Återställningsprocessen skapar databasen på målinstansen.
-C anger att detta är en kopieringsåterställning. Parametrarna efter -C anger de logiska namnen på filerna i databasen.  Observera att dessa namn måste matcha de logiska namnen på den databas som återställs.  Om databasen finns gör du egenskaper på DB-namnet från SSMS GUI och tittar under "Filer".

Om återställningen görs till en klustrad SQL-server lägger du till "-A "virtual-Server name" " i återställningskommandot.

Den sista komponenten i kommandot är namnet på den databas som återställs, t.ex. MSSQL$
FINANCE:testdb

Om du inte är säker på vad de logiska namnen på databasfilerna är kan du ange ett ofullständigt kommando enligt nedan:

nsrsqlrc -s nsr-server -c sql12srv1 -t "5/25/2016 1:34:14 PM" -d "MSSQL$FINANCE:testdb-recovered" -C " 'mydb' = 'c:\ återställa\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(pid 2144):Starttid: Wed May 25 15:37:42 2016
43621:(pid 2144):Computer Name: SQL12SRV1 Användarnamn: administratör
NSR_CLIENT: sql12srv1.jets.local;
                  NSR_SERVER: nsr-server;
37725:(PID 2144):Återställer databasen 'testdb' till 'testdb-recovered' ...
142468:(PID 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Söka efter säkerhetskopia för sparad MSSQL$FINANCE:/testdb.
37945:(pid 2144):Flytt saknas för logisk fil testdb.
37945:(pid 2144):Flytt saknas för logisk fil testdb_log.
37945:(pid 2144):Flytt saknas för logisk fil testdb_log1.
37946:(pid 2144):Ingen logisk fil med namnet mydb i originaldatabasen
29401:(pid 2144):D atabase filflyttningslista fel. Faktisk fillista är:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. EKONOMI\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Program\Microsoft SQL Server\MSSQL11. EKONOMI\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Program\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
142468:(PID 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Söka efter säkerhetskopia för sparad MSSQL$FINANCE:/testdb.
37945:(pid 2144):Flytt saknas för logisk fil testdb.
37945:(pid 2144):Flytt saknas för logisk fil testdb_log.
37945:(pid 2144):Flytt saknas för logisk fil testdb_log1.
37946:(pid 2144):Ingen logisk fil med namnet mydb i originaldatabasen
29401:(pid 2144):D atabase filflyttningslista fel. Faktisk fillista är:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. EKONOMI\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Program\Microsoft SQL Server\MSSQL11. EKONOMI\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Program\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
Återställningsåtgärden slutfördes med fel. Mer information finns i loggfilen för modulens säkerhetskopiering. okänt XBSA-fel 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442): Anger cleanUp(). nsr/db_apps/bsmsql/rcovmain.cpp(500): Avslutar cleanUp().
43709:(pid 2144):Stopptid: Wed May 25 15:37:49 2016


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

I kommandot ovan gav jag ett slumpmässigt logiskt namn 'mydb' och kommandot spottar ut det faktiska logiska namnet på DB-filerna och den ursprungliga platsen för dem. Du kan använda den här informationen för att skapa återställningskommandot. Observera att du måste ange en annan sökväg att återställa data till. Du kan inte och bör inte ange den ursprungliga källsökvägen i återställningskommandot för att undvika risken att skriva över befintliga data.

Säkerhetskopieringstiden för återställning kan erhållas från kommandot mminfo. Antingen kan savetime som visas i utdata användas eller så kan du rapportera nsavetime och använda den här tiden i stället.

t.ex:

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday"

SQLbackups.001 Data Domain sql12srv1 5/25/2016 1:26:41 PM 119 MB 3209027663 cb full MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 5/25/2016 1:29:16 PM 5 KB 3192250597 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 5/25/2016 1:34:14 PM 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 2016-05-25 13:40:31 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb

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

SQLbackups.001 sql12srv1 cb 119 MB full 2016-05-25 13:26:41 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 5/25/2016 1:29:16 PM 1464197356 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 1320 MB incr 5/25/2016 1:34:14 PM 1464197654 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 5/25/2016 13:40:31 PM 1464198031 MSSQL$FINANCE:testdb

Observera att du kan ange nsavetime/savetime för antingen metadatasparuppsättningen eller den faktiska datasparuppsättningen. Båda dessa kommer att fungera.

Scenario 2:

Om säkerhetskopiorna registreras i mediedatabasen utan DB-namnen är tiden för den nödvändiga säkerhetskopieringen inte lika uppenbar. Till exempel har alla databassäkerhetskopior samma sparuppsättningsnamn som nedan:

SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:43:15 PM 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:45:26 PM 151 KB 2655391455 cb incr MSSQL$FINANCE:

Från ovanstående kan man inte se vilken sparuppsättning som har den säkerhetskopia du behöver.

Om medata-datasparuppsättningen finns kommer säkerhetskopiorna att vara bläddringsbara från GUI och du kan hitta DB-namnet och säkerhetskopieringstiden från GUI. T.ex. om DB24 krävdes visar det grafiska användargränssnittet säkerhetskopieringstiden som "5/25/2016 4:49 PM". 



Om sparuppsättningen för metadata inte finns där måste du köra kommandot nsrinfo för att hitta lagringstiden för återställningen. t.ex. om mminfo visar sparuppsättningarna enligt nedan:

SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:43:15 PM 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:45:26 PM 151 KB 2655391455 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:47:34 PM 151 KB 2638614367 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:49:42 PM 151 KB 2621837279 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:51:50 PM 151 KB 2605060191 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4:53:58 PM 151 KB 2588283103 cb incr MSSQL$FINANCE:

Kör nsrinfo på spartiderna enligt nedan för att få information om databasen som är en del av spara set:

nsrinfo -n mssql -t "5/25/2016 4:43:15 PM" sql12srv1
skanningsklient 'sql12srv1' för savetime 1464208995(5/25/2016 4:43:15 PM) från mssql-namnområdet
MSSQL$FINANCE:/ DB21
MSSQL$FINANCE:/DB21%/files.1464208995.1464209044
2 objekt hittades

nsrinfo -n mssql -t "5/25/2016 4:49:42 PM" SQL12SRV1
skanningsklient "sql12srv1" för savetime 1464209382(5/25/2016 4:49:42 PM) från mssql-namnområdet
MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
2 objekt hittades

Eftersom de sparade uppsättningarna inte visar DB-namnen kan ovanstående vara lite trial and error, i scenariot där metadatasparuppsättningen inte finns. Använd den ungefärliga DB-storleken som en ledtråd för att begränsa nsrinfo-frågan till några få sparade uppsättningar.