Een SQL-database herstellen met behulp van opdrachtregelherstel met NMM

In dit artikel wordt de procedure beschreven die moet worden gevolgd voor een succesvol herstel van een SQL-database waarvan een back-up is gemaakt met NMM met behulp van VDI

Het herstellen van een SQL-database vanaf de back-up met behulp van de opdrachtregel kan nodig zijn als er een probleem is met het herstellen vanaf de GUI (Networker-gebruiker voor SQL Server GUI of de SSMS-plug-in). De browsetaak vanuit de GUI is traag of de vereiste database is niet zichtbaar in de GUI voor herstel.


Doorgaans worden de volgende savesets aangemaakt wanneer een back-up wordt gemaakt van een enkele DB:

Een volledige back-up van een enkele DB heeft de volgende savesets:
SQLbackups.001 Data Domain sql12srv1 25-5-2016 13:26:41 119 MB 3209027663 cb full MSSQL$FINANCE:testdb ==> Full backup saveset
SQLbackups.001 Data Domain sql12srv1 25-5-2016 13:29:16 5 KB 3192250597 cb incr MSSQL$FINANCE: testdb ==> metadata saveset.


A incremental backup of a single DB will have the following 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


Notice each backup has a metadata saveset, dat altijd wordt aangemaakt als 'incr' niveau en normaal gesproken erg klein is. Deze opslagset bevat informatie die het mogelijk maakt om de DB-vermelding in de GUI "Networker User for SQL Server" te zien. Deze opslagset wordt gemaakt bij elke SQL VDI-back-up. Het is echter mogelijk dat deze opslagset niet bestaat als het handmatige kloonproces deze opslagset voor klonen niet bevatte en als de oorspronkelijke opslagsets niet meer bestaan. Als dit het geval is, is opdrachtregelherstel de enige optie.

Zodra u hebt bepaald van welke back-up u moet herstellen, kunt u de opdrachtregel samenstellen. Hieronder ziet u een voorbeeld van een herstelopdracht:

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"

In de bovenstaande command-s

optie is het om de Networker-servernaam op te geven,
-c optie wordt gebruikt om de bronclient op te geven (als het herstel wordt uitgevoerd op een andere host dan de bronclient),
-d specificeer de doel-DB waarnaar moet worden hersteld. Deze DB zal niet bestaan. Tijdens het herstelproces wordt de database op de doelinstantie gemaakt.
-C geeft aan dat dit een kopieherstel is. De parameters na de -C specificeren de logische namen van de bestanden in de database.  Let op: deze namen moeten exact overeenkomen met de logische namen van de database die wordt hersteld.  Als de database bestaat, voer dan eigenschappen uit op de DB-naam van SSMS GUI en kijk onder 'Bestanden'.

Als het herstel wordt uitgevoerd op een geclusterde SQL-server, voegt u de "-A "virtuele-servernaam" " toe aan de herstelopdracht.

De laatste component in het commando is de naam van de DB die wordt hersteld, bijv. MSSQL$
FINANCE:testdb

Als u niet zeker weet wat de logische namen van de databasebestanden zijn, dan kunt u een onvolledige opdracht geven zoals hieronder:

nsrsqlrc -s nsr-server -c sql12srv1 -t "5/25/2016 1:34:14 PM" -d "MSSQL$FINANCE:testdb-recovered" -C " 'mydb' = 'c:\ recover\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(pid 2144):Start time: Wed May 25 15:37:42 2016
43621:(pid 2144):Computer Name: SQL12SRV1 Gebruikersnaam: beheerder
NSR_CLIENT: sql12srv1.jets.local;
                  NSR_SERVER: nsr-server;
37725:(pid 2144):Database 'testdb' herstellen in 'testdb-hersteld' ...
142468:(PID 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Back-up zoeken voor saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Ontbrekende verplaatsing voor logisch bestand testdb.
37945:(pid 2144):Ontbrekende verplaatsing voor logisch bestand testdb_log.
37945:(pid 2144):Ontbrekende verplaatsing voor logisch bestand testdb_log1.
37946:(pid 2144):Geen logisch bestand met de naam mydb in de originele database
29401:(pid 2144):D atabase file relocation list error. Actual file list is:
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): Back-up zoeken voor saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Ontbrekende verplaatsing voor logisch bestand testdb.
37945:(pid 2144):Ontbrekende verplaatsing voor logisch bestand testdb_log.
37945:(pid 2144):Ontbrekende verplaatsing voor logisch bestand testdb_log1.
37946:(pid 2144):Geen logisch bestand met de naam mydb in de originele database
29401:(pid 2144):D atabase file relocation list error. Actual file list is:
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
Herstelbewerking voltooid met fout(en). Raadpleeg het back-upbestand van de module voor meer informatie. unknown XBSA error 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442): Entering cleanUp(). nsr/db_apps/bsmsql/rcovmain.cpp(500): CleanUp() afsluiten.
43709:(pid 2144):Stoptijd: Wed May 25 15:37:49 2016


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

In het bovenstaande commando heb ik een willekeurige logische naam 'mydb' gegeven en het commando spuugt de werkelijke logische naam van de DB-bestanden en de oorspronkelijke locatie ervan uit. U kunt deze informatie gebruiken om uw herstelopdracht op te bouwen. Houd er rekening mee dat u een ander pad moet opgeven om de data naar te herstellen. U kunt en mag niet het oorspronkelijke bronpad opgeven in de herstelopdracht om te voorkomen dat bestaande gegevens worden overschreven.

De back-uptijd voor het terugzetten kan worden verkregen via de opdracht mminfo. U kunt de savetime gebruiken zoals weergegeven in de uitvoer, of u kunt rapporteren over nsavetime en in plaats daarvan deze tijd gebruiken.

Bijv:
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
5/25/2016 1: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 1:26:41 PM 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 5/25/5/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 1:40:31 PM 1464198031 MSSQL$FINANCE:testdb

Let op: U kunt de nsavetime/savetime van de metadata-saveset of de daadwerkelijke dataopslagset opgeven. Elk van deze zal werken.

Scenario 2:

Als de back-ups zijn geregistreerd in de media-db zonder de DB-namen, is het tijdstip van de vereiste back-up niet zo duidelijk. Bijvoorbeeld, alle DB back-ups hebben dezelfde save set namen als hieronder:

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:

Uit het bovenstaande kun je niet opmaken welke save set de back-up heeft die je nodig hebt.

Als de medata data save set bestaat, dan zijn de back-ups doorzoekbaar vanuit de GUI en kunt u de naam van de database en de back-uptijd vinden in de GUI. Bijvoorbeeld, als DB24 vereist was, geeft de GUI de back-uptijd weer als "5/25/2016 4:49 PM". 



Als de metadataopslagset er niet is, moet u de opdracht nsrinfo uitvoeren om de opslagtijd voor het herstel te vinden. bijv. als de mminfo de savesets als volgt toont:

SQLbackups.001 Data Domain sql12srv1 25-5-2016 16:43:15 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-5-2016 16:45:26 151 KB 2655391455 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-5-2016 16:47:34 151 KB 2638614367 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-5-2016 16:49:42 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:

Run nsrinfo on the save times as below to get info on the DB that's part of the save set:

nsrinfo -n mssql -t "5/25/2016 4:43:15 PM" sql12srv1
scanning client 'sql12srv1' for savetime 1464208995(5/25/2016 4:43:15 PM) van de mssql namespace
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) from the mssql namespace
MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
2 objects found

Aangezien de opslagsets de DB-namen niet weergeven, kan het bovenstaande een beetje vallen en opstaan zijn, in het scenario waarin de metadataopslagset niet bestaat. Gebruik de geschatte DB-grootte als een aanwijzing om de nsrinfo-query te beperken tot een paar opslagsets.