On dit toujours qu’il faut faire des backups, encore des backups, toujours plus de backups. Ce qu’on a tendance à dire moins souvent c’est que tant que les données n’ont pas été restaurées avec succès un backup ne sert à rien.

Un exemple marquant est le cas de Ma.gnolia, site social où il était possible de stocker des marque pages sur Internet. Le 30 Janvier dernier, le site a subit un crash catastrophique de sa base de données MySQL 5, entraînant de fait la coupure du site. Ce crash était du à une corruption de données étalée dans le temps (non détectable a priori sans véritable contrôle de cohérence) qui a aussi corrompue les backups. Un passage par des spécialistes de la récupération de données n’a malheureusement rien donné non plus, ce qui signifie une perte totale de près de 500 Go de données utilisateurs et la mort effective du site dans sa version actuelle. Heureusement des systèmes de caches sur d’autres sites Internet (FriendFeed, flux RSS, etc) ont permis à certains utilisateurs de récupérer une partie de leurs données.

Voici un podcast où le responsable de Ma.gnolia explique un peu plus en détails ce qu’il s’est passé :

Citizen Garden Episode 11: Whither Ma.gnolia? from Larry Halff on Vimeo.

La leçon principale à retenir pour un opérateur de backups est donc ici de régulièrement tester jusqu’au bout sa procédure de restauration de données. Il est aussi utile, bien que techniquement parfois difficile voire impossible, d’effectuer des vérifications de cohérences des données à sauvegarder ainsi que des backups.

Sur un de nos serveurs SQL j’utilisais une carte contrôleur RAID Adaptec 2810SA avec trois disques SATA en RAID 5. Le serveur a soudainement rendu l’âme : au démarrage il restait bloqué sur la phase d’initialisation de la carte et finissait par afficher un time out.

Heureusement je disposais d’une carte Adaptec 2820SA, et comme ces cartes stockent la configuration du RAID sur les disques eux-mêmes et non pas en cache, le changement de carte était envisageable avec un bon espoir de ne perdre aucune donnée. J’ai donc enlevé la carte 2810 en notant l’ordre de branchement des trois disques durs, ajouté la 2820 puis rebranché les disques dans le même ordre. Au démarrage la carte s’initialise correctement et affiche un message indiquant la présence d’un RAID 5 étranger qu’il faut alors accepter comme configuration à utiliser. Le RAID 5 passe alors en mode Recovery/Verifying et est immédiatement utilisable.

Problème toutefois : la version de la carte n’étant pas tout à fait la même, Windows 2003 Enterprise R2 rebootait au lancement. Il a donc été nécessaire de le réinstaller en mode réparation et en fournissant une disquette avec les pilotes de la nouvelle carte contrôleur RAID. Une fois cela terminé, l’ensemble des données et des programmes installés était opérationnel et le serveur a pu repasser en production.

Au total la période de downtime a été de trois heures, ce qui pour un serveur « noname » est plutôt acceptable, surtout sans perte de données.

Suite à la mort brutale et simultanée de deux des trois disques durs montés en RAID 5 de mon serveur SQLServer 2000 (comme quoi c’est possible), j’ai du reconstruire en urgence un nouveau serveur. Pour rappel on peut perdre un disque dur dans une grappe RAID 5 sans perte de données, au delà on perd tout… Je détaille ici les étapes que j’ai suivi pour restaurer entièrement les données.

Continuer à lire "Restauration de SQL Server"