Récupérer un serveur NAS moderne est une tâche complexe

Vous pensez que récupérer un serveur de stockage en réseau (NAS) « bon marché » est une tâche simple ? Eh bien détrompez-vous ! Les serveurs NAS peuvent être des serveurs de stockage basés sur le RAID peu coûteux et destinés aux petites et moyennes entreprises, mais de nos jours ils sont d’un point de vue technique presque aussi complexes et difficiles à récupérer que leurs homologues haut de gamme (et plus chers également) de chez Dell EMC, HP et autres marques. Sachant que la plupart de ces « petits » supports de stockage sont à présent dotés des mêmes fonctionnalités avancées que les versions haut de gamme, telles que la déduplication, la prise en charge de la virtualisation, le ciblage iSCSI, et d’autres, leurs données sont structurées dans de nombreuses couches différentes, lesquelles doivent être récupérées et restructurées les unes après les autres pour enfin atteindre les fichiers de données « réels ».

Ceci fut le cas lorsqu’un client récent de la branche allemande de Ontrack a rencontré une défaillance avec son NAS QNAP. Le système basé sur le RAID 6 était composé de 24 disques durs avec une capacité de 6 terabytes chacun. Pendant la configuration, deux LUN iSCSI ont été créés contenant plus de 40 et 60 terabytes de données. Chaque LUN était la cible iSCSI d’un système Windows Server 2012 R2 et formaté en partition NTFS. D’autre part, la fonctionnalité déduplication de Windows Server 2012 R2 était présente sur les deux LUN. Un jour, lorsque le client – le service informatique d’un grand groupe immobilier – fit face à un ralentissement du NAS, le système a été stoppé brutalement (sans arrêter le système correctement). Ceci entraîna une impossibilité d’accéder aux LUN, bien que les lettres des lecteurs fussent affichées. Et bien pire pour le client : il n’existait aucune sauvegarde disponible !

Le client contacta alors Ontrack et ses spécialistes. L’analyse montra que pour ce qui était du processus de récupération des données, six couches de structure des données ont dû être manipulées les unes après les autres dans ce projet. Étant donné qu’un NAS QNAP fonctionne avec un système de données Linux, les spécialistes durent d’abord reconstruire la couche RAID6 du NAS QNAP pour atteindre le système de fichiers EXT4 de Linux. Dans ce système de fichiers EXT4, des fragments des LUN furent trouvés et durent être reconstruits pour obtenir l’accès aux 64 et 44 Teras de données brutes des LUN. La taille de chaque fragment était d’environ 1 Tera chacun, ainsi plus de 100 gros « morceaux de données iSCSI » ont dû être manipulés, structurés et assemblés pour reconstruire chacun des deux LUN iSCSI.

Ces fragments iSCSI étaient à l’origine gérés par le système NAP et combinés au fur et à mesure, ainsi le système Windows Server croyait pouvoir accéder à deux LUN existants. Les experts en récupération des données s’arrangèrent pour combiner ces fichiers iSCSI LUN en un seul volume NTFS après que les fichiers iSCSI ont été copiés bloc par bloc vers un support de stockage SSD temporaire. Étant donné que la déduplication était également activée dans Windows Server sur ce système, les ingénieurs durent travailler sur cette sixième et dernière couche et durent chercher les données qui étaient affectées par cette fonctionnalité pour créer un volume NTFS utilisable que le client a été en mesure d’utiliser.

Ce volume NTFS fut ensuite copié à partir du support de stockage SSD vers un nouveau système de stockage RAID que le client pourrait associer facilement à son réseau afin d’avoir de nouveau accès aux données perdues.

Même avec les propres outils de récupération hautement spécialisés de Ontrack, parvenir à récupérer et copier un tel volume de données sur le nouveau support de stockage nécessita plusieurs semaines. L’analyse finale de ce cas important de récupération des données par les experts de Ontrack a démontré clairement que de toute évidence, le serveur NAS n’avait pas été configuré correctement après son achat et sa mise en activité, et il est possible qu’il s’agisse de la principale raison de cette défaillance. Comme il a été décrit, la récupération des données – en raison de l’immense quantité de données stockées sur le serveur – a demandé beaucoup de temps. C’est pourquoi il est très important de configurer un serveur NAS correctement avant d’y stocker des données. Par ailleurs, il est judicieux de prévoir à l’avance toute situation de perte de données telle que celle-ci.

Et ce cas de perte de données montre également ceci : bien que ce système NAS soit doté de nombreuses fonctionnalités avancées, celles-ci ne doivent pas toutes être utilisées, sachant que les serveurs de petite et moyenne taille tels que celui-ci sont très certainement beaucoup moins à l’abri d’une défaillance que leurs homologues haut de gamme. Ainsi, l’utilisation de la fonctionnalité déduplication dans ce cas précis n’était sans doute pas une bonne idée, sachant qu’elle a rendu la récupération des données bien plus complexe. Et comme les disques durs d’un tel système sont devenus très abordables au cours des dernières années, il aurait peut-être été préférable d’acheter des disques supplémentaires plutôt que de rendre la structure inutilement plus complexe, et en agissant de la sorte, prendre le risque que même les experts en récupération des données ne puissent un jour plus intervenir dans un délai acceptable et pour un coût raisonnable.