SQL : il est temps de mettre les données de sauvegarde au travail !

Pour des raisons évidentes de qualité des données, de centralisation de l’information et souvent de coût, beaucoup d’entreprises exécutent l’ensemble de leurs requêtes sur la même base de données.

Pour une enseigne retail, le même système peut être sollicité pour répondre - avec une diligence identique - aux besoins de vérification des hypothèses marketing et aux demandes relatives à la gestion des stocks sur le terrain. Ainsi la requête d’un commercial en facing client sur la disponibilité d’un produit spécifique dans une agence locale peut se voir ralentie par la requête de la division marketing produit au siège.

L’augmentation de la performance des systèmes est bien évidemment une solution, mais au-delà de s’avérer coûteuse, elle n’est pas forcément souhaitable, ni pérenne, car les besoins peuvent varier.

La duplication d’une base de données entière pour des besoins différents est une option, mais le temps consacré à la copie des données peut générer non seulement des erreurs, des temps de copie importants mais surtout une disparité très importante entre la base source et la base cible.

Cela reste cependant une option quand les changements “temps réel” n’ont pas un impact majeur sur l’information que l’on désire obtenir.

Le clonage de bases de données réinventé

De nombreuses entreprises qui utilisent les outils les plus modernes de protection de bases de données SQL à des fins de restauration suite à un incident ont rapidement manifesté un intérêt pour l'utilisation des copies de protection des données pour la conduite de projets de tests et de développement. Leur objectif ? Minimiser la multiplication des copies de données tout en permettant aux développeurs de travailler sur les dernières versions des données de production.

Ces mêmes entreprises ont ainsi demandé à pouvoir cloner des bases de données SQL dans des environnements dédiés au développement ou à l’analyse de données, pour lesquels la machine virtuelle ou l’environnement occuperaient l’espace de stockage le plus petit possible. Cette attente des entreprises trouve une réponse au sein de systèmes permettant de protéger les bases de données SQL via des API proposées par le fournisseur du SGBDR, mais aussi en permettant le clonage complet de la base de données vers n'importe quel serveur SQL ou instance SQL au sein d'un environnement client utilisant les mêmes API.

En clonant la base de données sur un volume entièrement distribué, hautement disponible et très performant, il devient possible de configurer les serveurs SQL de test et de développement avec une capacité de stockage primaire minimale et de continuer à faire fonctionner des serveurs SQL de plusieurs téraoctets sans qu’il soit nécessaire d’ajouter du stockage primaire. En outre, comme le serveur SQL cible et les bases de données clonées sont séparés du serveur SQL primaire et du stockage, il n'y a pas d'impact sur les performances de l'environnement de production.

Dans ce type de configuration, les clones sont créés et détruits par un flux de travail entièrement automatisé au sein de l'interface utilisateur, ce qui élimine le risque de fragmentation massive des données.

L'utilisation de ce genre de workflow de test et de développement permet le clonage instantané de bases de données directement du cluster de sauvegarde vers un autre serveur SQL, sans aucun impact sur les serveurs SQL primaires ou les contrôleurs de stockage primaires.

En d'autres termes, le serveur SQL cible n'a besoin que d'une capacité de stockage suffisante pour héberger une version du système d’exploitation et du serveur SQL compatible avec la base de données clonée, le reste étant pris en charge par le cluster de sauvegarde.

Un potentiel à exploiter

Dans un environnement traditionnel, les nombreuses copies de sets de données générées par ces besoins divers contribuent largement au “dark data” car elles occupent un espace disque conséquent, sans que la moindre gestion de leur cycle de vie ne soit appliquée. Les solutions plus modernes permettent de trouver un usage productif aux données de back-up.
Les données de back-up ont trop longtemps été au repos. Utilisées comme une police d’assurance en cas de perte de données ou d’erreur, elles représentent un centre de coût important pour les services informatiques. En 2020, il est temps de reconsidérer leur statut et d’envisager la valeur potentielle qu’elles peuvent apporter.

Cette capacité d’effectuer les tests sur un clone exact d’un système client-serveur, sans risque de mettre en péril l’environnement de production ou les données recèle une valeur inestimable pour beaucoup d’entreprises prêtes à sortir des sentiers battus pour innover. Les entreprises commencent tout juste à envisager le potentiel des données de sauvegarde.
Et à moins que décharger les systèmes en production des requêtes les moins vitales ne soit pas une priorité pour vous, il est temps d’estimer les bénéfices futurs de cette approche à l’aune des efforts requis par la validation d’une vision différente et de mettre - enfin - les données de sauvegarde au travail.

Christophe Lambert est un expert des technologies de gestion, d'optimisation et de valorisation des données secondaires. Il a plus de 20 ans d’expériences dans le recrutement, la construction et la gestion d’équipes autour de projets dans ce domaine. Il a débuté sa carrière en tant que responsable informatique de Fineduc puis a participé à la création de diverses sociétés informatiques. Il a ensuite rejoint NetApp pour y devenir responsable technique des Services Providers EMEA puis SimpliVity où il occupait le poste de Directeur des solutions de stockage hyperconvergées lorsque l'entreprise a été absorbée par HPE. Depuis 2018, il est Directeur Technique Grands Comptes EMEA, Cohesity.
https://www.cohesity.com/fr/