Problème pour récupérer un backup SQL Server 2008

Bonjour,

J'ai un collègue qui tente désespérément de récupérer une base de données sur le serveur d'un client.

Le serveur fait tourner SQL Server 2008 Express US.
Je lui ai indiqué deux méthodes :
- Stopper les services du serveur, puis recopier les MDF et LDF afin de les remonter sur sa machine
- Faire un backup de la base, et le restaurer sur sa machine

Il se heurte à des problèmes liés à la fois à une méconnaissance de l'outil, et liés aux mécanismes de sécurité mis en place chez le client.

Il accède en VPN à un TSE chez le client.
Ce TSE chez le client accède alors en TSE au serveur de la base de données (si j'ai bien compris), ainsi qu'en partage Windows pour les fichiers.

Il s'agit d'un TSE "basique" : pas de copier/coller de fichier à travers TSE.

Il doit donc récupérer les fichiers en les uploadant par FTP à travers le VPN, ou en les envoyant sur un site HTTP genre dl.free.fr

Dans tous les cas :
- La recopie des MDF/LDF échoue.
- Le backup est corrompu.

Hier, je lui ai proposé de faire un ZIP multi-volume du fichier BAK, afin de limiter les problèmes de transfert.

Rien n'y fait, impossible de restaurer le fichier de backup : son poste lui dit que la sauvegarde est corrompue.

Il utilise SQL Server 2008 FR.
Sa version est à peine plus récente que celle du serveur (genre il a le SP2 et le serveur seulement le SP1 ?)

Est-ce que vous avez une idée pour l'aider ?

Je lui envoie le lien vers ce topic, en espérant qu'il va venir donner plus de détails...

Merci d'avance !

Il ne s'agit visiblement pas d'un problème SQL Server, mais de fichier corrompus. C'est vers les outils intermédiaires qu'il faut se tourner.
PS : un backup est souvent plus rapide parce que plus petit à transférer.
Pour savoir s'il est valide, lancer la commande T SQL :
RESTORE VERIFYONLY FROM DISK = '???'
ou ??? est le chemin/fichier du backup.

A +

J'y comprends rien...

J'ai récupéré le backup.

J'ai lancé la commande :

Code:

---

RESTORE VERIFYONLY FROM DISK = 'c:\in\Devis.bak'

---

J'obtiens ce message :

Code:

---

1 2 3 4

Attempting to restore this backup may encounter storage space problems. Subsequent messages will provide details. The path specified by "D:\Program Files\Microsoft SQL Server\MSSQL10.EXPRESS2008\MSSQL\DATA\Devis.mdf" is not in a valid directory. Directory lookup for the file "D:\Program Files\Microsoft SQL Server\MSSQL10.EXPRESS2008\MSSQL\DATA\Devis_1.ldf" failed with the operating system error 21(failed to retrieve text for this error. Reason: 15105). The backup set on file 1 is valid.

---

C'est plutôt bon signe.

Y'a une manip particulière pour changer les dossiers de destination lors du restore ?

Bonjour,

Citation:

---

Envoyé par StringBuilder

Y'a une manip particulière pour changer les dossiers de destination lors du restore ?

---

Oui ;)

Utilisez FILELISTONLY pour trouver le nom logique (LogicalName) des fichiers à restaurer.

Code:

---

RESTORE FILELISTONLY FROM DISK = 'c:\in\Devis.bak'

---

Ensuite, restaurer les fichiers à un nouvel emplacement avec WITH MOVE :

Code:

---

1 2 3 4 5 6

RESTORE DATABASE nomBDD FROM DISK = 'c:\in\Devis.bak' WITH MOVE 'logicalNameMDF' TO 'C:\nouvelEmplacement\Devis.mdf', WITH MOVE 'logicalNameLDF' TO 'C:\nouvelEmplacement\Devis_1.ldf'

---

J'ai pu restaurer sans problème la base de données sur mon poste en utilisant la version ENU, comme sur le serveur.

Je lui ai fait désinstaller sa version de SQL Server 2008 R2 Express FRA, ainsi que sa version de 2005 Express.

On hésite entre :
- incompatibilité entre les backups de la version ENU et la version FRA (étonnant)
- problème de cohabitation de la version 2005 avec la version 2008 (et tentative par erreur de restauration de la base sur la 2005)

En tout cas, avec un message plus parlant, on aurait tiqué plus vite...

Il est en train de réinstaller SQL Server... Verdict dans une demi-heure:)

N'oubliez pas qu'avec la version Express vous êtes limité à 10 Go (ce qui semble être le problème dans votre cas...)

Si c'est pour développer sur un poste de travail, utilisez la version developpeur.

A +

Non non, le fichier backup (qui contient les 3 derniers full backup) ne fait que 800 Mo, la base est toute petite (surtout quand on sait que 95% de la taille, c'est des images et des PDF enregistrés dans la base).

On a fini par réussir à installer remonter le backup sur son poste, après avoir installé la 2008 R2 Express ENU.

Nous avons donc deux pistes :
- Il utilisait une version française : incompatibilité entre FRA et ENU ? Etonnant, très étrange, peu probable...
- SQL Server 2005 Express était installé conjointement sur son PC... On n'a pas cherché à décortiquer, mais visiblement, le moteur de 2005 essayait de faire la restauration.

En revanche, je ne comprends pas du tout pourquoi lorsqu'il faisait un "select @@version" c'est 2008 qui apparaissait... 8O

Là, moi je vote, et plus loin que l'erreur de manipulation, ça sent le bug avec SQL Server Management Studio qui s'emmêle les pinceaux lorsque plusieurs versions de SQL Server cohabitent sur le même poste.

Toujours est-il que nous avons fini par résoudre le problème !

Lorsque je donne des formations à Orsys, je déconseille fortement l'utilisation de SSMS directement.

Le plus simple est de demander le script SQL que SSMS veut lancer, ne pas le lancer et analyser ce que ce script va faire.

De surcroit vous en apprendrez beaucoup plus par ce moyen, car je pense qu'à votre âge la clicougnette n'a plus de secret pour vous...

A +

Ceci étant dit il est vrai que j'ai eu quelques surprises du genre avec SSMS sans expliquer pourquoi (pas eu le temps de chercher) mais mon dernier exemple est l'utilisation de SSMS 2008 R2 avec 2 instances SQL Server 2008 R2 et 2012 (Denali au moment de mes tests :P). Je pouvais utiliser les nouvelles DMV fournis avec 2012 sur une instance 2008 ... j'ai pas compris comment je pouvais faire cela :P ... après avoir pris une instance 2008 R2 propre en production, les DMV n'était pas présentes ... ouff qqch de logique (ou pas ???) :P

++

Si on repart de ton message, l'erreur 21 est "Device Not Ready".

Peut être partir de ce point.