Bonjour à tous,
Voilà j’aimerai avoir votre avis sur un sujet épineux la sauvegarde et ses tests.
Je travail dans une PME avec une infra assez conséquente
• 5 hôtes Vmware une licence pour seulement 3 …
• 80 Vm dont des postes de travail
• Des serveurs divers SharePoint TFS SQL etc. …
• Un DC physique + 1 virtuel
• Un serveur de périphérique physique
• 1 serveur de DMZ avec le ftp et messagerie et site web de la société
• Backup avec VDR et DPM  
• Deux baies MD 1000.
• Sauvegarde vers un NAS Syno local qui est répliqué sur un autre chez un hébergeur
Nous somme en train de réfléchir au PRA, et c’est un point ou je m’accroche avec mon supérieur. En effet je dis que le PRA ne sera valable que le jour ou on l’à testé et lui me rétorque de « vivre dans le monde mickey ». J’aurais tendance à dire que c’est plutôt lui qui y vie car croire que sa va marcher.  
 
C’est vrai je suis conscient qu’on ne peut pas effacer nos VM et les restaurer sans savoir justement si ça marche. Immobiliser la société etc … On n’a pas non plus tous le matériel en double.
Bref,
Comment avez-vous fait pour tester et même tester régulièrement vos sauvegardes/PRA ?  
Vous louer le matériel vous faites ça le week end ?
 
Déjà savoir combien de temps sa nous prendra à tous restaurer, savoir si notre scénario tient la route. Les ressources homme ou machines nécessaires. En plus le fait d’aller chercher physique le NAS chez l’hébergeur est pour moi une faille … la loi de Murphy étant ce quelle est c’est là qu’on a un accident.
 
Bref votre avis la dessus ;
 
Merci.

Bonjour,
 
Sur les deux dernières années, j'ai mis en place deux PRA et bien sure qui dit mise en place dit tests.
Pour info: une collectivité territoriale et le siège d'une filiale Europeene d'un groupe US : les boites US sont très concernées par les PRAcar c'est dans la loi Sarbanes Oxley (Sox).
Ces tests sont à effectués régulièrement (généralement 1 fois l'an voir plus si activité hyper critique).
Je reviens sur la loi Sox: la boite est dans l'obligation de tester ses PRA car si jamais elle est incapable de procurer ses données, elle risque fort de se faire comdamner pour dissimulation d'information ou pire encore.
 
Pour la collectivité:
J'ai fait les tests en grandeur nature.  
Sous Vmware tu peux creer un espace hors réseau afin de faire des tests.  
Tu peux ainsi restaurer tes Vm les unes après les autres pour vérifier le fonctionnement. Dans cet espace tu peux créer une Vm poste client et testé les applis clients/serveurs (cette partie là nous ne l'avons pas fait).
Pour le basculement de baie... j'ai tiré sur les cables d'alim.  
C'est violent mais je l'ai fait en presence du prestataire qui avait mis en place la solution: ça permettait aussi de voir si il etait sure de ce qu'il avait mis en place.  
Aucun pb tout à basculer et a redemarrer ensuite.
Lorsque tu as de la redondance (genre 2 baies de stockage repliquées, plusieurs noeuds de serveurs) les tests peuvent être fait grandeur nature ça ne perturbe pas l'activité.
Si ton responsable refuse ce genre de tests, ça veut dire qu'il n'est pas sure de l'infrastructure et là c'est vraiment grave: que se passera t il en cas de panne d'un noeud ou d'une baie.
Ces tests sont obligatoire avec des key users!
 
Pour la boite:
Serveurs dédiés aux tests.  
L'activité etait trop critique et il n'y avait pas d'architecture redondée.
Dans ce cas là il faut remonter les Vm sur un serveur de test.
Mais comme votre archi est redondée en synchro réelle (ce que j'en deduis), votre test PRA ne sera pas complet si vous utilisez cette méthode

Salut.
 
Pour le testing tu es dans l'environement idéal. Un machine virtual se déplace/copie sans nécessitée de coupure. Donc déjà tu peux récupérer l'intégralité de tes serveurs, et installer quelques machines sur un LAN séparé et les remonter pour reproduire ta prod (avec VMWARE SERVER ou juste le player .... Mais bon, les deux étant gratuit ...) ... Ou en tous cas, en partie. Tu seras en mode dégradé (moins performant), mais déjà là tu pourras checker si tu as des ennuies au redémarrage, repérer si un ordre précis est nécessaire, si tous tes services démarrent etc ...
 
Une fois ce labo monté, tu peux faire "mumuse" dedans ! Si tout va bien ...... Alrors ton boss fera le fanfaron (mais tu auras la conscience tranquile) mais si il y a un ou plusieurs problèmes ... Ton ponds la plus belle procedure qu'il soit et tu lui mets sous le nez
 
Tes questions sont justifiées :

Et à moin d'être senior dans le domaine (et encore), je pense que rien ne vaut un bon passage en mode laboratoire ...

Je me posé justement la question sur la restauration d'une partie de l'infra et pas dans sa totalité pour connaitre le temps total que cela mettrai et du coup valider le scénario de restauration ( d'abord le DC puis les ESX , puis ...).
Savoir aussi combien couterait des serveur en location (sous 24 ou 48 heures)en attendant de racheter des serveurs.
Le fait d'aller physiquement chercher un NAS alors que sa risque forcément d'etre la panique dans ces moment là ...
bref tout un tas de choses je suis jeune  (27 ans) je n'ai que 3 ans d'experience et je suis "sidéré" que l'on ne ce pose pas ces questions ... et même qu'on me reproche de les poser. Peut être suis-je trop idéaliste ...
 

j'ai eu le même cas où je suis maintenant. Et je test de temps à autres mes backup (pas dans la totalité) sans pour autant que ces tests soient structurés (planning etc ...) Mais au moins ... Si un jour j'ai à récupérer une catastrophe, j'aurais "un peu" d'avance

La réponse est simple.
Ton DSI n'est absolument pas sure de son infra et ne la maitrise pas, il se fait caca dessus et cache les risques à la DG.
Il applique la politique de l'autruche: Jusqu'ici tout va bien, l'important c'est pas la chute...
Mais si ça vient aux oreilles du DG ou DAF, il va vite sortir la tête de son trou (il faut juste qu'il ne sache pas que ça vient de toi).
 
80 Vm c'est déjà la bonne PME, ça m'étonnerai que personne n'ait travaillé sur le niveau de service: temps d'arrêt des machines accépté, temps d'arrêt des communications commerciaux/clients et fournisseurs... (je ne connais pas votre secteur).
Un PRA ne se limite pas à l'informatique: problèmes RH (contagions, grêve...), problèmes batiment (incendie, inondation...), problèmes fournisseurs (grêve transporteurs, faillite d'un fournisseur...) etc etc.
 
Il faut s'adresser à la personne qui a ou a eu en charge ce projet pour l'interroger sur la partie informatique... si personne ne s'est posé la question ça veut tout simplement dire que la boite n'a pas la culture de gestion de risques (en général les DAF l'ont) et dans ce cas là laisse tombé ou apprends la aux membres du comdir si tu as l'occasion de parler avec eux (un bon moyen de progresser dans la boite ou de te faire virer par ton supérieur).

Heuuuuu l'informatique ne me semble pas les plus concerné ... Ton PRA est un peu complet là ! Moi perso les conatgions, greves et autres ....

- Une grève partielle du personne bloque l'entrée de ta boite.
Comment permettre aux non grévistes de continuer le travail et donc avoir accès à leurs données
 
- Le service financier attrape la coqueluche à cause de l'un d'entre eux(c'est d'actualité): ils doivent finaliser les comptes de trimestres pour le siège... que faire?
 
je vais arreter là les exemples.
Si tu te limites aux systèmes, ce n'est pas un PRA mais une simple redondance, tolérance aux pannes ou appelle le comme tu veux de tes systèmes.