Restauration d’une base de données SQL à l’aide de la restauration par ligne de commande avec NMM

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions


Cet article documente la procédure à suivre pour une restauration réussie d’une base de données SQL qui a été sauvegardée avec NMM à l’aide de VDI

La restauration d’une base de données SQL à partir de la sauvegarde à l’aide de la ligne de commande peut être nécessaire en cas de problème avec la restauration à partir de l’interface utilisateur (utilisateur NetWorker pour l’interface utilisateur SQL Server ou le plug-in SSMS). La tâche de navigation à partir de l’interface graphique est lente ou la base de données requise n’est pas visible dans l’interface utilisateur pour la restauration.


Typiquement, les savesets suivants sont créés lorsqu’une seule base de données est sauvegardée :

Une sauvegarde complète d’une seule base de données aura les savesets suivants :
SQLbackups.001 Data Domain sql12srv1 5/25/2016 1 :26 :41 PM 119 MB 3209027663 cb full MSSQL$FINANCE :testdb ==> Full backup saveset
SQLbackups.001 Data Domain sql12srv1 5/25/2016 1 :29 :16 PM 5 KB 3192250597 cb incr MSSQL$FINANCE : testdb ==> saveset de métadonnées.


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


Notez que chaque sauvegarde dispose d’un saveset de métadonnées, qui est toujours créé au niveau 'incr' et qui est normalement très petit. Ce saveset contient des informations qui permettent d’afficher la liste des bases de données dans l’interface utilisateur « NetWorker User for SQL Server ». Ce saveset est créé avec chaque sauvegarde VDI SQL. Toutefois, il est possible que ce saveset n’existe pas si le processus de clonage manuel n’a pas inclus de manière incorrecte ce saveset pour le clonage et si les savesets d’origine n’existent plus. Si c’est le cas, la restauration par ligne de commande est la seule option.

Une fois que vous avez déterminé à partir de quelle sauvegarde vous devez effectuer la restauration, vous pouvez construire la ligne de commande. Vous trouverez ci-dessous un exemple de commande de restauration :

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"

Dans la commande

ci-dessus, l’option permet de spécifier le nom du serveur NetWorker,
-c permet de spécifier le client source (si la restauration est effectuée sur un hôte autre que le client source),
-d spécifie la base de données de destination vers laquelle effectuer la restauration. Cette base de données n’existera pas. Le processus de restauration crée la base de données sur l’instance cible.
-C spécifie qu’il s’agit d’une restauration de copie. Les paramètres après -C spécifient les noms logiques des fichiers de la base de données.  Notez que ces noms doivent correspondre exactement aux noms logiques de la base de données en cours de restauration.  Si la base de données existe, enregistrez les propriétés sur le nom de la base de données à partir de l’interface utilisateur de SSMS et regardez sous « Fichiers ».

Si la restauration est effectuée sur un serveur SQL en cluster, ajoutez « -A « virtual-server name » » à la commande de restauration.

Le dernier composant de la commande est le nom de la base de données en cours de restauration, par exemple MSSQL$
FINANCE :testdb

Si vous n’êtes pas sûr des noms logiques des fichiers de base de données, vous pouvez fournir une commande incomplète comme suit :

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 Nom d’utilisateur : administrator
NSR_CLIENT : sql12srv1.jets.local ;
                  NSR_SERVER : nsr-server ;
37725 :(pid 2144) :Restauration de la base de données 'testdb' dans 'testdb-recovered' ...
142468 :(pid 2144) :[2292]nsr/db_apps/bsmsql/rcstripes.c(222) : Finding backup for saveset MSSQL$FINANCE :/testdb.
37945 :(pid 2144) :Missing relocation for logical file testdb.
37945 :(pid 2144) : migration manquante pour le testdb_log de fichier logique.
37945 :(pid 2144) :Missing relocation for logical file testdb_log1.
37946 :(pid 2144) :Aucun fichier logique nommé mydb dans la base de données
d’origine 29401 :(pid 2144):D atabase file relocation list error. La liste actuelle des fichiers est :
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) : Finding backup for saveset MSSQL$FINANCE :/testdb.
37945 :(pid 2144) :Missing relocation for logical file testdb.
37945 :(pid 2144) :Missing relocation for logical file testdb_log.
37945 :(pid 2144) :Migration manquante pour le testdb_log1 de fichier logique.
37946 :(pid 2144) :Aucun fichier logique nommé mydb dans la base de données
d’origine 29401 :(pid 2144):D atabase file relocation list error. La liste actuelle des fichiers est :
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

Restore operation finished with error(s). Pour plus d’informations, reportez-vous au fichier log de sauvegarde du module. unknown XBSA error 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442) : Entrée cleanUp(). nsr/db_apps/bsmsql/rcovmain.cpp(500) : Sortie de cleanUp().
43709 :(pid 2144) :Stop time : Wed May 25 15 :37 :49 2016


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

Dans la commande ci-dessus, j’ai donné un nom logique aléatoire 'mydb' et la commande recrache le nom logique réel des fichiers de base de données et l’emplacement d’origine de ceux-ci. Vous pouvez utiliser ces informations pour créer votre commande de restauration. Notez que vous devez fournir un chemin différent pour restaurer les données. Vous ne pouvez pas et ne devez pas fournir le chemin source d’origine dans la commande de restauration afin d’éviter le risque d’écraser les données existantes.

Le temps de sauvegarde pour la restauration peut être obtenu à partir de la commande mminfo. Il est possible d’utiliser le paramètre savetime, tel qu’indiqué dans la sortie, ou vous pouvez créer un rapport sur nsavetime et utiliser ce temps à la place.

e.g :

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/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

Remarque : vous pouvez spécifier nsavetime/savetime du saveset de métadonnées ou du saveset de données réel. L’une ou l’autre de ces options fonctionnera.

Scénario 2 :

Si les sauvegardes sont enregistrées dans la base de données des supports sans les noms de base de données, l’heure de la sauvegarde requise n’est pas aussi évidente. For example, all DB backups have the same save set names as below :

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 :

De ce qui précède, on ne peut pas dire quel saveset a la sauvegarde dont vous avez besoin.

Si le saveset de données medata existe, les sauvegardes sont accessibles à partir de l’interface graphique et vous pouvez trouver le nom de la base de données et le temps de sauvegarde à partir de l’interface graphique. Par exemple, si DB24 était requis, l’interface graphique affiche l’heure de sauvegarde comme suit : « 5/25/2016 4 :49 PM ». 

kA5j0000000TNJYCA4_1_0

Si le saveset de métadonnées n’existe pas, vous devez exécuter la commande nsrinfo pour trouver l’heure d’enregistrement de la restauration. Par exemple, si mminfo affiche les savesets comme ci-dessous :

SQLbackups.e.g. 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 :

Run nsrinfo on the save times as below to get info on the DB that are are 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) from the 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 objets trouvés

Étant donné que les savesets n’affichent pas les noms de base de données, ce qui précède peut être un peu d’essais et d’erreurs, dans le scénario où le saveset de métadonnées n’existe pas. Utilisez la taille approximative de la base de données comme indice pour restreindre la requête nsrinfo à quelques savesets.

Article Properties
Article Number: 000022417
Article Type: How To
Last Modified: 09 Aug 2022
Version:  4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.