Bonjour,  
 
Étant en phase de test de logiciel de ghost, j'essaie de faire un backup à chaud et une restauration sur du matériel différent d'un serveur sous Windows server 2003 hébergeant un BDD sql server active.
 
Le  soucis que je rencontre est le suivant:
les fichier mdf et ldf de ma base de donnée sont sur un lecteur f:
Or j'ai uniquement 3 partitions: C: F: G:
 
aucune lettre de lecteur entre le c: et f: n'est utilisé.
 
Mon lecteur f: stock les fichier de ma base de donnée (ldf et mdf).
 
Le souci que j'ai c'est que lorsque je fait un ghost de mon c: et f: et que je le restaure sur une autre machine, une fois Windows chargé, je me retrouve avec un lecteur c: et un lecteur D: !
 
Évidemment sql server ne retrouve plus ses fichier mdf et ldf de la BDD et je peut seulement la supprimer et réimporter un dump.
 
Ma question est : Est-ce normal que les softs de ghost ne conservent pas l'attribution des lettre de lecteur lors de la restauration?
 
Y a t-il une manipulation particulière à faire pour conserver les même lettre de lecteur?
 
Les logiciel testé sont acronis backup&recovery 10, symantec system recovery 2010, farestone total backup recovery 7 et paragon drivebackup 10.
Sur les 4, seul acronis, m'a conservé les même lettre de lecteur après la restauration.

A voir dans les options
Tu as été voir du côté de Clonezilla aussi ? Je l'utilise, jamais eu de soucis avec de l'XP, 2000 et 2003 (en plus de Linux).

Quand tu redémarres une machine ghosté, souvent le hardware n'est jamais 100% identique. Le matériel ou une partie du matériel (et notamment le disque dur ou l'array raid) est redétecté. Windows met bêtement les lettres de lecteurs les unes à la suite des autres (c: d: e: f: , etc).
 
En utilisant dès le départ, les lettres les unes à la suite des autres (c d: e: sans trou) : tu n'aurais pas ce soucis ...

je n'est pas choisi! le poste à cloner est comme cela.
faut-il obligatoirement que les lettre se suivent?
 
Clonezilla ne fait pas de ghost à chaud apparemment.

ça ne fait pas de ghost à chaud, mais un "bon" ghost ne se fait pas à chaud aussi

Si tu ghost par partition c'est normal que les lettres soient changées
ça reviens a ajouter une nouvelle partition pour l'os
 
Il existe des produit spécifiques pour les serveurs et la restauration sur du matériel différent

"ça ne fait pas de ghost à chaud, mais un "bon" ghost ne se fait pas à chaud aussi"
ok, et tu arrête tes serveur toi pour ghoster?....  
 
"Si tu ghost par partition c'est normal que les lettres soient changées
ça reviens a ajouter une nouvelle partition pour l'os
 
Il existe des produit spécifiques pour les serveurs et la restauration sur du matériel différent"
 
tu veut dire qu'on est obligé de ghoster le disque entier???
Ca m’étonne quand même!
 
ce qui est triste c'est que les soft que je test ce sont les versions serveur et prévus pour du matériel différents normalement!!!
 
Acronis® Backup & Recovery™ 10 Server for Windows http://www.acronis.fr/backup-recovery/server-windows/
Symantec Backup Exec System Recovery Server Edition  http://www.symantec.com/business/b [...] er-edition
Total Backup Recovery® 7 Server  http://www.farstone.com/software/t [...] server.php
Paragon Drive Backup 10.0 Server  http://www.paragon-software.com/fr/business/db-server/
 
Sur les 4, seul acronis, m'a conservé les même lettres de lecteur après la restauration.

Parce que tu ghostes souvent tes serveurs ?
 
Juste un image une fois le serveur "fait", et éventuellement une autre fois si une mise à jour majeure du système est faîte.
Temps d'immobilisation minime, et fait durant un week-end, le soir après les heures de bureau, durant les vacances...
 
Après si tu préfères ghoster à chaud, c'est toi qui le sens. Pour moi ce n'est pas une fonction indispensable.

Ben justement je veut mettre en place un ghost journalier. Car souvent de petit changement de paramétrages sont fait sur les logiciel qu'ils hébergent ou des scripts.
De plus, en incluant la bdd dans le ghost je perdrais moins de temps en cas de reprise d'activité.

ça se fait pas ça , la bdd doit être traitée a par avec les processus propre a sa restauration*
 
Pour Ghost par partition il me semble qu'il ne prend pas le MBR d'ou le souci.
 
Pour tout faire: *= bdd, ad, systemes>> backupexec systeme recovery peux ghoster a chaud avec toutes les options propres aux backup traditionnels+ restaurer sur du matériel différent ou en virtuel
 
J'avais 1 complète par mois et une différentielle par jour (tout en prod !), pas de problème de performance notable la consommation de ressource etant limitable  
 
http://eval.symantec.com/mktginfo/ [...] ESR_DS.pdf
le cout est assez élevé mais a comparer a une journée sans activité...

"Pour tout faire: *= bdd, ad, systemes>> backupexec systeme recovery peux ghoster a chaud avec toutes les options propres aux backup traditionnels+ restaurer sur du matériel différent ou en virtuel"
La tu veut parler de backup exec ou de Symantec Backup Exec System Recovery Server Edition. Ce sont 2 softs différents...
Moi c'est Symantec Backup Exec System Recovery Server Edition que je test justement!
 
"ça se fait pas ça , la bdd doit être traitée a par avec les processus propre a sa restauration"
 
Je précise que mes bases de donnée (sur chaque serveur) seront ghosté la nuit quand il n'y a pas d'accès dessus. Mes serveur n'ont pas d'AD.
Si le backup complet (bdd de donnée inclue) ne permet pas de restaurer la bdd correctement, j'utiliserais la restauration du dump de la bdd (dump que je ferais de tout façon en plus du ghost).

"Pour Ghost par partition il me semble qu'il ne prend pas le MBR d'ou le souci"
Lors de la sélection des partition on peut bien choisir le MBR (cela crée d’ailleurs un fichier supplémentaire en plus des fichier pour chaque partitions). En effet la MBR (master boot record) sert à la gestion des multi boot et des partition donc il est a mon avis important de la sauvegarder avec. Le problème des lettre de lecteur que je rencontre va me poser beaucoup de problème je pense si je n'arrive pas à trouver une solution! Pourtant c'est un truc tellement courant et basic que je ne comprend pas pourquoi il n'y a pas plus de monde concerné par ce problème. Et pourquoi Acronis arrive lui à me conserver mes lettre de lecteur après restauration?
 
Je précise aussi que j'ai installé les soft dans un VM test et je la ghost pour la restaurer sur du matos physique.

system recovery fallait le dire!

Concernant la MBR, elle stocke la table des différentes partition c'est bien ça?
Mais si une lettre de lecteur est modifié dans sous Windows,genre le lecteur initialement D: je lui affect la lettre f:, est-ce que cela est pris en compte dans la MBR? Je ne pense pas! c'est a mon avis windows qui fait sa sauce!
Mais alors dans ce cas, comment les soft de backup peuvent-il faire le lien entre les lettre des partitions si il se basent sur la mdr?

C'est comme quand Windows détecte un nouveau périphérique de stockage il affecte la lettre immediatement après celle du dernier lecteur physique  
Pourquoi ne pas changer la lettre après restauration/redetection ?
 
Pour un point comme ça essaye d'avoir un ingé avant vente

 
 
Pourquoi ne pas changer la lettre après? parce que cela m'a déja planté ma bdd dès que windows est chargé    j'ai plus qu'a réimporter un dump. Je peut même plus détacher ou ratacher ma base sql server, je suis obligé de la supprimer.
 
Je crois que j'ai touvé un élément de réponse sur un site traitant du MBR:
 
Détails
Le plus petit espace adressable sur un disque dur est de 512 octets à la fois. Un secteur de disque dur est de 512 octets de long, c'est-à-dire un (1) secteur est le plus petit espace adressable sur un disque dur. Le MBR est un (1) secteur, Alors que le MBR est de 512 octets de long. Ces 512 octets sont divisés en plusieurs parties, chacune de ces parties ont leur propre fonction pour obtenir l'ordinateur à démarrer. Les 4 parties principales du MBR sont (dans l'ordre tels qu'ils apparaissent dans le MBR):
 
    Le code de démarrage (BootCode en anglais)
    Le volume d'octets (volume bytes)
    La table de partition (partition table)
    La signature d'octets (signature bytes)
 
 
Le code de démarrage: cette partie du MBR est lu par le BIOS de l'ordinateur lorsque l'ordinateur est démarré. Lorsque l'ordinateur termine ses propres procédures de démarrage (faire quelques vérifications) et se prépare à démarrer le système d'exploitation, le code de démarrage de l'MBR est lu en premier. Cela permet à l'ordinateur d'interpréter le reste de l'MBR.
 
Le volume d'octets (volume bytes): ce sont 4 octets qui sont situés après Le code de démarrage (BootCode) et juste avant la table de partition. Windows 2000 et Windows XP utilisent ces 4 octets pour identifier les volumes montables sur le disque dur. Si ces octets sont modifiés ou effacés du MBR, Windows 2000/XP va passer par une simple détection du matériel ronde qui ré-identifier tous les volumes sur le disque. Cela se fait au cours du prochain démarrage de Windows après avoir changé le volume d'octets. Les lettres de lecteur attribuées à des volumes pourraient changer après cela.

La table de partition (partition table): il s'agit d'une séquence de 64 octets (4 x 16) qui permettent d'identifier les 4 premiers (ou moins) partitions primaires sur un disque dur. Il y a une espace pour l'identification des 4 partitions. Chaque identification d'un partition est composé de 16 octets qui décrivent un certain nombre de choses sur la partition, tel que: où il commence, de quel type il est, quelle est sa taille, est-il une partition active ou non, etc. Une de ces 4 descriptions de partition peut être utilisé pour décrire une partition étendue, qui elle-même peut alors contenir des lecteurs logiques. Les lecteurs logiques ne sont pas décrits dans le MBR.
 
Une partition active est la partition à partir de laquelle le système d'exploitation est démarré. Ce doit être une partition principale, et il ne peut être qu'un (1) partition principale active à tout moment. S'il y a, par exemple, seulement 2 partitions sur un disque dur, les 32 premiers octets de la table de partition (2 x 16) contiendront la description de ces partitions. Les autres 32 octets doit tous contiennent des zéros. Donc, la suppression d'une partition consiste à mettre des zéros dans la description de la partition choisie.
 
La signature d'octets (signature bytes): ce sont 2 octets qui sont utilisés pour désigner un secteur important. Ils peuvent être trouvés juste après le MBR, mais il existe d'autres secteurs qui contiennent ces octets ainsi. Si elles ne sont pas trouvées après le MBR, l'ordinateur ne sera pas en mesure de lire le MBR (car il ne sera pas reconnu comme un secteur important).
 
En conclusion; le MBR est constitué (composé) de:
 
    440 octets de BootCode, suivi par
    4 octets contient les information du volume, suivi par
    2 octets qui ne sont pas utilisés (pas sure), suivi par
    64 octets qui contiennent des descriptions de la partition, ensuite
    2 octets qui est «de près» le MBR
 
Ceci fait un total de 512 octets.
 
Note sur les systèmes d'exploitation basés sur UNIX
La principale différence entre un MBR sous Unix et un MBR Windows est le Bootcode. Le bootcode sous Unix a la capacité de rechercher des informations de partition à l'extérieur de l'MBR. Ainsi, il devrait être clair que le remplacement d'un bootcode Unix par un bootcode Windows peut rendre le système non-démarrable (non-bootable).
 
Voila, une vue générale sur le MBR, la zone le plus important dans un disque dur. C'est presque tout.

Par contre si c'est la mbr qui stock la tables des partitions, comment faire pour faire un backup d'un serveur avec 2 HDD et faire une restauration sur un autre serveur avec 1 seul HDD? Cela me semble pas possible.
Pourtant ce cas ce pose à moi.

up