Sauvegarde, tolérance de panne, RTO, RPO, continuous data protection (CDP), plan de continuité d'activité, Disaster Recovery plan (DRP) ou plan de reprise d'activité en cas de sinistre (PRA)
(Mars 2007)
 
SOMMAIRE

0- Introduction
1- RPO, RTO, CDP, disponibilité
2- DRP
 21- Exemple de mise en place de DRP
 22- Méthodologie de mise en place de DRP
3- Tolérance de pannes
 31- Sur les DD
 32- Sur les Serveurs
   321- La virtualisation des serveurs
 33- Sur le stockage
   331- La virtualisation du stockage
4- Sauvegarde
 41- Solution technologique
  410- Le stockage holographique  
  411- Disque dur
  412- La sauvegarde box to box
  413- WAFS  
  414- Bandes/taux de transfert  
  415- Taux de transfert de données du matériel de sauvegarde
  416- La bande passante du reseau  
 42- Plan de sauvegarde
  421- Types de sauvegarde  
  422- Les rotations de bandes(ou stratégies de sauvegarde)
  423- L’externalisation de bandes - système de sauvegarde séparé des autres serveurs
  424- Le snapshot(copie instantanée de l'état d'un système)
  425- WORM(write one, read many)
  426- One Button Disaster Recovery Solution (OBDR)
  427- Sauvegarder DB EXchange et SQL à froid
5- Le Cloud Computing
6- Les liens utiles, pour aller plus loin
7- Les guides pour administrateur des logiciels de sauvegarde

 
0- Introduction
______________________________________________________________________________________________
Dans la rubrique sauvegarde, ce sont des questions récurrentes d'où l'idée de tout regrouper sous un même topic.  
Une telle présentation ne peut être exhaustive (mais le périmètre est assez large), tout ce qui existe n'est pas là. Ceci est valable pour le contenu, ce n'est qu'un apercu des solutions évoquées, donc pour aller plus loin...
 
______________________________________________________________________________________________
Quelques chiffres pour commencer:
source : CLUSIF (Club de la sécurité de l’information français)
 
• 95 % des salariés d’entreprises déclarent avoir déjà perdu des fichiers informatiques,
représentant 1 heure à plusieurs jours de travail.
• 80 % des PME non préparées ne survivent pas à un crash informatique majeur.
• 20 % des ordinateurs portables font l’objet d’un sinistre (bris ou vol).
• 70 % des PME ne sauvegardent pas leurs données.
• 60 % des PME qui ont vécu un sinistre informatique disparaissent dans les 5 ans.
• 98 % des entreprises de + de 200 salariés ont une dépendance modérée ou forte vis à vis de l'informatique.
• 42 % des entreprises de + de 200 salariés n'ont pas de processus formalisé et entretenu de gestion de la continuité d'activité, et 32% ont un processus qu'en partie réalisé.
______________________________________________________________________________________________
 
Il est clair que la tolérance de panne associée à la sauvegarde et à un DRP coute chère et peu même être très onéreux.
Mais l'indisponibilité des ressources informatiques pendant 1/2 journée voir plus, la perte de données (donc le coût salarial du temps de travail perdu) et les conséquences financières (temps de travail perdu, contrats perdus, pénalités de retard...) et de dégradation de l'image pour l'entreprise vis à vis de ses clients sont bien au delà de l'investissement de départ qu'est celui dans un tel système.
 
 
La sauvegarde est un projet à part entière.
Avant de vous lancer dans un projet de mise en place d'un système de sauvegarde, vous devez vous poser la question suivante:
Pourquoi sauvegarder?
- pour restaurer un fichier ou dossier en cas d'effacement accidentel.
- pour restaurer les données d'un serveur en panne.
- pour restaurer des données en cas de sinistre majeur.
- pour archiver.
- ...
 
 
Donc une des raison principale, pour mettre en place une sauvegarde, est la restauration.
Donc penser la sauvegarde c'est aussi penser restauration.  
Pour quelques dizaines de Go, la restauration n'est pas un problème en soit.  
Mais lorsqu'on parle de centaine de Go voir de To, les temps de restauration vont commencer à peser sur l'actité de l'entreprise... surtout que les temps de restauration peuvent être jusqu'à 10 fois supérieur aux temps de sauvegarde.
Ce point ne doit jamais être perdu de vue.
 
 
1- RPO, RTO, CDP, disponibilité
_____________________________________________________________________________________________
Le CDP (Continuous Data Protection) englobe l’ensemble du processus de protection des données : sauvegarde en continu, protection continue hors site, stockage historique et capacité de restauration immédiate.  
 
La disponibilité représente le temps de panne acceptable par an. Il s'exprime en pourcentage.
 
Indisponibilité (minutes par an)                 Pourcentage de disponibilité Classe
50.000 (34 jours, 17 heures et 20 min)                        90%                         1
5.000 (3 jours, 11 heures et 20 min)                           99%                         2
500 (8 heures 20 minutes)                                       99,9%                        3
50 (un peu moins d'une heure)                                 99,99%                       4
5 minutes                                                            99,999%                      5
0,5 (30 secondes)                                                99,9999%                     6
0,05 (3 secondes)                                              99,99999%                     7
 
En cas de sinistre:
Le RTO (Recovery Time Objective) spécifie le délai maximum que l'entreprise tolère avant de reprendre son activité. Il peut être de quelques secondes à quelques heures.  
 
Le RTO va définir en partie votre infrastructure.  
Entre un RTO défini à zéro et un RTO défini à 24h, l’infrastructure sera différente.  
Dans le cas d’une infrastructure à 1 serveur :
-Si vous pouvez vous passer d’informatique pendant 24h, un seul serveur avec un contrat de maintenance à intervention sur site dans les 8h suffit*. Pas besoin non plus de redondance.
-Par contre, pour un RTO égale à zéro, l’infrastructure sera tout autre : clustering, salle info de secours …
Les temps de restauration de sauvegarde seront à prendre en considération : ex, double sauvegarde DD/bandes, clustering de stockage…
 
* Attention, ces delais d'intervention spécifient qu'un technicien sera sur votre site dans les 8h mais ne garantie pas le fonctionnement dans ces 8h (Pb de pièces de rechange, mauvaise expertise du pb par téléphone... expérience vécue auprès de divers constructeurs). Tenez compte de cela dans vos calculs de RTO.
 
Le RPO (Recovery Point Objective) désigne, pour sa part, la durée maximum d'enregistrement des données qu'il est acceptable de perdre lors d'une avarie. Cette durée varie de zero à …
 
Le RPO lui va définir vos objectifs de sauvegarde.  
Il faut prendre en compte en plus la volumétrie et fenêtre de sauvegarde.
Entre un RPO proche de zéro et un RPO défini à 24h, les contraintes seront différentes.
-Dans le cas d’un RPO défini à 24h avec une volumétrie faible, une sauvegarde complète tous les soirs suffit.
-Dans le cas d’un RPO très faible, plusieurs sauvegardes journalières (type snapshot, CDP…) seront nécessaires.
 
 
2- DRP
______________________________________________________________________________________________
Le DRP (Disaster Recovery Plan) est le processus prévoyant les mesures à mettre en œuvre en cas de sinistre informatique et pour s’y prémunir.  
La tolérance de panne et la sauvegarde ne suffisent pas à elles seules à la continuité de l’activité et/ou au plan de récupération en cas de sinistre informatique.  
 
En effet cette continuité d’activité et ce plan de récupération, c'est à la fois ceux des opérations métier et ceux des outils informatiques qui les supportent.
Chaque entreprise étant particulière, la continuité d'activité et le disaster recovery le sont aussi.  
Ils devront se baser sur:
- une analyse de risques, ou un audit de vulnérabilité (non restreint aux outils informatiques).
- une mise en priorité des processus métier.
 
Ensuite, l'entreprise construira la solution de continuité d'activité et plan de récupération en cas de sinistre qui lui sont propre:
- en fixant ses objectifs de continuité ou de reprise d'activité;
- en menant des actions préventives de réduction des risques externes.
- en fiabilisant les processus existants, réduction des risques internes.
- en fiabilisant le système d'information: c'est le plan de continuité informatique.
 
Les opérations métiers et donc analyse de risques, processus métier, continuité d’activité et « disaster recovery plan» ne peuvent être traités ici… ne pouvant être exhaustif.
C’est pourquoi seules les parties tolérance de panne, sauvegarde, RCO et RPO peuvent être abordées.
 
21- Exemple de mise en place de DRP
 
Voici un plan (extra-light) qui peut servir de base pour la mise en place d'un DRP. Celui ci est adapté à une structure type PME. Ce n'est qu'une base de départ, non un mode d'emploi clé en main et encore moins un modèle exhaustif.  
 
Phase de préparation
Justification du projet
  -Evaluer le coût d’un arrêt complet des systèmes/téléphonie… d’une journée. Cela permet non seulement de justifier le projet mais aussi de défendre votre budget.
  -Expliquer les objectifs et enjeux d’un tel projet.
 
Périmètre du projet
  -Définir le périmètre d’intervention du projet : les serveurs, la téléphonie, le wan, le lan…
 
Le cahier des charges
  -Fonctions prioritaires.
  -Niveau de service.
  -Définition du cahier des charges.
 
Phase d'analyse
  -Analyse de l'existant : topologie systèmes et réseau, identification de tous les éléments composant le réseau, les contrats de maintenance…
  -Définir la criticité des métiers et des systèmes associés.
 
Phase d'orientation
  -Les données : vérifier que toutes les données critiques sont sauvegardées et qu’elles peuvent être restaurer. Optimisation de la sauvegarde.
  -Les systèmes : hiérarchisation de la criticité des systèmes; Dans quel ordre remettre en route les systèmes et en combien de temps pour minimiser l’impact d’un sinistre.
  -Les utilisateurs. Comment leurs garantir un accès à l'issue d'un sinistre.
  -L’entreprise : définition du site de replis…
  -Etude des solutions préventives.
  -Etude des solutions curatives.
 
Proposition de solutions
  -Pour chaque élement défini dans le périmètre d'intervention: solution préventive comme curative.
 
Validation
 
Maquettage et tests
   -Modification si nécessaire, tests
 
Lancement du projet
   - L'implémentation des solutions retenues
 
Tests et recettes
 
Ne pas oublier la documentation et la gestion de projet:
- Suivi du projet
- Les docs techniques
- Les docs utilisateurs  
- Les procédures en cas de sinistre (si possible testées par une personne externe au projet)
- Répertorier les contacts, les responsabilités (qui fait quoi lors d'un sinistre)...
- Planification, Analyse des risques sur la mise en place du projet, OT...
etc etc...
 
22 - Méthodologie de mise en place de DRP
 
Méthodologie PRA
 
 
 
 
3- Tolérance de pannes
______________________________________________________________________________________________
31- Sur les Disques durs
 
La tolérance de panne permet d’assurer la disponibilité des systèmes en cas de panne. Elle ne constitue en aucun cas un système de sauvegarde à T-x.
 
Solution RAID pour les DD, les principaux types de RAID:
RAID: Redundant Array of Independant Disks
 
- RAID0 :  
Agrégat de bandes. Regroupement de plusieurs disques physiques sous un seul volume. Ce n'est pas une solution à tolérance de panne, mais elle permet de comprendre le RAID0+1.
 

 
- RAID1 :  
Mirroring. Système de RAID qui se compose de deux disques durs qui stockent les mêmes données. Le RAID 1 augmente la sécurité car si un disque tombe en panne l'autre prend automatiquement le relais
 

 
-RAID0+1:  
C'est la combinaison du RAID 0 et du RAID 1. Ce type de RAID est composé de quatre disques durs, répartis en deux volumes dont le premier permet de faire du mirroring. Ce système est l'un de plus onéreux.
 

 
- RAID5 :  
Aussi appelé agrégat par bandes avec parité, est un système permettant de mettre en place une tolérance de panne au niveau des disques. Il se constitue au minimum avec 3 disques avec un système de parité permettant de récupérer les données même dans le cas d'une panne d'un des disques.
Le système de parité est dit "tournant" car les bits de parité sont répartis sur tous les disques.
 

 
Il est conseillé d'utiliser le mirroring (RAID1 ou RAID0+1) pour tout ce qui est base de données et le RAID5 pour les données. On peut très bien combiner les 2 (RAID0+1 ou RAID1 + RAID5) pour dissocier DB et données.
Pourquoi les DB sur du mirroring?
Dans le cas du RAID5, en plus du nombre d'I/O, il faut ajouter le temps de calcul de la parité et le temps d'écriture de celle ci. Ceci augmente fortement le nombre I/O et le temps lié, qui dans le cas des DB sont très nombreux et a pour conséquence de ralentir les accès sur les DB.
Dans le cas du RAID1 ou RAID0+1, même si les temps d'écritures sur disques sont plus lent, en théorie, que dans le cas du RAID5, il n'y a pas de calcul de parité (donc plus rapide et moins d'I/O) et les accès en lecture sont plus rapide (pas de calcul de parité, lecture sur 2 disques).
 
-introduction au RAID
-pour aller plus loin
 
 
32- Sur les serveurs
 
Solutions matérielles:
- Redondance des alimentations électriques sur les serveurs.
- Redondance des cartes réseaux sur les serveurs.
- Système onduleur pour l’alimentation des serveurs.
- Serveur «Hot-Plug », permet le changement de cartes, alimentation, … à chaud.
- contrat de maintenance 4h sur site.
- solution de luxe : redondance de serveur physique, virtualisation, clustering...
 
 
321- La virtualisation des serveurs
______________________________________________________________________________________________
La consolidation:
Voici un ex d'application de la virtualisation pour la tolérance de panne de serveur et la consolidation de stockage(un schéma étant souvent plus explicite que de longs discours):
 

 
cliquer ici si l'image n'apparait pas, recharger la page si necessaire (Image 1)
 
Sur les serveurs physiques, les VM en rouge sont celles démarrées. En cas de crash de l'un des serveurs (on n'aborde pas ici un quelconque pb de SAN), il suffit de demarrer les VM arrêtées sur le serveur en fonctionnement.
Comme ces VM sont sur un SAN (pour cet ex), seules 4 licences serveur sont nécessaire pour les VM.
 
La haute disponibilitée:
 

 
cliquer ici si l'image n'apparait pas, recharger la page si necessaire (Image 2)
 
La haute disponibilité necessite une salle de secours qui, en cas de sinitre dans la 1ère salle, est à l'abris.
 
Pour plus de détails sur la virtualisation (et plus particulièrement Vmware), je vous renvoie vers les liens suivants:
- Forum Vmware communities
- Doc Vmware ESX des versions 1.5 à 2x
- Doc Vmware ESX version 3
- Drivers, maj et outils pour ESX:
  * jusqu'aux versions 2x
  * version 3
 
Edition 2011:
En 4 ans, date de ce post, il y a eu beaucoup de changement dans le monde de la virtualisation des serveurs.
Je ne vais pas faire un tour des solutions, les principes restent les mêmes.
Par contre de nouvelles fonctionnalités sont disponible sur les offres de base ou moyenne gamme.
 
La fonction HA: redemarrage automatique des Vm sur autre seveur physique, avec coupure équivalente à ce temps de démarrage.
La fontion fault tolerance: aucune coupure, une instance dite fantôme des Vm permet un basculement automatique est imédiat d'un serveur physique à l'autre.
 
33- Sur le stockage
331- La virtualisation du stockage
______________________________________________________________________________________________
 
Un premier aperçu sur la virtualisation du stockage:
Définition de la virtualisation de stockage
 
Extrait
Réplication de stockage Storage Virtualization  
Il est important d'avoir des sauvegardes appropriées ou des copies de stockage dans le cas d'une catastrophe. Certaines options de virtualisation du stockage des outils mis en œuvre qui permettent la réplication de stockage du disque virtuel à apporter à d'autres endroits dans le cas d'une catastrophe.  
En général, cela coûte plus cher pour les consommateurs, mais permet la récupération de données dans le cas où il est détruit dans les emplacements d'origine sur le disque physique. Certaines options permettent de réplication de données à distance à d'autres endroits. Cela est vrai pour les serveurs qui utilisent à la fois synchrone et asynchrone en miroir.  
Le processus permet de serveurs au sein d'une certaine distance de recevoir une réplication complète des données. Le site distant où les données sont stockées doivent communiquer avec la source d'origine qu'il est complètement miroir de reprise après sinistre.  
Instantanés de l'entreposage sont également possibles grâce à des options spécialisées de virtualisation du stockage. Ceux-ci permettent une conservation plus précis et de l'espace "  clone" option qui pourrait être restauré facilement en cas de catastrophe. Cela peut être fait pour un large éventail d'utilisations et de permet de "reculs" dans le cas où quelque chose a horriblement mal tourné.  
 
Quelques éditeurs:
DataCore / EMC / Dell / Falconstor / IBM / Neartek / Storagetek / Symantec-Veritas / NetApp / HP
 
Edition 2011:
Pour utiliser actuellement cette technologie, voici le principe en quelques lignes:
La virtualisation du stockage permet de créer un pool en aggregant différent stockage quelque soit la ressource (SAN, NAS, DAS...) et quelque soit son emplacement.
Ce pool peut être vu comme une "unité" SAN.
L'avantage: on simule un SAN quelque soit l'origine du stockage.
Très interessant lorsqu'on se lance dans la virtualisation sans vouloir investir dans du SAN FC ou ISCSI.
 
Autre interet: la plupart des ces outils disposent d'options de réplication croisée synchrone.
Il est donc possible de créer une couche d'abstraction au dessus de votre stockage, de divisé ce stockage (en 2 partie par ex) et de créer de la réplication synchrone entre ces 2 pools.
Il est donc possible d'utiliser, par ex, 2 baies DAS (3 à 5 fois moins chère que le ISCSI) de simuler 2 baies SAN et de faire en sorte que l'une soit l'image de l'autre en temps réél.
En cas de panne de l'une d'entre elles, le basculement est automatique est sans coupure (un leger freeze de qqls secondes).
 
Avec la virtualisation de serveur, vous obtenez une tolérance de panne sur le stockage à moindre cout.
 
4- Sauvegarde
______________________________________________________________________________________________
Deux choses sont à prendre en compte : La solution technologique (matériel et logiciel) et le plan de sauvegarde.
 
41- Solution technologique
410- Le stockage holographique
______________________________________________________________________________________________
1.6 To par support prévu d'ici 2009.
N'ayant jamais utilisé ce type de sauvegarde, je vous renvoie aux liens suivants:
introduction
Le principe
les disques
 
411- Disque dur
______________________________________________________________________________________________
      Le support qui pose la plus grosse polémique. Il y a les pro sauvegarde sur disque dur, et les autres plus mitigés sur les risques que ce support comporte.
Voici 2 petits articles intéressants sur le sujet, avec des comparatifs de prix DD Vs Bandes et les commentaires du directeur marketing d'Overland Storage que l'on ne peux pas vraiment taxer d'objectifs -il vend de la sauvegarde sur baie mais aussi de l'autoloader-. Il admet que, même si la sauvegarde sur DD à de l'avenir (voir raisons ci dessous) elles ne peuvent se passer de la sauvegarde sur bandes:
 
http://www.indexel.net/1_6_3711__3 [...] ande__.htm
http://www.zdnet.fr/entreprise/ser [...] 990,00.htm
 
 
      La solution sur DD n'est pas une solution de sauvegarde à elle seule de plus elle comporte les risques suivants: plusieurs jours de sauvegarde sur un même media, virus (contrairement aux bandes, le DD n'est pas un média inerte), défaillance mécanique, intégrité des données sur long terme, pb d'externalisation...  
Elles doivent toujours être complétées par une solution de sauvegarde sur media optique ou magnétique.  
 
      L'avantage du disque est de laisser disponible les systèmes par une sauvegarde dite déportée et des restaurations plus rapide.  
Associé à du snapshot, elle permet de réduire le RPO.
        Elle est donc utilisée pour des entreprises ayant une utilisation 24/24h de leurs systèmes avec une sauvegarde déportées sur disque (type snapshot ou virtualisation de librairie) et ensuite sauvegarde de ce disque sur media cité ci-dessous ou pour des entreprises ayant le besoin d'avoir à disposition rapidement des données perdues.
A moins d'avoir le budget pour des baies SAN redondantes et dédiées à la sauvegarde (via la virtualisation de librairies) sur des sites différents (redondance, sauvegarde croisée). Sans compter l'investissement réseau, le WAN capable de supporter cela, les logiciels... plusieurs dizaines de millier d'€, pour l'instant.
 
Fausse idée, qui à la vie dure...
 
L'un des arguments qu'on retrouve le plus souvent, pour nous expliquer la soit-disante supériorité de la sauvegarde sur DD VS sauvegarde sur bande est l'argument fiancier.
Or pour un même niveau de sécurité, c'est à dire : externalisation des média (voir point 423), une seule sauvegarde par media (protection contre les virus...) et rotation, la sauvegarde sur DD est bien plus chère que la sauvegarde sur bande.
 
Un exemple:
Pour un roulement sur 1 mois (22 media) avec conservation de la dernière bande mensuel (12 media) plus un archivage annuel (1 media), nous nous retrouvons avec 35 media (22+12+1).
 
Disque dur:
Au 01/01/2008, un DD USB de 700 Go vaut environ 200€ pour du Iomega ou Lacie.
(bien sure on peut trouver encore moins chère mais combien tiendront 5 ans?).
Pour notre roulement l'investissement est de 200*35= 7000€.  
(en supposant qu'aucun DD ne tombera en panne pendant une période de 5 ans, période de contrat de maintenance d'un lecteur LTO)
 
Bandes:
Sur la même base:
Au 01/01/2008, prix d'un lecteur LTO3 (capacité 400/800Go) = 4000€ ttc (maintenance comprise et j'ai vu large point de vue tarif), prix d'une bande= 52€.
Pour notre roulement l'investissement est de 4000+(52*35)= 5820€
 
Donc l'argument "c'est moins chère" ne tient pas.
Mais je ne dis pas que c'est une mauvaise solution, que les choses soient claires.
 
Edit 2011:
Avec la baisse des couts des solutions types virtualisation de stockage, je suis passé au backup D2D (disk to disk).
Le backup est assuré par le logiciel de virtualisation (Vmware data recovery: vdr).
Mais pour des raisons de sécurité, et principalement par le fait que la bande est un média inerte et que toute notre infra repose sur un logiciel de virtualisation (Vmware), nous continuons le backup sur bande : D2D2T (disk to disk to tape).
Nous ne mettons sur ces bandes que les images (snapshot) des serveurs, data y compris.  
En cas de crash de toute l'infra de virtualisation ou d'un problème de catalogue VDR, nous pouvons remonter l'infra, les serveurs ou les datas.
 
412- WAFS
______________________________________________________________________________________________
 
WAFS: Wide Area Files Services.
Définition Wikipedia: cliquer ICI.  
 
413- Optique (CD, DVD) :
______________________________________________________________________________________________
      Durée de vie des supports optiques limités aux alentours de 5 ans.  
Capacité limitée : 700Mo pour un CD, 4,7 Go par couche pour le DVD. Solution acceptable pour très petite structure avec peu de données critiques.
Pour être franc, très très peu utilisée. Peu d'avenir, mais comme cela existe il fallait l'aborder.
 
414- Bandes (DAT, DLT, LTO…) :
______________________________________________________________________________________________
         On ne va pas aborder tous les types de format, c’est un aperçu des formats les plus utilisés afin de se faire une idée sur les types bandes.
         Suivant le volume de données à sauvegarder, la technologie aura sont importance. Outre les capacités, les temps de sauvegarde peuvent devenir longs, voir très long comme pour une sauvegarde exchange par bloc, d’où l’importance des débits de transfert et du type de sauvegarde (full/incrémentielle/différentielle).
 
         Ex, pour un serveur exchange comportant environ 200 BAL avec quota à 500Mo sur une techno LTO2, le temps de sauvegarde avoisine les 6h dans un réseau 100Mb.
Certaines entreprises sauvegardent la partie Exchange sur un lecteur dédié en plus de leur sauvegarde.
Les autoloader haut de gamme dispose de plusieurs lecteurs de bandes augmentant d'autant les capacités de sauvegarde à l'heure ( exe ici ).  
 
DAT
 
La technologie DSS repose sur un support type DAT et se présente sous cinq formats (DDS1, DDS2, DDS3, DDS4, DAT). Les formats de lecteur 1 et 2 étant obsolètes, on passe au 3 et 4 (bientôt obsolète).  
 
DDS3 :
Capacité: 12 Go (natif) / 24 Go (compressé)  
Débit de transfert de données: 1.2 Mo/s (natif) / 2.4 Mo/s (compressé).
 
DDS4 :
Capacité: 20 Go (natif) / 40 Go (compressé)  
Débit de transfert de données: 3 Mo/s (natif) / 6 Mo/s (compressé).
 
DAT72 :
Capacité: 36 Go (natif) / 72 Go (compressé)  
Débit de transfert de données: 3,5 Mo/s (natif) / 7 Mo/s (compressé).
 
DLT
Capacité: 40 Go (natif) / 80 Go (compressé)  
Débit de transfert de données: 6 Mo/s (natif) / 12 Mo/s (compressé).
 
Capacité: 80 Go (natif) / 160 Go (compressé)  
Débit de transfert de données: pas d’info.
 
LTO Ultrium
 
LTO1
Capacité: 100 Go (natif) / 200 Go (compressé)  
Débit de transfert de données: 16 Mo/s (natif) / 32 Mo/s (compressé).
 
LTO2
Capacité: 200 Go (natif) / 400 Go (compressé)  
Débit de transfert de données: 35 Mo/s (natif) / 70 Mo/s (compressé).
 
LTO3
Capacité: 400 Go (natif) / 800 Go (compressé)  
Débit de transfert de données: 80 Mo/s (natif) / 160 Mo/s (compressé).
 
LTO4
Capacité: 800 Go (natif) / 1,6 To (compressé)  
Débit de transfert de données: 120 Mo/s (natif) / 240 Mo/s (compressé).
Intègre le chiffrement materiel (256-bit AES-GCM)
 
LTO5
Capacité: 1.5 To (natif) / 3 To (compressé)  
Débit de transfert de données: 140 Mo/s (natif) / 280 Mo/s (compressé).
Intègre le chiffrement materiel  
 
Pour info: 10 Mo/secondes = 36 Go/heure
En plus de ces données afin de calculer vos temps de sauvegarde, il faut tenir compte du taux de transfert de votre materiel et celui de votre réseau.
 
415- Taux de transfert de données du matériel de sauvegarde
______________________________________________________________________________________________
Version            Largeur de bus          Taux maximum de transfert de données approximatif
Wide Ultra SCSI          16 bits                               40 Mo/secondes = 144 Go/heure
Ultra2 SCSI                8 bits                                 40 Mo/secondes = 144 Go/heure
Wide Ultra2 SCSI         16 bits                               80 Mo/secondes = 288 Go/heure
Ultra 160 SCSI            32bits                                160 Mo/secondes = 576 Go/heure
Fibre Channel 1 Go                                               100 Mo/secondes = 360 Go/heure
Fibre Channel 2 Go                                               200 Mo/secondes = 720 Go/heure
 
416- La bande passante du reseau
______________________________________________________________________________________________
Type de réseau   Taux de transfert théorique    Débit réaliste     Taux de transfert réaliste*
10Base-T               10 mbps=1,25 Mo/secondes       40-50 %            500 Ko/secondes=1,8 Go/heure
100Base-T             100 mbps=12,5 Mo/secondes         80 %             10 Mo/secondes=36 Go/heure
1 Gigabit                1000 mbps=125 Mo/secondes        70 %             87,5 Mo/secondes=315 Go/heure
 
*Suivant la charge sur le réseau ce taux peut varier fortement.
 
PS:  
Les données sauvegardées vont aussi influencer les temps de sauvegarde. Par ex, pour un même volume donné, un seul fichier sera sauvegardé plus rapidement que des dizaines de millier.
 
42- Plan de sauvegarde
 
Le plan de sauvegarde repose sur 3 principes : le type de sauvegarde, les roulements et l'externalisation.
 
421- Types de sauvegarde
______________________________________________________________________________________________
Les plus courantes sont les suivantes :
 
Complète : cette méthode transfère sur bande une copie de toutes les données concernées par la sauvegarde, indépendamment de la modification des données depuis l'exécution de la précédente sauvegarde.
 
Différentielle : cette méthode sauvegarde tous les fichiers modifiés depuis la précédente sauvegarde complète, indépendamment de leur modification depuis la dernière opération de sauvegarde, quel que soit son type. Les opérations de récupération nécessiteront de réaliser la restauration de la dernière sauvegarde complète et la dernière sauvegarde différentielle.
 
Incrémentale : ici, se verront transférer sur bande les seuls fichiers modifiés depuis la dernière opération de sauvegarde, quel que soit son type (complète, différentielle ou incrémentale). Les opérations de récupération nécessiteront de réaliser la restauration de la dernière sauvegarde complète et de chaque sauvegarde incrémentale.
 
Le choix du type de sauvegarde va dépendre de plusieurs facteurs dont la fenêtre de sauvegarde (combien de temps avons-nous pour effectuer la sauvegarde), la volumétrie de sauvegarde et la volumétrie de données changeant chaque jour.
 
Plus de détails ici
 
422- Les rotations de bandes(ou stratégies de sauvegarde)
______________________________________________________________________________________________
Les rotations vont dépendre du type de sauvegarde en fonction de la volumétrie, de la conservation des bandes et vont être conditionnés par le RPO.
 
Exemple de scenario (extrait du manuel administrateur BrightStor ARCserve Backup) :  
- Le scenario GFS (Grandfather-Father-Son), est composé de sauvegardes complètes hebdomadaires combinées à des sauvegardes incrémentielles et différentielles quotidiennes.  
La stratégie GFS est une méthode permettant de gérer des sauvegardes sur une base journalière, hebdomadaire et mensuelle.
L'objectif principal du scénario GFS est de suggérer un intervalle minimum standard et cohérent qui sera utilisé
pour la rotation et le retrait (ou rétention) du média.  
Les sauvegardes journalières sont les « Fils » (Sons). La dernière sauvegarde complète de la semaine (la sauvegarde hebdomadaire) est le « Père » (Father). La dernière sauvegarde complète du mois (la sauvegarde mensuelle) est le « Grand-père » (Grandfather).  
Ces scénarii permettent de sauvegarder vos serveurs pendant une année entière à l'aide d'un nombre minimum de médias.
 
D'autres exemples ici
 
423- L’externalisation de bandes - système de sauvegarde séparé des autres serveurs
______________________________________________________________________________________________
La première des précautions est de séparer physiquement le serveur de sauvegarde, et le système de sauvegarde rattaché, du reste des serveurs.
En cas d’incendie, inondation… les données seront toujours présentent soit sur le système de sauvegarde soit sur les serveurs.
Pour les petites structures, avec un seul serveur, l’externalisation est primordiale. Mais dans ce cas de figure et en cas de sinistre, le RPO sera égal à la durée entre la bande externalisée et le moment du sinistre.  
Plus la rotation d’externalisation est courte, plus le RPO peut être réduit.
 
L’externalisation consiste à enlever régulièrement du site une bande de sauvegarde full et de la conserver dans un endroit sécurisé à l’abri de l’eau, de la chaleur, de source magnétique et du feu dans un coffre ignifugé par exemple.
Soit sur un autre site, soit à un autre endroit du site à l’abri d’un sinistre pouvant toucher la première partie du site, soit en banque.
 
 
 
424- Le snapshot(copie instantanée de l'état d'un système)
______________________________________________________________________________________________
Définition: Image statique d'un ensemble d'enregistrement d'une base de données.
Divers outils permettent le snapshot du système, de fichiers ou de DB en cours d'utilisation.
 
La première option, le snapshot système, permet de générer une image à chaud du système.  
Associé à un CD Pebuilder, par exemple, vous pouvez faire une restauration rapide du système en cas de crash.
Cette solution est en plus bien moins chère qu’une option disaster recovery sur les logiciels de sauvegardes.
 
Une autre application, dans le cas ou SQL et Exchange ne peuvent être sauvegardés à froid, est de « snapshoter » les DB SQL et Exchange à chaud. Solution toujours moins chère que les options sauvegarde à chaud SQL et Exchange sur les logiciels de sauvegardes.
Néanmoins il y a un bémol concernant cela mais qui n'est pas forcement handicapant. La plupart des outils de snapshot (pour les outils à prix très abordable) sauvegarde une partition et non un dossier ou fichier.  
 
Si l’association de sauvegarde sur DD et bandes n’est pas dans votre budget, les snapshots en cours de journée, puis sauvegardés sur bandes, sont une solution afin de réduire le RPO.
En effet, en cas de crash, au lieu de revenir sur l’état de vos données au moment de la sauvegarde sur bandes (généralement le soir) il est possible de revenir sur l’état de vos données au moment du snapshot, c'est-à-dire en cours de journée.
 
Voici un exemple concret :  
Tous les midis vous faites un snapshot et vous faites une sauvegarde chaque soir sur bande. Donc sur vos bandes vous avez la sauvegarde de vos données datées du jour à l’instant T2 (qui correspond au début de la sauvegarde sur bande, généralement le soir) + les données datées du jour à l’instant T1 (qui correspond à l’heure du snapshot, ici le midi).
En cas de crash il vous ait donc possible de revenir à la sauvegarde de la veille au soir, mais aussi à la sauvegarde de la veille à midi. Soit un RPO divisé par 2, puisqu’au lieu d’avoir une sauvegarde toutes les 24h, vous avez une sauvegarde toutes les 12h.
 
 
425- WORM(write one, read many)
______________________________________________________________________________________________
Caractérise un support sur lequel on peut écrire une fois et une seule, et qu'on peut lire autant qu'on veut.
 
La législation n'apporte (heureusement) aucune précision sur les choix techniques susceptibles de répondre aux critères indispensables à un archivage légal.  
Toutefois, cette notion d'archivage légal impose que l'on s'assure que le document que l'on a conservé puisse être restitué en apportant l'assurance qu'il n'a pu être modifié. L'utilisation d'un support inscriptible une seule fois (WORM) est donc préconisée.  
Mieux, la norme NF Z 42-013 n'accepte que les supports de type optique non-réinscriptible. Cette norme, rédigée en 1999 et mise à jour en 2001 doit être remise au goût du jour (on parle maintenant de fin 2007). Cependant, si l'obéissance à cette norme française est une piste à suivre, ce n'est pas la seule et l'unique.  
Les Worm logiques à base de disques magnétiques semblent pouvoir répondre aussi bien, voire mieux par certains aspects, aux exigences de ce type de conservation.
 
source
 
 
426- One Button Disaster Recovery Solution (OBDR)
______________________________________________________________________________________________
Une parenthèse sur une particularité HP, l'OBDR.
Il s'agit d'une option présente sur les lecteurs de bande HP qui permet, à partir d'une sauvegarde système, le boot sur la bande de sauvegarde et la reconstruction du système du serveur par simple appuie sur un bouton.
Le système se restaure en quelques dizaine de minutes, à condition que le serveur soit directement branché (SCSI) sur le lecteur.
 
 
427- Sauvegarder DB EXchange et SQL à froid
______________________________________________________________________________________________
Si Exchange et SQL peuvent être arrêtés pendant les sauvegardes, pourquoi ne pas faire l'économie des options de sauvegardes à chaud des DB Exchange et SQL?
 
Un script pré-sauvegarde contenant les lignes de commande suivantes permet l'arrêt des bases:
************************
net stop MSExchangeSA /YES
net stop mssqlserver /yes
************************
 
Un script post-sauvegarde contenant les lignes de commande suivantes permet le redémarrage des bases:
(vérifier les dépendances tout de même, suivant les versions il faudra peut être redémarrer plus de services)
************************
net start MSExchangeSA
net start MSExchangeMTA
net start MSExchangeIS
net start mssqlserver
************************
 
Pour la sauvegarde à froid se reporter aux recommandations de Microsoft:
http://support.microsoft.com/kb/296788/fr
Et lire la petite polémique (ci dessous, à partir du 12/03/2008) sur ce sujet.
 
 
5- Le Cloud Computing
______________________________________________________________________________________________
Element à ne pas négliger, l'offre n'est pas encore assez mûre pour s'étendre dessus pour l'instant(quoique l'offre IBM global services sur serveur AS400 dans le cadre de DRP existe depuis plusieurs années: mais est ce du CP?)
 
 
6- Les liens utiles, pour aller plus loin
______________________________________________________________________________________________
Ces textes, sur les bonnes pratiques informatiques, intègrent ce qui a été abordé jusqu'à présent:
- ITIL, Gestion de la Continuité des Services
- Norme ISO 17799, l'analyse de risque
- Gestion des risques informatique
- Notions sur les DRP, RCO, RPO
- Notions sur le  CDP
- Tolérance de pannes
- Le Clusif: Plan de continuité d'activité.
 
D'autres liens:
- Sur le stockage
 
Méthodologie
- La méthode MEHARI
 
...à suivre
 
 
 
7- Les guides pour administrateur des logiciels de sauvegarde
______________________________________________________________________________________________
Pour trouver de l'aide sur les logiciels de sauvegarde, voici des liens sur les guides administrateurs pour les principaux:
 
- Symantec Backup Exec:
http://ftp.support.veritas.com/pub/support/products/
 
- BrightStor ARCserve Backup:
ftp://ftp.ca.com/caproducts/ARCserve_manuals/docs/
http://download.iomega.com/qsg/arc [...] ide_fr.pdf
 
- HP Data Protector: (au moment du telechargement, preciser la langue)
http://h20000.www2.hp.com/bizsuppo [...] tId=304619
 
- IBM, Tivoli Storage Manager (TSM):
http://www.redbooks.ibm.com/abstra [...] .html?Open
 
- EMC Software ( ex legato ), Networker:
https://powerlink.emc.com/nsepn/web [...] Mode=BASIC , il faut etre inscrit sur powerlink http://powerlink.emc.com afin de pouvoir y acceder  
 
- Atempo Time Navigator:
http://fr.atempo.com/support/downloads.asp
 
______________________________________________________________________________________________
Deux choses importantes pour finir:
- Un DRP doit être testé au moins une fois par an.
- Les sauvegardes doivent être vérifiées tous les jours et suivies dans le temps.
 
Sinon les sauvegardes et le DRP perdent leurs raisons d'être et ne peuvent être garantis.
 

bien sure toute contribution ou rectification est la bienvenue

drapal

 
 
J'ai apporté quelque petites precisions ... bonne idée de topic
Si besoin je peux t'aider à developper la partie stockage.

merci, j'ai fait les modif.
Et si tu as d'autres précisions ou d'autres trucs à apporter n'hesites pas.
 
Sinon 2 précisions que j'ajouterai dans le post:
RAID1+0 est appellé aussi RAID10 (deja indiqué): au moins 2 disques en agregat et mirroré.
Quant au RAID5, tu peux mettre autant de disque que tu veux, avec un mini à 3 disques. Je vais préciser cela.
Mais le RAID10 (ou RAID0+1) n'est pas une évolution du RAID5 puisque leurs utilisations ont un but different. J'ai précisé cela aussi (usage du RAID10 pour les DB et le RAID5 pour le reste).
 
Pour l'histoire des reseaux distincts ou en redondance, je préfère ne pas l'aborder pour l'instant car c'est un sujet à part entière et/ou je préfère laisser cela à un spécialiste en reseau .

Excellent, drapal.

 
 
parfait

rectificatif: j'ai ecrit une boulette concernant le RAID0+1 et RAID10.
 
RAID0+1
Il permet d'obtenir du mirroring rapide puisqu'il est basé sur des grappes en stripping. Chaque grappe contenant au minimum 2 éléments, et un minimum de 2 grappes étant nécessaire, il faut au minimum 4 unités de stockage pour créer un volume RAID0+1.
 
La fiabilité est moyenne car un disque défectueux entraîne le défaut de toute une grappe.
 
RAID10
 permet d'obtenir un volume agrégé par bande fiable. (puisque il est basé sur des grappes répliquées). Chaque grappe contenant au minimum 2 éléments et un minimum de 2 grappes étant nécessaire, il faut au minimum 4 unités de stockage pour créer un volume RAID10.
 
Sa fiabilité est assez grande puisqu'il faut que tous les éléments d'une grappe soient défectueux pour entraîner un défaut global. La reconstruction est assez performante puisqu'elle ne mobilise que les disques d'une seule grappe et non la totalité.
 
Dès que j'ai du temps, je corrigerai cette partie là.

c'est cool, ça avance bien   .... j'apporte d'ailleurs ma contribution
 

:-)

Voila, je pense avoir fait le tour, il manque plus que des exemples de rotation.
J'ai traité du GFS, si vous en avez d'autres je suis preneur.  
Pas des trucs tordus mais des méthodes largement utilisées et validées.

J'ai ajouté une 6eme partie avec des liens sur les guides pour administrateur sur des logiciels de sauvegarde. Pour l'instant il y a ceux là:
- Symantec Backup Exec
- BrightStor ARCserve Backup  
- HP Data Protector
 
si vous utilisez d'autres logiciels et que vous avez les liens sur les documentations techniques, je suis preneur.
merci

drapo

drapo aussi

une seule remarque ...  
 
Bravo !  
 
Drapalisé

Pour le point 6, tu peux rajouter
 
IBM, Tivoli Storage Manager ( TSM )
http://www.redbooks.ibm.com/abstra [...] .html?Open
 
EMC Software ( ex legato ), Networker
https://powerlink.emc.com/nsepn/web [...] _irrt=true , il faut etre inscrit sur powerlink http://powerlink.emc.com afin de pouvoir y acceder

 
je le fais de suite, merci

Une partie 3.2 a été ajoutée.
Il s'agit de la tolérance de panne sur les serveurs.
Toute contribution est la bien venue ... je risque surement d'oublier des choses
merci

Très interessant ce sujet

 
Super travail
 
 

great

Article très intéréssant.
 
Pour la partie 6 (Les guides pour administrateur des logiciels de sauvegarde) voilà un lien supplémentaire  
 
http://fr.atempo.com/products/time [...] efault.asp

 
Merci, c'est ajouté. J'ai directement mis le lien sur la page documentation.

Voila... terminé (normalement!).
 
Je n'ai pas traité le clustering qui est un sujet à lui tout seul et seulement abordé la virtualisation qui est aussi un sujet à elle seule.
 
Bien sure ce n'est qu'une introduction à la sauvegarde, tolérance de panne et DRP mais j'espère avoir apporté pas mal de billes.
Si des points semblent manqués, avoir été mal abordés ou même si des liens ou précisions vous viennent en tête merci de les poster ici.
 
 

Comme me l'a fait remarquer Damienmarlin je n'ai pas abordé la sauvegarde distante.
C'est fait: le point 412 a été ajouté, il traite du Wide Area Files Services (WAFS). Par manque de temps j'ai mis un lien sur wikipédia, j'y reviendrai plus tard
 
Edit: du coup j'ai trouver un site qui expliquait le WAFS, j'ai mis le lien.

ok

oui c vrai akabis la sauvegarde deporté enleve le côté humain et donc reduit encore plus la gestion.
Après sur ces offres la protection du flux des donées est importante. Et dans les deux sens (car certaines offres ne sont pas sécurisé lors de la restauration).
Et dernire point important, certaines offres de sauvegarde deporté font même disposé au client une machine en envoi express avec ces donées.
Sympa pr redemmarrer par ex après un vol
ps: la limite de cette solution c'est bien sur le volume a sauvegarder.

Je ne pense pas parler des offres de prestaires qui proposent des sauvegardes chez eux.
Par WAFS je pensais plutot aborder la sauvegarde box to box au sein d'une même entreprise
Après, à l'autre bout d'une box, que ce soit la même entreprise ou un presta ça change pas grand chose, hormis les offres et les config à la mode de chez le prestataire.

ok c'est un peu dommage du fait de l'avantage que çà peut apporter pour des petites structures mais je comprend mieux l'objectif de ton topic. Qui est fort bien détaillés dans son objectif.
Bravo en tout cas.

 
Très bon guide, sauf pour cette partie. SQL, Exchange, Oracle et autres bases de données ont des systèmes de rotation de journaux qui nécessite une sauvegarde par Agent ou outil intégrés afin d'effectuer :
 

• Une vérification de la base de donnée : En cas d'erreur la sauvegarde est annulée

Ce qui n'est pas vérifié moteur arrêté. Vous pouvez sauvegarder pendant 10 ans une base corrompu et non identifiée en production et donc non restaurable

• Un tronc des logs :  

Sinon vos journaux ont une taille qui augment indéfiniement
 
La sauvegarde à froid n'est utilisable que dans un seul cas. Quand la base est corrompue, avant de la restaurer on faut une sauvegarde à froid pour revenir en arrière.
 
Note :
Exchange (ntbackup) , Oracle et SQL Server (SQL Agent) intègre des outils de sauvegarde à chaud gratuit... la question ne se pose même plus.

Pour les bases Oracle, c'est RMAN

Je n'ai jamais parlé d'Oracle dans le tuto.
 
Pour Sql tu peux en effet faire une sauvegarde des bases et des journaux de transaction via l'assistant de sauvegarde du gestionnaire d'entreprise.
Mais suivant la taille des bases ou leurs nombres, cette sauvegarde peut être très longue.
La sauvegarde à froid est une solution.  
J'utilise les 2 méthodes et jamais eu de pb de restauration pour les backup à froid.
 
Concernant Exchange, même problème... les temps de sauvegarde.
Tu veux d'abord faire une sauvegarde via ntbackup et ensuite sauvegarder le fichier bkp???
Pour commencer tu utilises 2 systèmes de sauvegarde, donc 2 fois plus de risque d'erreur.
Ensuite lorsque tu as deux ou trois centaines de bal + les autres sauvegarde, tu ne t"amuses pas à ça lorsque ta fenêtre de backup est restreinte.
Idem, j'utilise les 2, jamais eu de souci.
 
Pour ntbackup, ça va bien pour dépanner c'est tout... En plus je ne suis même pas sure qu'il gère les autoloader.

Entre ce que tu fais et qui marche à 95 % et ce qui ce fait de bien et qui marche à 100% il y a un gap. Le gap représente l'incapacité de restaurer dans 5% des cas. Ces 5% ne sont pas acceptables pour une entreprise.
 
 
Désolé, on ne sauvegarde pas à froid les bases de données pour les raisons que j'ai cité. Ce n'est pas pour rien que les agents existent. Tout le reste de ton guide est nickel, mais sauf cette partie.
 
Crois moi, je n'ai rien contre toi, c'est comme ça qu'on fait...
 
PS : Si la sauvegarde est plus lente c'est justement parce qu'il ne se contente pas de copier les fichiers, il y a un travail de maintenance essentiel sur les bases de données.
 
Je pourrais si tu le veux te donner un cas client que j'ai expérimenté si tu le veux.
 
Rajoutons à celà, le fait que sans sauvegarde à chaud, les logs de ces bases augmentent infiniement selon leur paramétrage.

J'aimerais que tu nous expliques comment une base sauvegardé proprement a froid ne pourrait pas redémarrer dans 5 % des cas (chiffre purement arbitraire ou il y'a un vrai calcul derrière ?). Une sauvegarde à froid permet de sauvegarder l'intégralité des fichiers base fermée, on est d'accord jusque la ? A partir de la, si tu reposes ces fichiers ailleurs et que tu redémarres la base, qu'est ce qui peut gêner ? j'aimerais franchement un cas concret pour comprendre la.
Dans ma petite experience d'environnement de prod, j'ai jamais vu de problème de redémarrage de base arreté a froid. Mais alors par contre les agents de sauvegardes a chaud (de gros éditeurs en général, Tina, Backup Exec), la j'en ai vu des soucis de corruptions.
D'ailleurs sous oracle, et le fameux outils RMAN, il y'a qq versions buggées qui oubliaient de sauvegarder les logs generé pdt le backup, emmerdant non ?

Pour moi les agents ont été créés pour permettre la prod 24/24 de tourner, et pour alléger les sauvegardes puisqu'on peut faire de l'incremental avec. Mais de la a dire que c'est plus sécurisé qu'une sauvegarde à chaud, je ne m'y risquerais pas.

 
Tu as tout à fait raison les 5% sont arbitraire et n'avaient pour but que de démontrer que l'expérimentation d'une personne qui toute sa vie n'a pas d'accident en roulant à 200km sur l'autoroute, ne démontre pas pour autant que sa pratique est bonne.
 
Vous savez les sécurités en informatique, on n'en a besoin qu'en cas de problème , normal.
 
 
Pour expliquer mon propos, je prendrais l'exemple sur un cas client que j'ai déjà connu par 3 fois en pratique.
 
Sauvegarde à froid et ces conséquences
 
Je rappelle => Expension des logs sauf  
si les logs circulaires sont activés sous Exchange et le mode de récupération simple sous SQL Server.
Voyez déjà on est dans un cas particulier, dans lequel, la sauvegarde à froid est possible. Sinon Expension infinie des logs
 
Mais parlons des effets de bord possibles
La base a eu une corruption qui dans le temps s'est aggravé. Lorsque notre équipe a fait un esenutil, nous avons pu repérer et avions la possibilité de supprimer les index corrompus pour réparer la base. L'inconvénient c'est qu'avec le temps, le nombre de page abimé était tel, que c'était quelques BAL importante (DG) qui sautaient.
 
Solution : On restaure une sauvegarde.
 
Sauf que, sauvegarde à froid = Moteur Exchange éteind => Pas de validation de la sauvegarde par Exchange lui même.
 
Nous avons du remonter des sauvegardes sur 6 MOIS avant de retrouver une version consistente de la base de donnée, là ou une sauvegarde à chaud aurait révélé, la panne le jours même.
 
 
Il faut savoir qu'au début de l'opération de sauvegarde, le moteur d'exchange ou SQL font des vérifications poussée de l'état de la base (qu'il ne font pas forcément en production à cause des impacts de performances) grâce au paramétrage de votre outil de sauvegarde. Lors d'une sauvegarde à froid, les moteurs de bases sont éteinds. Aucune vérification n'est possible. C'est une chose que de sauvegarde un fichier consitent et une base consistente. Le fichier Windows peut être valable, mais la base de donnée non. Dans notre cas, rien n'empechait de copier le fichier 1000 fois (consistence au niveau fichier), mais au niveau base elle ne l'était pas. Windows regarde l'enveloppe du fichier, mais pas son contenu. Analogie simple, prenez un fichier Word, ouvrez le avec le bloc note et supprimer quelques lignes dans l'entête.
Pour Windows le fichier sera tjrs viable, mais Word n'en voudra plus.
Si une base est détectée comme étant corrompu, la sauvegarde est refusée par le moteur. Et vous avez ainsi un message d'erreur de votre outil de sauvegarde, le jour même vous indiquant que la sauvegarde a été refusée.
 
Exemple de message pour Exchange 2003 : http://support.microsoft.com/kb/810333/en-us
 

 
La sauvegarde à froid a bien vécu dans les SI du temps des produits telque Exchange 5.5 et SQL 7. Mais les bases de données ont évoluées depuis et les outils de sauvegarde ont du eux aussi évoluer. Une sauvegarde à chaud (je ne suis pas le seul à en parler) est aujourd'hui une nécessité et n'est plus un choix technique ou de cout. Avec la sauvegarde à froid on ferme les yeux sur un potentiel problème, et bien sur, si vous n'avez jamais d'arrêt violent de vos systèmes, ou de log (société souhaitant récupérer la moindre transaction), vous passez à travers les mailles du filet à problème. Tant mieux, mais est-ce pour autant une position responsable pour un Ingénieur ou un Architecte informatique, je ne crois pas.

Pour Exchange, la sauvegarde à froid (ou hors connexion) n'est absolument pas déconseillé par Microsoft.
Il est vrai que ça marche mieux depuis Exchange 2000.
De plus il me semble bien avoir lu sur un des site de MS qu'un arrêt des bases (un arrêt correct j'entends) lançait une vérification des celles ci.
 
L'outil "eseutil" sert justement aux vérif de base (mais pas seulement) et est conseillé par Microsoft pour toute sauvegarde à froid... Ils en font un peu trop de ce coté là afin de limiter les appels vers la hotline (à mon avis).
D'ailleurs Microsoft explique comme faire une sauvegarde à froid, des (sur)précautions à prendre ici: http://support.microsoft.com/kb/296788/fr
 
Quant à parler d'une "position responsable pour un Ingénieur ou un Architecte informatique", tu y vas un peu fort.
Lorsque tu as un budget "no limit" (c'est pas courant mais ça existe, j'ai vu ça) là tu n'as aucune excuse pour te passer de toutes les options d'un logiciel de sauvegarde.
Quand tu dois faire le choix entre des modules pour sauvegarde à chaud de certains logiciels (ça se compte en centaine d'€) et le dernier PDA à la mode que veut le DG... là, il n'y a plus de choix possible.
Eh oui, bon nombre de petites boites n'allouent pas de budget à l'informatique et il faut faire avec les moyens du bord.
 
Maintenant j'ai entendu tes arguments, je vais ajouté un commentaire dans le tuto renvoyant à cette discussion et pour Exchange je vais faire un renvoi vers le site de MS cité ci dessus afin que EUSEUTIL soit utilisé en cas de sauvegarde à froid des Db Exchange.
 
EDIT: pour parler de mon expérience personnelle, je n'ai jamais eu de pb avec les sauvegardes à froid des bases Exchange. Alors que j'en ai rencontré avec les sauvegardes à chaud.
Et que recommande MS lorsqu'une sauvegarde à chaud ne fonctionne pas... une sauvegarde à froid  

Edit : Reponse à Jef
 
Certes, mais le problème que tu évoques vient tout de même d'une absence de maintenance sur la base. Dans un environnement de prod, quand il s'agit de très grosses bases (comme de la messagerie exchange), il y'a quand même un minimum de maintenance a effectuer régulièrement. Je ne connais pas trop exchange mais je suppose qu'il est possible de de lancer un defrag de la base ... etc etc...
 
Je pense qu'on ne peut pas diaboliser la sauvegarde à froid sous prétexte de qq mauvaises experiences. On doit pouvoir trouver tout autant de problèmes sur de la sauvegarde à chaud. Pour moi la sauvegarde doit être adapté à l'environnement et au moyen de l'entreprise.
Quant aux archives logs, effectivement, la rotation se paramètre et ça fait parti de la maintenance de l'environnement.

En tout cas joli sujet Akabis. Juste une remarque, DRP, en france on a plutot tendance a parler de PRA
Sinon, dans ma société, on est train de passer sur du la virtualisation complète. On pratiquait deja un peu avant avec des ESX Starter, mais ce coup la, on est carrement sur du SAN, avec du Virtual Infrastructure.  
La souplesse du truc est assez géniale, mais du coup on se retrouve avec pas mal de méthodes pour la sauvegarde. Il va nous rester a choisir maintenant, sachant qu'on risque de faire quelques économies sur les agents de sauvegardes.

L'outil s'appelle EUSEUTIL

Sinon (pour dévier du sujet), si un jour j'ai le temps, je mettrai une procédure DRP (les grandes lignes car chaque DRP est particulier) vu je suis en train de mettre en place mon 2eme dans un structure type moyenne structure (filiale de groupe, je ne compte pas ceux fait dans les agences de 20 personnes)... enfin si ce coup si ça marche encore lol
 
EDIT:  
Voila c'est fait: 21- Exemple de mise en place de DRP