Slik gjenoppretter du en SQL-database ved hjelp av kommandolinjegjenoppretting med NMM

Denne artikkelen dokumenterer fremgangsmåten som skal følges for en vellykket gjenoppretting av en SQL-database som ble sikkerhetskopiert med NMM ved hjelp av VDI

Gjenoppretting av en SQL-database fra sikkerhetskopien ved hjelp av kommandolinjen kan være nødvendig hvis det er et problem med gjenoppretting fra GUI (NetWorker-bruker for SQL-server GUI eller SSMS-plugin). Enten er surfeoppgaven fra GUI treg, eller den nødvendige databasen er ikke synlig i GUI for gjenoppretting.


Vanligvis opprettes følgende lagringssett når en enkelt DB sikkerhetskopieres:

En fullstendig sikkerhetskopi av en enkelt DB vil ha følgende savesets:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:26:41 PM 119 MB 3209027663 cb full MSSQL$FINANCE:testdb ==> Full backup saveset
SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:29:16 PM 5 KB 3192250597 cb incr MSSQL$FINANCE: testdb ==> metadata saveset.


En inkrementell sikkerhetskopi av én enkelt DB vil ha følgende savesets:SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:34:14 PM 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb ==> Log backup saveset
SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:40:31 PM 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb ==> metadata saveset


Legg merke til at hver sikkerhetskopi har et metadatalagringssett, som alltid opprettes som INCR-nivå og vanligvis er svært lite.
Dette lagringssettet inneholder informasjon som gjør det mulig å se DB-oppføringen i det grafiske grensesnittet "Networker User for SQL server". Dette lagringssettet opprettes med hver SQL VDI-sikkerhetskopi. Det er imidlertid mulig at dette lagringssettet kanskje ikke finnes hvis manuell kloneprosess feilaktig ikke inkluderte dette lagringssettet for kloning, og hvis de opprinnelige lagringssettene ikke lenger eksisterer. Hvis dette er tilfelle, er kommandolinjegjenoppretting det eneste alternativet.

Når du har bestemt hvilken sikkerhetskopi du trenger å gjenopprette fra, kan du konstruere kommandolinjen. Nedenfor er et eksempel på en gjenopprettingskommando:

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"

I kommando-s-alternativet

ovenfor er å spesifisere NetWorker-servernavnet,
-c alternativet brukes til å spesifisere kildeklienten (hvis gjenopprettingen blir gjort på en annen vert enn kildeklienten),
-d spesifisere destinasjonen DB å gjenopprette til. Denne DB vil ikke eksistere. Gjenopprettingsprosessen oppretter DB på målforekomsten.
-C angir at dette er en kopigjenoppretting. Parameterne etter -C angir de logiske navnene på filene i databasen.  Vær oppmerksom på at disse navnene må samsvare nøyaktig med de logiske navnene på databasen som gjenopprettes.  Hvis databasen finnes, gjør du egenskaper på DB-navnet fra SSMS GUI og se under 'Filer'.

Hvis gjenopprettingen utføres på en SQL-server i klynge, legger du til "-A" virtuelt servernavn "" i gjenopprettingskommandoen.

Den siste komponenten i kommandoen er navnet på DB blir gjenopprettet f.eks MSSQL $
FINANCE: testdb

Hvis du ikke er sikker på hva de logiske navnene på databasefilene er, kan du gi en ufullstendig kommando som nedenfor:

nsrsqlrc -s nsr-server -c sql12srv1 -t "5/25/2016 13:34:14 PM" -d "MSSQL $ FINANCE: testdb-recovered" -C " 'mydb' = 'c: \ recover\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(pid 2144):Starttid: Wed May 25 15:37:42 2016
43621:(pid 2144):Computer Name: SQL12SRV1 Brukernavn: administrator
NSR_CLIENT: sql12srv1.jets.local;
                  NSR_SERVER: nsr-server;
37725: (pid 2144):Gjenopprette databasen 'testdb' til 'testdb-gjenopprettet' ...
142468:(pid 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Finne sikkerhetskopiering for saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Manglende flytting for logisk fil testdb.
37945:(pid 2144):Manglende flytting for logisk fil testdb_log.
37945:(pid 2144):Manglende flytting for logisk fil testdb_log1.
37946:(pid 2144):Ingen logisk fil med navnet mydb i opprinnelig database
29401:(pid 2144):D atabase file relocation list error. Faktisk filliste er:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Programfiler\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Programfiler\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
142468:(pid 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Finne sikkerhetskopiering for saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Manglende flytting for logisk fil testdb.
37945:(pid 2144):Manglende flytting for logisk fil testdb_log.
37945:(pid 2144):Manglende flytting for logisk fil testdb_log1.
37946:(pid 2144):Ingen logisk fil med navnet mydb i den opprinnelige databasen
29401:(pid 2144):D atabase-filflyttingslistefeil. Faktisk filliste er:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Programfiler\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Programfiler\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
Gjenopprettingsoperasjonen ble fullført med feil(er). Se loggfilen for sikkerhetskopiering av modulen for mer informasjon. ukjent XBSA-feil 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442): Entering cleanUp(). nsr/db_apps/bsmsql/rcovmain.cpp(500): Avslutter cleanUp().
43709:(pid 2144):Stop time: Ons 25. mai 15:37:49 2016


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

I kommandoen ovenfor ga jeg et tilfeldig logisk navn 'mydb' og kommandoen spytter ut det faktiske logiske navnet på DB-filene og den opprinnelige plasseringen av dem. Du kan bruke denne informasjonen til å bygge gjenopprettingskommandoen. Du må angi en annen bane for å gjenopprette dataene til. Du kan ikke og bør ikke oppgi den opprinnelige kildebanen i gjenopprettingskommandoen for å unngå risikoen for å overskrive eksisterende data.

Sikkerhetskopieringstiden for gjenoppretting kan hentes fra mminfo-kommandoen. Enten kan lagringstiden som vises i utdataene brukes, eller du kan rapportere om nsavetime og bruke denne tiden i stedet.

e.g:

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= i går"

SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:26:41 PM 119 MB 3209027663 cb full MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:29:16 PM 5 KB 3192250597 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:34:14 PM 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 5/25/2016 13:40:31 PM 5 KB 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 5/25/2016 13:26:41 PM 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 5/25/2016 13:29:16 PM 1464197356 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 1320 MB incr 5/25/2016 13: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

Du kan angi nsavetime/savetime for enten metadatalagringssettet eller settet med lagring av faktiske data. Hver av disse vil fungere.

Scenario 2:

Hvis sikkerhetskopiene er registrert i media db uten DB-navnene, vil tidspunktet for den nødvendige sikkerhetskopien ikke være like åpenbart. For eksempel har alle DB-sikkerhetskopier de samme lagringssettnavnene som nedenfor:

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

Fra ovenstående kan man ikke fortelle hvilket lagringssett som har sikkerhetskopien du trenger.

Hvis medata-datalagringssettet eksisterer, kan sikkerhetskopiene bla gjennom fra GUI-en, og du kan finne DB-navnet og sikkerhetskopieringstiden fra GUI-en. F.eks. hvis DB24 var nødvendig, viser GUI sikkerhetskopieringstiden som "5/25/2016 4:49 PM". 



Hvis metadatalagringssettet ikke er der, må du kjøre nsrinfo-kommandoen for å finne lagringstiden for gjenopprettingen. f.eks. hvis mminfo viser savesets som nedenfor:
SQLbackups.001 Data Domain sql12srv1 5/25/2016 4::2016 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 16:53:58 PM 151 KB 2588283103 cb incr MSSQL$FINANCE:

Kjør nsrinfo om lagringstidene som nedenfor for å få informasjon om DB som er en del av lagringssettet:

nsrinfo -n mssql -t "5/25/2016 4:43:15 PM" sql12srv1
Scanning Client 'sql12srv1' for savetime 1464208995(5/25/2016 16:43:15 PM) fra mssql-navneområdet
MSSQL$FINANCE:/ DB21
MSSQL$FINANCE:/DB21%/files.1464208995.1464209044
2 objects found

nsrinfo -n mssql -t "5/25/2016 4:49:42 PM" sql12srv1
scanning client 'sql12srv1' for savetime 1464209382(5/25/2016 4:49:42 PM) fra mssql-navneområdet
MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
2 objekter funnet

Siden lagringssettene ikke viser DB-navnene, kan ovennevnte være litt prøving og feiling, i scenariet der metadatalagringssettet ikke eksisterer. Bruk den omtrentlige DB-størrelsen som en ledetråd for å begrense nsrinfo-spørringen til noen få lagringssett.