Problème restauration WSS 3.0

**Masics** · 27/12/2016, 10h28

Bonjour,

Je viens faire appel à vos lumières car j'ai un souci avec une restauration Sharepoint et je ne trouve pas ce qui me bloque.

Voici la situation.
Je m'occupe aujourd'hui d'un client qui a entre autres un intranet basé sur WSS 3.0 sur Windows Server 2003.

Etant donné que je viens de reprendre le flambeau sur ce client et que nous allons rapidement prévoir une migration de ce site vers des versions de SHarepoint et Windows Server plus récente, j'aimerai effectuer d'abord quelques test sur ce site, j'aimerai donc en créer une copie exacte sur un autre serveur indépendant du domaine de mon client.

J'ai donc créé un serveur Windows Server 2008 R2 (Pas de licence 2003 sous la main...), avec un WSS 3.0.
J'ai créé une application web avec une collection de site bidons .

J'ai ensuite fais un backup du site Sharepoint via la commande
stsadm -o backup -url "http://monurl" -filename "Monfichier.bak" -overwrite

Lorsque je transfère ensuite le fichier sur le nouveau serveur et que je lance la commande
stsadm -o restore -url "http://Manouvelleurl" -filename "Monfichier.bak" -overwrite
La commande tourne, je vois le fichier de base de données qui se créé bien sur SQL Server (Base de 2.5Go environ, qui a priori est bien restaurée dans son intégralité si j'en crois la taille du fichier mdf), mais elle ne s'arrête jamais. Une fois la BDD restaurée, j'ai l'impression que la commande tourne dans le vide (Je l'alaissé tourner plusieurs jours dans le doute), et rien 'est créé coté Sharepoint. Je n'ai du coup aucun message d'erreur pour m'aider.

Est-ce que quelqu'un saurait à quoi ce problème peut être du ?

Je vous remercie par avance pour votre aide :-)
Masics

**DotNetMatt** · 28/12/2016, 22h52

Envoyé par Masics

La commande tourne, je vois le fichier de base de données qui se créé bien sur SQL Server (Base de 2.5Go environ, qui a priori est bien restaurée dans son intégralité si j'en crois la taille du fichier mdf), mais elle ne s'arrête jamais. Une fois la BDD restaurée, j'ai l'impression que la commande tourne dans le vide (Je l'alaissé tourner plusieurs jours dans le doute), et rien 'est créé coté Sharepoint. Je n'ai du coup aucun message d'erreur pour m'aider.

Je ne suis pas expert sur SharePoint, mais la taille d'une base de donnees ne se mesure pas a la taille de son fichier MDF. On peut en effet pre-allouer de l'espace disque pour eviter des problemes de "croissance automatique" (auto growth).

Es-tu sur que ton fichier de backup n'est pas corrompu ? As-tu essaye de tronquer ta DB ?

Je ne sais pas si ca aidera, mais as-tu regarde ce post : STSADM taking so long time to run – SLOW! et son premier lien ?

**Masics** · 29/12/2016, 12h31

Bonjour DotNetMatt et merci de ta réponse.

Je ne pense pas que le fichier soit corrompu, car si je le copie sur le serveur d'orignie et que je fais une restauration avec la même commande mais sur une autre url que l'originale, la restauration fonctionne.

Malheureusement, le lien de l'article que tu cite ne semble pas correspondre à mon cas, car il s'agit dans l'article d'un temps de latence lors du lancement de la commande, temps pendant lequel aucune activité n'est visible sur le serveur, or lorsque ma commande tourne, elle se lance de suite et le proc monte a plus de 80% non stop, même après plusieurs jours (Et ma BDD devient inaccessible, même via SQL Management studio).

**Boubou2020** · 29/12/2016, 15h33

je pense que de ton Fichier backup ne doit pas avoir l’extension .bak

avec la commande powshell stsadm tu doit avoir l’extension .dat

**Masics** · 29/12/2016, 16h17

Hello abdallah_mehdoini,

Merci de ton aide également.

Oups, ceci est en fait une erreur de ma part quand j'ai écris le post.
Mon fichier est bien en .dat

**Felykanku** · 29/12/2016, 17h37

La meilleur façon de resoudre ton problème c'est d'accepter le déploiément deta base de données. Parce que tu déclare qu'en changeant d'url avec un autre fichier ça marche et donc soit tu optes pour l'audit de ta configuration ou tu refais tout pour t'éviter que ta conf. soit une fois de plus merdique. Mais pensez aussi au bouton resolu

**Masics** · 29/12/2016, 23h17

Envoyé par Felykanku

La meilleur façon de resoudre ton problème c'est d'accepter le déploiément deta base de données. Parce que tu déclare qu'en changeant d'url avec un autre fichier ça marche et donc soit tu optes pour l'audit de ta configuration ou tu refais tout pour t'éviter que ta conf. soit une fois de plus merdique. Mais pensez aussi au bouton resolu

Merci mais je ne comprend rien du tout à ton message.

Pourquoi parle tu d'accepter le déploiement de la base de données ? Quel est le rapport ?

Pourquoi tu parle d'une configuration merdique ? Même chose, je ne vois pas le rapport avec la config.

Et je n'ai jamais dis que ca marchait avec un autre fichier en changeant l'URL, mais avec le même fichier, pour assurer qu'il n'est pas corrompu.

Et pas de problème, j'userai du bouton résolu.... quand mon souci le sera...

**Boubou2020** · 30/12/2016, 04h17

Si je traduit ton problème en terme SQL Server Ta base de donnée reste bloquée en état restauration il reste bloquée sur un avancement de 100%

pour cela Essayer d'activer le trace flag ce ci va qui va vous permettre de tracer l’opération du restauration à ERRORLOG

Code :

Sélectionner tout - Visualiser dans une fenêtre à part