Points clés à retenir
- Les workflows de restauration traditionnels peuvent entraîner un décalage de l’infrastructure dans les environnements gérés par Terraform, en provisionnant de nouvelles ressources en dehors de l’état.
- Clumio Backtrack est conçu pour restaurer les données directement dans les buckets S3 et les tables DynamoDB existants, ce qui permet de préserver l’identité des ressources.
- La restauration sur site permet de réduire le recours aux importations manuelles de Terraform, à la reconfiguration des points de terminaison et au rapprochement des états en cas d’incident.
- L’alignement des processus de reprise sur les principes de l’« Infrastructure as Code » (IaC) permet de préserver l’intégrité de la configuration et la prévisibilité opérationnelle.
- La conception de la restauration est tout aussi cruciale que celle de la sauvegarde pour les équipes qui gèrent des environnements de production via Terraform.
L’IaC apporte cohérence, reproductibilité et contrôle des versions aux cloud. Terraform devient la référence absolue concernant ce qui existe, comment cela est configuré et comment cela doit fonctionner. La restauration pose un nouveau défi.
Les opérations de restauration classiques créent souvent de nouvelles ressources : de nouveaux compartiments S3, de nouvelles tables DynamoDB, de nouveaux points de terminaison. Du point de vue de Terraform, ces ressources n’ont pas été définies dans le code. Elles n’existent pas dans l’état. Cela crée un écart. Dans le cadre des opérations courantes, cet écart reste gérable. Lors d’un incident, il s’aggrave. C’est là que la conception de la reprise revêt autant d’importance que celle de la sauvegarde.
Le problème de la dérive de l’IaC
Dans un modèle de restauration classique :
- Une ressource protégée est restaurée en tant que nouvelle ressource.
- La ressource d’origine reste dans un état corrompu, écrasé ou défaillant.
- L’état Terraform ne reconnaît pas la nouvelle ressource.
- Les équipes doivent importer manuellement les ressources dans State.
- Il se peut que les configurations des applications doivent être mises à jour.
Pour platform qui gèrent l’infrastructure de production via Terraform, cela crée des frictions au pire moment possible. Le défi ne réside pas dans la fiabilité des sauvegardes en soi, mais dans la manière dont les workflows de restauration s’intègrent aux pratiques d’« infrastructure as code ».
Présentation de la restauration sur site avec Clumio Backtrack
Clumio Backtrack est une fonctionnalité de restauration qui permet de restaurer des données directement dans des ressources AWS existantes, sans avoir à provisionner une infrastructure de remplacement. Lorsqu’elle est configurée via le fournisseur Clumio Terraform, Backtrack permet de mettre en place des workflows de restauration conformes à l’infrastructure définie par code.
Clumio Backtrack prend en charge à la fois Amazon S3 et Amazon DynamoDB. Pour une analyse technique plus approfondie des workflows de restauration spécifiques à DynamoDB, consultez notre article de blog consacré àClumio Backtrack pour DynamoDB.
Au lieu de mettre en place des ressources de remplacement, Backtrack facilite la restauration :
- Les objets S3 sont stockés directement dans le compartiment d’origine.
- Les données DynamoDB directement dans la table d’origine.
Du point de vue de Terraform, l’infrastructure est censée rester inchangée, les ressources définies continuant à correspondre à la configuration déclarée. Cela permet de réduire le recours aux importations manuelles de ressources, aux tables de restauration temporaires, à la reconfiguration des points de terminaison et au rapprochement des états en situation de pression.
Un exemple concret
Imaginons un environnement de production entièrement géré via Terraform. Une table DynamoDB gère les stocks ; un compartiment S3 stocke les ressources de l’application ; les rôles et les politiques de gestion des identités et des accès sont codifiés ; et les politiques de protection sont définies via Terraform. Si une corruption survient avant un pic de trafic important, les méthodes de restauration traditionnelles peuvent créer de nouvelles ressources qui devront être réintégrées dans Terraform.
Avec Backtrack, la restauration est conçue pour s’effectuer dans les limites des ressources existantes, ce qui permet de préserver l’intégrité de l’infrastructure définie et de conserver l’identité des ressources. Cette approche vise à éviter d’avoir à mettre à jour Terraform pour prendre en charge un bucket ou une table nouvellement créé(e), en considérant la restauration comme une opération au niveau de la couche de données plutôt que comme un processus de remplacement de l’infrastructure.
Pourquoi est-ce important pour Platform ?
Pour les équipes qui ont adopté l’IaC, les workflows de reprise doivent préserver l’identité des ressources, l’alignement des états, l’intégrité de la configuration et la prévisibilité opérationnelle. La restauration sur place contribue à la réalisation de ces objectifs en limitant les modifications apportées à l’infrastructure lors des opérations de reprise.
Récupération à Cloud
Backtrack est conçu pour fonctionner à cloud , qu’il s’agisse de restaurer un petit nombre d’objets ou de grands ensembles de données. Les performances de restauration varient en fonction de la taille de la charge de travail et de la configuration de l’environnement, mais l’objectif architectural reste le même : restaurer les données sans entraîner de nouveaux écarts au niveau de l’infrastructure. Pour les environnements gérés par Terraform, cette distinction est importante.
Dans quel contexte cette approche s’inscrit-elle ?
La restauration sur site est particulièrement indiquée dans les cas suivants :
- Charges de travail DynamoDB à haut débit
- Compartiments S3 contenant un grand nombre d’objets
- Systèmes de production entièrement gérés via Terraform
- dans des environnements complexes où il est difficile de rediriger les dépendances des applications vers de nouvelles ressources
Lorsque l’infrastructure est définie de manière déclarative, les processus de reprise doivent s’aligner sur cette même approche.
Pour commencer
Pour découvrir Clumio Backtrack et son intégration avec Terraform :
- Consultez ladocumentation relative au fournisseur Clumio Terraform.
- Découvrez le codesource du fournisseur sur GitHub.
- Regardez lavidéo de démonstration de Backtrackintégrée ci-dessus.
Définir la protection sous forme de code n’est qu’une partie du processus. La conception de workflows de reprise qui préservent l’intégrité de l’infrastructure vient compléter ce modèle.
FAQ
Q : Quels problèmes les restaurations traditionnelles posent-elles dans les environnements gérés par Terraform ?
R : Les restaurations traditionnelles créent souvent de nouvelles ressources, telles que des compartiments S3 de remplacement ou des tables DynamoDB, qui ne sont pas définies dans l’état Terraform. Cela peut entraîner une dérive de l’infrastructure et obliger les équipes à importer manuellement des ressources et à harmoniser les configurations lors d’incidents critiques.
Q : En quoi Clumio Backtrack se distingue-t-il des méthodes de restauration classiques ?
R : Au lieu de déployer une nouvelle infrastructure, Clumio Backtrack est conçu pour restaurer les données directement dans la ressource AWS existante. Cette approche permet de préserver l’identité de la ressource et de maintenir l’état de Terraform en adéquation avec la configuration déclarée.
Q : Quels sont les services AWS pris en charge par Clumio Backtrack ?
R : Clumio Backtrack prend en charge Amazon S3 et Amazon DynamoDB. Il est conçu pour restaurer les objets S3 dans le compartiment d’origine et les données DynamoDB dans la table d’origine, ce qui permet de garantir la cohérence avec l’infrastructure définie par code.
Q : Pourquoi la restauration sur site est-elle importante pour platform ?
R : Platform s’appuient sur l’infrastructure en tant que code pour garantir la cohérence et le contrôle. La restauration sur place permet de maintenir l’alignement des états, l’intégrité de la configuration et la prévisibilité opérationnelle sans introduire de modifications supplémentaires au niveau de l’infrastructure lors des opérations de restauration.
Q : Dans quels cas la restauration sur site s’avère-t-elle particulièrement utile ?
R : Cette solution est particulièrement utile pour les charges de travail DynamoDB à haut débit, les compartiments S3 contenant un grand nombre d’objets et les systèmes de production entièrement gérés via Terraform. Elle peut également s’avérer avantageuse dans les environnements où la redirection des dépendances des applications vers des ressources nouvellement créées s’avérerait complexe ou risquée.
Q : Comment les équipes peuvent-elles se lancer dans l’intégration de Clumio Backtrack et de Terraform ?
R : Les équipes peuvent consulter ledocumentation relative au fournisseur Clumio Terraform, explorer lecode source du fournisseur sur GitHubet visionner la vidéo de démonstration « Backtrack » mentionnée dans l’article de blog pour comprendre les détails de la mise en œuvre et du flux de travail.
Lawrence Chang est directeur technique chez Clumio et Vir Choksiest responsable principal du marketing produit chez Commvault.
