Guide complet pour la sauvegarde et la restauration des bases de données Cassandra

Introduction : Pourquoi les sauvegardes sont-elles importantes pour Cassandra ?

Cassandra est conçu pour ne jamais tomber en panne. La sauvegarde de Cassandra est importante, car sans une sauvegarde appropriée, des données importantes risquent d’être perdues. Alors que la réplication est un composant important qui protège contre les défaillances matérielles, elle ne protège pas contre la perte de données. Par conséquent, il est indispensable de disposer d’une sauvegarde récupérable et de stocker les copies dans un endroit totalement séparé pour sauvegarder toutes vos données.

Quels types de pannes ou d’incidents nécessitent un plan de sauvegarde et de restauration ?

Les plans de sauvegarde et de restauration sont nécessaires pour les défaillances logiques que la réplication ne peut pas résoudre. Il peut s’agir d’une suppression accidentelle, d’une corruption de données, d’un ransomware ou d’un échec de mise à niveau. Cassandra copie chaque opération sur chaque réplique simultanément, ce qui signifie qu’en cas de survenue de l’un de ces problèmes, c’est l’ensemble du cluster qui en pâtit.

Ci-dessous, nous allons explorer les défaillances et les incidents typiques qui nécessitent un plan de sauvegarde et de restauration.

• Suppression accidentelle de données : Exécution de DROP TABLE ou TRUNCATE sur le mauvais cluster, entraînant la suppression de vos données sur toutes les répliques.
• Corruption de données : Problème de logiciel, de matériel ou de système de fichiers nécessitant un retour à un état stable.
• Échec des mises à niveau : Mauvaise configuration de la base de données ou mises à niveau entraînant des données corrompues ou laissant les fichiers SSTable dans un format incompatible.
• Ransomware : Logiciel malveillant qui crypte les répertoires de données Cassandra, rendant vos données illisibles.
• Initié malveillant : Quelqu’un au sein de l’équipe qui supprime ou détruit délibérément des données (un scénario moins rare qu’on ne le pense).

Quelles sont les considérations commerciales et techniques en matière de RPO (Recovery Point Objective) et de RTO (Recovery Time Objective) ?

Le RPO et le RTO sont deux paramètres importants qui déterminent directement la fréquence des sauvegardes ou la rapidité de la restauration. Chaque décision prise par une entreprise en matière de sauvegarde découle directement de ces deux paramètres :

L ‘objectif de point de récupération (RPO) définit le niveau de perte de données que votre entreprise peut tolérer, exprimé en heures. Par exemple, un RPO de 4 heures signifie que vous ne pouvez pas perdre plus de 4 heures de données ; il faudra donc effectuer une sauvegarde toutes les 4 heures.

L’objectif de temps de récupération (RTO) , quant à lui, définit la durée d’indisponibilité de votre entreprise pendant que vous vous concentrez sur le processus de récupération. Supposons que votre RTO soit de 2 heures. Dans ce cas, vous disposez de deux heures pour reprendre l’activité ; l’entreprise pourrait avoir de graves problèmes de santé financière.

Ces deux mesures sont importantes car elles influencent les décisions de l’entreprise qui peuvent avoir une incidence directe sur votre stratégie de sauvegarde Cassandra.

Quels sont les risques liés à l’absence d’une stratégie fiable de sauvegarde des données Apache Cassandra ?

La réplication seule n’est pas suffisante pour la sauvegarde, elle représente donc un risque énorme pour toute entreprise. Les conséquences vont au-delà de la perte de données et affectent la continuité opérationnelle, la conformité et la confiance des utilisateurs. Voici les principaux problèmes auxquels les entreprises sont confrontées en l’absence d’une stratégie de sauvegarde Cassandra fiable.

• Perte permanente de données : L’absence de stratégie de sauvegarde ou une stratégie peu fiable signifie qu’il n’y a pas de voie de récupération et qu’en cas de catastrophe, ce qui est perdu ne peut pas être récupéré.
• Temps d’arrêt prolongé : Sans stratégie de sauvegarde et sans RTO et RPO clairement définis, votre entreprise peut finir par perdre plus que prévu.
• Conformité et exposition aux réglementations : Des secteurs tels que la santé et la finance sont soumis à des réglementations strictes. Sans une stratégie de sauvegarde Cassandra appropriée, la non-conformité peut entraîner des pénalités financières importantes.
• Atteinte à la réputation : Lorsque les données des utilisateurs sont en danger, les entreprises peuvent souffrir d’une atteinte durable à leur réputation, ce qui conduit à une perte progressive des utilisateurs et de la confiance au fil du temps.

Comment les architectures de déploiement d’Apache Cassandra affectent-elles les besoins de sauvegarde ?

L’architecture de déploiement de Cassandra peut fortement dicter les besoins de sauvegarde. Elle détermine le degré de risque ou de complexité de la stratégie de sauvegarde. Chaque type de déploiement présente des défis spécifiques qu’une approche unique ne peut pas résoudre.

1. Déploiements multi-centres de données

Dans les déploiements multi-centres de données, les opérations de sauvegarde sont généralement exécutées à partir d’un centre de données secondaire dédié plutôt qu’à partir des nœuds de production, ce qui empêche l’activité de sauvegarde de dégrader les performances en direct. Ce centre de données dédié reçoit les mêmes données répliquées que la production, mais traite toutes les charges de travail de sauvegarde séparément, ce qui permet de libérer les nœuds primaires pour le trafic des utilisateurs.

2. Cloud/AWS – EBS vs Instance Store

Les déploiements en nuage sur AWS nécessitent des approches de sauvegarde différentes en fonction du type de stockage. Les nœuds fonctionnant sur des volumes EBS peuvent exploiter les fonctionnalités natives d’instantané, car le stockage EBS persiste indépendamment de l’instance. Les nœuds utilisant le stockage d’instance, cependant, nécessitent des sauvegardes horaires et quotidiennes sur un stockage externe comme S3, car les données du stockage d’instance sont définitivement et irréversiblement perdues dès qu’une machine s’arrête ou redémarre.

3. Déploiements Kubernetes/Hybrides

Les déploiements Cassandra basés sur Kubernetes nécessitent de sauvegarder plus que les données SSTable. Ils dépendent également des Secrets Kubernetes, des ConfigMaps et des définitions StatefulSet qui définissent la configuration et l’identité du cluster. Sans ces éléments, les données restaurées n’ont pas d’environnement valide dans lequel s’exécuter.

4. Clusters de production multi-nœuds

Dans les clusters de production multi-nœuds, les snapshots doivent être déclenchés simultanément sur chaque nœud pour produire un point de restauration cohérent. Une sauvegarde échelonnée risque de créer des lacunes dans les données qui rendront impossible une restauration propre.

5. Archivage des journaux d’engagement

L’archivage du journal Commit préserve le journal d’écriture séquentiel de Cassandra en même temps que les instantanés réguliers, ce qui permet une restauration à un moment précis. Pour les déploiements où même de petites fenêtres de perte de données sont inacceptables, l’archivage du journal d’engagement est un composant essentiel de la stratégie de sauvegarde.

Quels sont les objectifs de temps de récupération (RTO) et de point de récupération (RPO) à prendre en compte pour la sauvegarde et la restauration de la base de données Cassandra ?

Les bons RPO et RTO pour un déploiement Cassandra dépendent de la valeur commerciale des données et de la complexité du cluster. Ces deux paramètres doivent être définis avant de concevoir une stratégie de sauvegarde.

En ce qui concerne le RPO, plus vos données sont critiques, plus votre point de récupération doit être serré. Le RPO définit la perte de données acceptable et détermine la fréquence des sauvegardes. Prenons l’exemple d’une plateforme de traitement des paiements enregistrant des transactions en direct, qui peut nécessiter un RPO de quelques minutes.

En ce qui concerne le RTO, Cassandra exige des attentes honnêtes. Contrairement à une base de données à serveur unique, où la restauration peut prendre quelques minutes, la restauration d’un cluster Cassandra distribué implique la copie des données sur plusieurs nœuds, le redémarrage des services et l’exécution d’opérations de réparation pour synchroniser les répliques.

Comment la sauvegarde de Cassandra s’intègre-t-elle dans une stratégie plus large de protection des données d’entreprise ?

Pour les petites entreprises opérant dans leur secteur d’activité, l’utilisation de la seule stratégie de sauvegarde Cassandra est suffisante. Cependant, dans le cas des grandes sociétés et des entreprises, la sauvegarde de Cassandra ne fonctionne pas de manière isolée, mais s’intègre plutôt dans un cadre plus large de protection des données.

Pourquoi la sauvegarde au niveau de la base de données n’est-elle pas suffisante pour assurer la résilience de l’entreprise ?

Contrairement aux startups et aux entreprises de taille moyenne, les entreprises gèrent un énorme volume de données. Dans de tels scénarios, il est difficile pour toutes les équipes de gérer leur propre sauvegarde de manière indépendante, car

• Les organisations perdent la trace de ce qu’elles protègent réellement.
• Des problèmes majeurs ou des catastrophes, comme une attaque de ransomware, affectent plusieurs systèmes simultanément.

La résilience de l’entreprise ne se limite pas à la sauvegarde des bases de données. Bien que chaque équipe fasse de son mieux de manière isolée, il faut toujours un système universel qui gère tout et garde le contrôle en cas de problème. Ainsi, pour les grandes entreprises, Cassandra ne fonctionne pas séparément, mais plutôt avec d’autres systèmes importants qui nécessitent une protection dans le cadre de politiques cohérentes.

Comment les sauvegardes Cassandra s’intègrent-elles aux plateformes de sauvegarde d’entreprise ?

Les sauvegardes Cassandra s’intègrent aux plateformes de sauvegarde d’entreprise par le biais de plugins désignés, qui deviennent ensuite partie intégrante de l’ensemble unifié de l’entreprise. Nous vous présentons ci-dessous les fonctionnalités et les possibilités qu’elles offrent une fois intégrées à la plateforme de sauvegarde de l’entreprise.

• Gestion automatique des instantanés : La plateforme planifie et exécute automatiquement la commande nodetool snapshot sur tous les nœuds à la fois.
• Coordination entre les nœuds : Le plugin de sauvegarde Cassandra coordonne tous les nœuds de l’ensemble du cluster.
• Emplacement de stockage centralisé : Les fichiers sont transférés des nœuds individuels vers un emplacement de stockage centralisé.
• Pas de nettoyage manuel : La plateforme supprime automatiquement les anciens fichiers inutiles.
• Surveillance et alerte : En cas de problème, les plateformes identifient et alertent l’équipe, ce qui permet de résoudre rapidement les problèmes.
• Prise en charge du processus de restauration : Lorsque la restauration est nécessaire, la plateforme gère tout de A à Z.

Comment les systèmes de sauvegarde centralisés réduisent-ils le risque opérationnel ?

L’utilisation d’un système de sauvegarde centralisé peut avoir un effet positif sur l’efficacité opérationnelle de l’entreprise. Dans le tableau ci-dessous, nous allons explorer les risques typiques que les sauvegardes individuelles posent aux entreprises et comment un système de sauvegarde centralisé peut réduire de manière significative les risques opérationnels.

Une plateforme centralisée permet de se défendre contre les ransomwares et de renforcer la sécurité et la conformité.

Quelles sont les stratégies de sauvegarde de Cassandra disponibles ?

La sauvegarde de Cassandra ne suffit pas à répondre aux besoins des entreprises. Elle ne concerne qu’un système à la fois, alors que les entreprises ont besoin de plusieurs systèmes avec une protection coordonnée et cohérente. Une seule sauvegarde isolée ne peut pas protéger l’environnement d’une entreprise. Elle a besoin d’une stratégie de protection des données centralisée qui unifie tout dans un cadre unique et qui met en œuvre des politiques, une surveillance, des alertes et des procédures de récupération cohérentes.

Qu’est-ce que la sauvegarde instantanée Cassandra et quand devriez-vous l’utiliser ?

La sauvegarde instantanée Cassandra crée une copie ponctuelle de toutes les tables SST, exécutée par la commande nodetool snapshot. Elle ne nécessite pas de stockage supplémentaire, mais crée plutôt des liens en dur pour ce moment précis qui sont gelés, et qui peuvent être utilisés ultérieurement pour récupérer les informations que vous aviez en cas de problème ou de perte de vos données.

Avant toute opération à haut risque, il convient d’utiliser la sauvegarde des instantanés Cassandra. De tels scénarios incluent

• Les mises à jour à grande échelle
• Changements de schéma
• Suppression de données en masse

Important : Il est fortement recommandé d’exécuter des instantanés quotidiennement ou occasionnellement. Une fois la sauvegarde créée, transférez-la sur un support de stockage externe. La sauvegarde Cassandra S3 est l’approche la plus répandue. Vous pouvez la transférer sur Amazon S3, qui protégera vos instantanés et garantira la sécurité de toutes vos données.

Quelle est la différence entre les sauvegardes complètes, incrémentielles et différentielles ?

Cassandra propose trois catégories principales de sauvegardes :

• Sauvegarde complète
• Sauvegarde incrémentale
• Sauvegarde différentielle

1. Une sauvegarde complète capture une copie complète de l’ensemble des données (qu’il y ait eu ou non des modifications). Bien qu’il s’agisse de l’option la plus simple, elle prend du temps et n’est donc pas la plus utilisée.
2. La sauvegarde incrémentale ne capture que ce qui a été modifié depuis la dernière sauvegarde.
3. La sauvegarde différentielle ne capture que les données nouvellement ajoutées et modifiées depuis la dernière sauvegarde complète.

NOTE : Cassandra ne supporte pas nativement la sauvegarde différentielle.

Comment fonctionne la sauvegarde incrémentale de Cassandra et quand devez-vous l’activer ?

La sauvegarde incrémentale de Cassandra ne capture que les nouveaux fichiers SSTable au fur et à mesure qu’ils sont écrits sur le disque, ce qui la rend plus efficace en termes de stockage que les sauvegardes complètes. Les sauvegardes incrémentales réduisent la surcharge de stockage en capturant uniquement les nouvelles données depuis la dernière sauvegarde. L’activation de cette fonctionnalité nécessite une modification d’une ligne dans Cassandra.yaml

Une fois activée, il n’y a pas d’autre travail manuel : le reste est géré automatiquement.

Étape 1 : Réception de nouvelles données

Les nouvelles données sont reçues dans la memtable, qui est un tampon d’écriture temporaire en mémoire.

Étape 2 : Les données sont évacuées de la table de mémoire vers le disque

Une fois que la table de mémoire est pleine et qu’elle n’est plus stockée, Cassandra évacue vos données sous la forme d’un fichier SSTable permanent.

Étape 3 : Création de liens matériels

Dès que les tables SST sont créées, Cassandra crée automatiquement des liens durs pour ces données dans les sauvegardes désignées.

Étape : 4 : Les agents de sauvegarde balayent et transfèrent les données

Les outils de sauvegarde tels que Medusa, intégrés à Cassandra, vérifient et transfèrent régulièrement les nouveaux fichiers vers le stockage externe.

Étape 5 : Le cycle se répète

Ce processus se répète continuellement à chaque fois que de nouvelles données entrent dans le cluster.

Les sauvegardes incrémentielles de Cassandra doivent être activées dans les cas suivants :

• Les données changent fréquemment.
• Le volume de données est important.
• Votre RPO nécessite des points de récupération à une fréquence supérieure à 24 heures.
• Les instantanés complets quotidiens occupent trop d’espace de stockage ou prennent trop de temps.

Comment les logs commit et les considérations de récupération ponctuelle affectent-ils la sauvegarde et la restauration de Cassandra ?

L’archivage des Commit Logs est une fonctionnalité importante dans l’architecture de déploiement de Cassandra lorsqu’il s’agit de restaurer les bases de données.

Lors de la sauvegarde de Cassandra, les étapes sont les suivantes :

• L’écriture arrive
• Commit Log (disque) + Memtable (RAM)
• La table de mémoire se remplit → FLUSH
• SSTable (disque)
• Le segment Commit Log est supprimé.

Bien qu’il s’agisse d’une séquence idéale dans des circonstances d’exploitation normales, l’archivage du journal de validation modifie ce schéma. Au lieu de supprimer les segments du journal de validation à la fin, il enregistre des copies dans une mémoire externe, ce qui permet d’accéder aux données perdues. Les instantanés réguliers combinés aux archives du journal de validation rendent possible la récupération à un moment donné (PITR). Sans l’archivage du journal de validation, la récupération est limitée au dernier instantané.

Pour mieux comprendre, prenons l’exemple suivant. Un instantané a été pris à 11 heures, puis une suppression accidentelle s’est produite à 15 h 34. Sans l’archivage des journaux de livraison, vous ne pourriez accéder aux données que jusqu’à 11 heures, ce qui vous coûterait 4 heures et 34 minutes de perte de données. Avec l’archivage des journaux de livraison, toutes vos données peuvent être remplacées, ce qui réduit la perte de données.

Dans de tels scénarios, où le RPO est proche de zéro, l’archivage des logs de validation n’est plus facultatif, mais indispensable.

Quels sont les avantages et les inconvénients des sauvegardes au niveau du cluster par rapport à celles au niveau du nœud ?

Les sauvegardes de Cassandra sont effectuées soit au niveau du nœud, soit au niveau de la grappe, chacun avec des compromis distincts.

Sauvegarde au niveau du nœud : Elle est plus simple que la sauvegarde au niveau du cluster car elle ne nécessite pas d’orchestration particulière et est sauvegardée sur chaque nœud de manière indépendante. Toutefois, la sauvegarde indépendante des nœuds risque d’entraîner une incohérence des données dans l’ensemble de la grappe, en particulier lorsque les grappes comptent plus de 50 nœuds, car la restauration peut s’avérer difficile et entraîner des problèmes liés à l’intégrité des données.

Sauvegarde au niveau de la grappe : Contrairement à la sauvegarde au niveau des nœuds, elle est beaucoup plus complexe et nécessite une orchestration particulière. Elle permet de sauvegarder simultanément tous les nœuds d’une même grappe. Cela garantit que l’intégrité des données n’est pas compromise.

Quels outils et services prennent en charge la sauvegarde et la restauration de Cassandra ?

Cassandra propose une large gamme d’outils et de services pour la sauvegarde et la restauration. Le choix du bon outil est aussi essentiel que les stratégies elles-mêmes, et ce choix dépend fortement de plusieurs facteurs, y compris la taille du cluster et les exigences de récupération. Dans cette section, nous examinerons en détail les principaux types d’outils et de services qui prennent en charge la sauvegarde et la restauration de Cassandra, et nous discuterons des avantages et des inconvénients de chacun d’entre eux.

Quels sont les avantages et les inconvénients des méthodes de sauvegarde natives de Cassandra ?

Quels sont les avantages et les inconvénients des méthodes de sauvegarde natives de Cassandra?

Les méthodes de sauvegarde natives de Cassandra sont les outils qui sont directement intégrés dans Cassandra, et il n’est pas nécessaire d’intégrer un logiciel tiers, comme Medusa et Bacula. Les deux principaux types de méthodes de sauvegarde natives de Cassandra sont les suivants :

1. Instantané Nodetool
2. Sauvegarde incrémentielle intégrée

Ces deux options sont largement utilisées par Cassandra, et la méthode spécifique que vous choisissez dépend fortement de plusieurs facteurs. Les méthodes de sauvegarde natives de Cassandra peuvent être une option idéale pour les petits déploiements en raison de leur aspect pratique. Il n’y a pas de coûts d’installation ou de licence supplémentaires.

Cependant, elles ont aussi leurs limites. Elles sont fortement axées sur le travail manuel, qui comprend le transfert des fichiers vers un serveur externe un par un, et le nettoyage manuel des anciens instantanés. Pour les déploiements importants, ce n’est peut-être pas l’option idéale, car il n’y a pas de surveillance centralisée, pas d’alerte automatique en cas de défaillance, parmi de nombreuses autres fonctionnalités.

Pour :

• facile à comprendre
• idéal pour les petits déploiements
• pas d’installation nécessaire
• gratuit et intégré

Inconvénients

• ne convient pas aux grandes productions
• pas de surveillance ni d’alerte
• pas de gestion de la rétention
• pas de planification

Comment fonctionne la sauvegarde S3 de Cassandra et quand devriez-vous l’utiliser ?

Cassandra backup S3 est l’une des solutions de sauvegarde les plus utilisées car elle offre une large gamme d’avantages :

• Capacité de stockage illimitée
• Redondance géographique
• Contrôle d’accès
• Politiques de cycle de vie automatiques

Pour vous aider à prendre une décision plus éclairée et à déterminer si cette solution est adaptée à vos besoins, nous allons explorer étape par étape son fonctionnement.

Étape 1 : Un instantané est déclenché sur chaque nœud, produisant des fichiers SStable.

Étape 2 : Ensuite, ces fichiers sont compressés, cryptés et téléchargés dans le seau S3 alloué, à l’aide d’un outil de sauvegarde tiers tel que Medusa.

Étape 3 : Une fois dans S3, les fichiers d’instantanés locaux peuvent être supprimés.

La sauvegarde Cassandra S3 doit être utilisée lorsque vous

• Le cluster fonctionne dans un environnement en nuage avec un accès S3.
• Vous avez besoin d’un stockage de sauvegarde géographiquement séparé et rentable.
• Vous souhaitez une gestion automatique de la rétention par le biais de politiques de cycle de vie S3.
• Vous utilisez des outils tiers, tels que Bacula Enterprise, Medusa et OpsCenter, qui s’intègrent nativement à S3.

Comment les méthodes manuelles basées sur les instantanés se comparent-elles aux outils de sauvegarde automatisée de Cassandra ?

En termes de praticité, les outils automatisés de sauvegarde de Cassandra constituent une meilleure option, en particulier pour les entreprises. Ci-dessous, nous allons les examiner et les comparer séparément.

Méthode manuelle basée sur les instantanés

Cette méthode repose fortement sur le travail manuel, y compris l’exécution de vos instantanés nodetool, l’écriture de vos propres scripts pour transférer manuellement les fichiers vers S3 SStable, la mise en place de tâches cron, et le balayage manuel des anciens instantanés qui ne sont plus nécessaires. Les méthodes manuelles ne sont pas très efficaces pour les entreprises et les grandes sociétés, car elles dépendent de l’homme, manquent de surveillance et de coordination et augmentent le risque d’erreur.

Les outils de sauvegarde automatisée de Cassandra sont automatiquement intégrés par des outils tiers, notamment Medusa et Bacula Enterprise. Les caractéristiques typiques comprennent la planification automatisée, la coordination, le transfert, la compression et le cryptage, la gestion de la rétention, la surveillance et l’alerte.

Comment les instantanés au niveau du système de fichiers peuvent-ils être utilisés en toute sécurité pour la sauvegarde de la base de données Cassandra ?

Dans un scénario typique, la sauvegarde de la base de données Cassandra crée et stocke simplement des données dans la base de données Cassandra. Un instantané au niveau du système de fichiers offre une approche alternative, permettant la capture de l’ensemble du disque au niveau de la couche de stockage. Il s’intègre aux outils de sauvegarde Cassandra tiers, tels que les instantanés AWS EBS, pour capturer les fichiers SSTable, les journaux de validation et les fichiers de configuration.

Bien que ces outils soient assez rapides et complets, et qu’ils puissent fonctionner indépendamment au niveau de la couche de stockage, ils peuvent causer de sérieux problèmes s’ils ne sont pas utilisés correctement. Si Cassandra est en cours d’écriture et qu’un instantané du système de fichiers est déclenché alors que les données sont dans la table de mémoire, il peut s’avérer difficile de restaurer clairement les données en question.

REMARQUE IMPORTANTE : Pour réduire le risque d’un tel scénario, exécutez le nodetool flush avant de déclencher l’instantané du système de fichiers. Voici ce que vous pouvez faire pour réduire le risque d’un tel scénario.

Existe-t-il des outils tiers de sauvegarde et de restauration de Cassandra et quelles sont leurs fonctionnalités ?

Il existe une large gamme d’outils de sauvegarde et de restauration Cassandra qui sont des options idéales pour répondre aux besoins des déploiements de production à grande échelle. Les avantages typiques offerts par ces outils incluent, mais ne sont pas limités à

• Efficacité opérationnelle
• Prise en charge du stockage en nuage
• Flexibilité de la sauvegarde
• Une reprise après sinistre plus rapide.

Principaux outils tiers de sauvegarde et de restauration de Cassandra

• Bacula Enterprise

Bacula Enterprise se distingue de toutes les autres solutions de sauvegarde, car il est spécifiquement conçu pour les environnements vastes et complexes. C’est l’outil de sauvegarde et de restauration de niveau entreprise le plus complet disponible pour les déploiements Cassandra.

• OpsCenter

OpsCenter est un outil de sauvegarde Cassandra tiers qui fait partie de la plateforme officielle de gestion de cluster de DataStax. La sauvegarde et la restauration ne sont qu’un élément d’une plateforme plus large qu’il couvre. Cet outil stocke les données de sauvegarde pour s’assurer qu’il n’y a pas de fichiers en double, et prend en charge à la fois le stockage local et Amazon S3 comme destinations de sauvegarde.

OpsCenter s’intègre directement à l’écosystème DataStax Enterprise et gère la complexité supplémentaire de la restauration de ces charges de travail avec les données Cassandra standard. Sa fonction de clonage de cluster permet de restaurer les données de sauvegarde sur un cluster différent, ce qui facilite la migration et les flux de travail de reprise après sinistre.

• Medusa

Medusa est l’un des outils de sauvegarde et de restauration open source les plus répandus, spécialement conçu pour Apache Cassandra. Medusa prend en charge les sauvegardes complètes et incrémentielles, gère automatiquement les rétentions et s’intègre à divers services de stockage en nuage tels qu’Amazon S3, Google Cloud Storage et Azure Blob Storage.

Medusa est conçu pour l’architecture distribuée de Cassandra ; il sait comment coordonner les sauvegardes entre les nœuds, gérer les fichiers SSTable et les chaînes de sauvegarde incrémentielles sans script personnalisé.

Comment la sauvegarde de Cassandra peut-elle être intégrée avec Bacula Enterprise pour la protection de l’entreprise ?

Les outils de sauvegarde Cassandra peuvent traiter la base de données de manière isolée, ce qui est une option idéale pour les petits déploiements. Pour les clusters > 50 nœuds, Cassandra Backup seul n’est pas suffisant car il manque la coordination et la visibilité d’une infrastructure complète. Bacula Enterprise intègre la sauvegarde de Cassandra dans une stratégie de protection des données plus large, à l’échelle de l’organisation.

Contrairement à la sauvegarde instantanée de Cassandra, qui sauvegarde chaque nœud un par un, Bacula permet de coordonner tous les nœuds du cluster en même temps et au même moment. Il gère une sauvegarde complète automatiquement sans aucune intervention manuelle. Cela inclut le déclenchement des snapshots, le transfert des SStables vers le stockage centralisé approprié, la gestion des chaînes de sauvegarde, et plus tard l’archivage des logs de commit pour une récupération au point dans le temps (PITR).

Cela fait de Bacula Enterprise une option pratique pour les organisations qui ont besoin d’un contrôle centralisé sur Cassandra avec d’autres systèmes dans leur infrastructure.

Comment effectuer une sauvegarde sécurisée pour différentes topologies Cassandra ?

Sauvegarder Cassandra en toute sécurité requiert plus que cela : cela requiert une exécution soigneusement planifiée, ce qui est souvent négligé. L’attention portée aux détails opérationnels est aussi importante que les outils et les stratégies eux-mêmes, car c’est ce qui garantit la cohérence des données tout au long du processus.

Comment sauvegarder un cluster Cassandra à plusieurs nœuds sans affecter la disponibilité ?

La sauvegarde d’un cluster Cassandra multi-nœuds sans impact sur la disponibilité nécessite d’échelonner les opérations de sauvegarde entre les nœuds, de les planifier pendant les heures creuses et de limiter l’utilisation des ressources. Les pratiques suivantes répondent directement à chacune de ces exigences.

• Sauvegardez un nœud à la fois

Cassandra réplique les données sur plusieurs nœuds, ce qui peut affecter sa disponibilité. Pour minimiser ce risque, il est conseillé de ne mettre en cluster qu’un seul nœud à la fois, tandis que les autres nœuds peuvent remplir leurs fonctions quotidiennes, comme répondre aux demandes.

• Exécutez les sauvegardes uniquement pendant les heures creuses

Pendant les heures de pointe, en particulier en semaine et pendant les heures de travail, la concurrence pour les ressources est relativement plus forte. La sauvegarde des opérations pendant les week-ends résout ce problème, car la concurrence pour les ressources est faible, voire inexistante.

• Restriction des opérations de sauvegarde

Les opérations de sauvegarde et le trafic en direct sont en concurrence pour les mêmes ressources. Des outils tels que Bacula Enterprise ou Medusa permettent de limiter les opérations de sauvegarde. Cela permet de s’assurer que les opérations de sauvegarde ne consomment pas suffisamment de ressources, et cela aura un impact sur les performances en temps réel.

Comment coordonner la sauvegarde des instantanés Cassandra sur des nœuds distribués ?

La coordination de la sauvegarde des instantanés Cassandra entre les nœuds distribués est simple tant que chaque nœud du cluster distribué est capturé simultanément.

Les scénarios inverses peuvent poser de sérieux problèmes. Dans un cluster distribué, chaque nœud détient une partie différente de l’ensemble des données. Même une différence minime peut donner lieu à des points dans le temps différents, ce qui peut finalement conduire à un point de récupération incohérent qu’il est difficile ou à peine possible de restaurer clairement.

Des outils efficaces ou des scripts d’orchestration doivent être mis en place pour gérer cette situation de manière native. L’intégration de Cassandra avec des outils tiers tels que Bacula Enterprise permet de connecter chaque nœud en même temps, d’attendre que tous les instantanés soient terminés et de transférer ensuite les fichiers vers un stockage externe. Ce processus garantit la coordination harmonieuse de la sauvegarde des instantanés Cassandra sur les nœuds distribués, sans aucun compromis.

Comment vous assurez-vous que les sauvegardes restent cohérentes entre les répliques et les centres de données ?

Les sauvegardes peuvent devenir incohérentes entre les répliques et les centres de données lorsque les nœuds détiennent des versions légèrement différentes des mêmes données au moment de l’instantané. Deux étapes préalables à la sauvegarde et deux pratiques au niveau de la sauvegarde abordent directement ce problème.

• Exécutez nodetool repair

Lorsque vous exécutez nodetool repair, la synchronisation des répliques s’effectue sur l’ensemble du cluster et chaque nœud dispose de la dernière version des mêmes données. Une fois ce processus terminé, il n’y aura pas d’incohérence lorsque l’instantané commencera.

• Désactivez le compactage

Exécutez nodetool disableautocompaction pour empêcher les nœuds d’être à mi-compactage lors de l’exécution de l’instantané, ce qui permet d’éviter les fichiers SSTable partiellement fusionnés dans la sauvegarde.

Une fois ces étapes terminées, vous pouvez passer à votre processus de sauvegarde. Voici ce que vous pouvez faire pour rester cohérent entre les centres de données.

• Utilisez la cohérence LOCAL_QUORUM

Cela vous permettra de n’avoir que des données entièrement confirmées et à jour du centre de données local qui sont capturées pendant les opérations de sauvegarde.

• Sauvegardez à partir d’un seul centre de données

La sauvegarde à partir de plusieurs centres de données peut entraîner des incohérences dues au décalage horaire. La sauvegarde à partir d’un seul centre de données élimine les incohérences puisqu’une sauvegarde complète du centre de données capture déjà l’ensemble des données grâce à la réplication.

Quelles sont les étapes pour restaurer Cassandra à partir des sauvegardes ?

La sauvegarde de Cassandra n’est que la moitié du processus : il est tout aussi important de vous équiper d’informations sur la façon de restaurer Cassandra à partir d’une sauvegarde. Le processus de restauration peut varier en fonction de plusieurs facteurs, y compris la portée et les méthodes utilisées tout au long du processus.

La section suivante couvre tous les scénarios de restauration que vous pouvez rencontrer.

Comment effectuer une sauvegarde et une restauration Cassandra en toute sécurité pour les tables, les espaces-clés ou les clusters complets ?

La sauvegarde et la restauration de Cassandra peuvent se faire à trois niveaux différents, et chacun d’entre eux peut conduire à une perte de données d’une ampleur différente. Examinons-les un par un.

• Restauration au niveau de la table

Il s’agit du niveau de restauration le plus simple. Dans la restauration au niveau de la table, vous n’avez pas besoin de tout récupérer, mais plutôt de récupérer une seule table qui a été accidentellement abandonnée ou supprimée. Le processus est simple : copiez le fichier snapshot donné dans le répertoire correct et exécutez nodetool refresh pour charger les données.

• Restauration au niveau de l’espace-clé

La restauration au niveau de l’espace-clé consiste à restaurer toutes les tables qui se trouvent dans le même espace-clé. Elle suit le même processus que la restauration au niveau des tables, mais s’applique à toutes les tables, et est effectuée lorsque l’ensemble de l’espace-clé est supprimé ou corrompu simultanément.

• Restauration d’un cluster complet

Ce type de restauration couvre tout ce qui se trouve dans le même cluster ; il s’agit donc de la restauration la plus complexe et la plus longue. En général, la restauration complète d’un cluster se produit après des événements catastrophiques majeurs tels qu’un ransomware. Le processus de restauration d’un cluster complet comprend l’arrêt de Cassandra sur chaque nœud, le balayage de tous les répertoires de données, la restauration des fichiers snapshot et le redémarrage ultérieur du cluster.

Comment restaurer à partir d’une sauvegarde d’instantané Cassandra et remettre les nœuds en service ?

La restauration d’un nœud Cassandra est un processus méticuleux qui nécessite le respect d’étapes clairement définies. Ci-dessous, nous allons explorer le cheminement exact des étapes que vous devrez suivre pour restaurer votre nœud Cassandra.

Étape 1 : Arrêter Cassandra

Vous devez arrêter Cassandra car les fichiers de données ne peuvent pas être remplacés lorsque Cassandra est en cours d’exécution.

Étape 2 : Effacer le répertoire de données

Effacez tous les fichiers corrompus du répertoire de données, car ce sont les fichiers qui seront remplacés par la sauvegarde.

Étape 3 : Copier les fichiers d’instantanés

Une fois que le répertoire de données est débarrassé des fichiers supprimés ou corrompus, vous pouvez copier les fichiers d’instantanés et les ramener au chemin d’accès correct du répertoire de données.

Étape 4 : Corriger les autorisations

Dès que les données correctes sont au bon endroit, corrigez les permissions des fichiers et assurez-vous que Cassandra en est propriétaire ; sinon, il ne pourra pas lire la bonne version.

Étape 5 – Redémarrez Cassandra

Le nœud revient en ligne et lit les fichiers SSTable restaurés.

Étape 6 – Exécutez nodetool repair. Cette opération synchronise le nœud restauré avec ses voisins afin qu’il reçoive toutes les écritures effectuées sur d’autres nœuds pendant qu’il était hors ligne.

REMARQUE IMPORTANTE : si vous effectuez une restauration complète d’un cluster, vous devrez répéter cette séquence sur tous vos nœuds.

Comment utiliser les données de la sauvegarde incrémentielle Cassandra lors de la restauration ?

La restauration à partir d’une sauvegarde incrémentielle Cassandra est beaucoup plus complexe que la restauration à partir d’une sauvegarde instantanée. Il y a deux choses importantes à garder à l’esprit lorsque vous lancez une restauration à partir d’une sauvegarde incrémentielle Cassandra.

• La sauvegarde incrémentale doit être appliquée dans l’ordre chronologique.
• Aucun fichier de la chaîne ne peut être sauté.

La restauration d’une sauvegarde incrémentale comprend deux phases principales, qui sont les suivantes :

1. Restauration de la ligne de base de l’instantané complet : Il est IMPOSSIBLE de récupérer votre sauvegarde incrémentielle sans restaurer la sauvegarde complète de l’instantané puisqu’elle vous sert de base.
2. Appliquez vos incréments dans l’ordre chronologique : Chaque incrément est construit sur la ligne de base, du plus ancien au plus récent. Si l’ordre n’est pas respecté, la restauration de la sauvegarde ne sera pas correcte

Prenons un exemple et voyons comment cela fonctionne.

Supposons que vous ayez un instantané complet le mardi, et des incréments chaque jour jusqu’au samedi. Pour restaurer votre sauvegarde incrémentielle du samedi, vous devrez appliquer les instantanés du mardi, puis les incrémentiels du mercredi, du jeudi, du vendredi et du samedi dans le même ordre chronologique.

Comment gérer les décalages de version entre la sauvegarde et la version cible de Cassandra ?

Comment gérer les différences de versions entre les sauvegardes et les versions cibles de Cassandra ?

Les sauvegardes Cassandra peuvent changer de temps en temps. Lorsque la version utilisée pour créer la sauvegarde et celle utilisée pour la restaurer ne correspondent pas, une restauration propre n’a pas lieu. Selon les circonstances, vous pouvez envisager deux solutions.

1. Exécutez la même version de Cassandra que celle utilisée pour la créer, puis mettez-la à niveau vers la version cible. Il s’agit de l’option la plus répandue. Elle minimise la complexité de l’ensemble du processus et élimine les risques liés à la compatibilité des formats.
2. Convertissez les anciens fichiers, puis restaurez-les dans une nouvelle version. Si la première solution ne fonctionne pas, vous pouvez convertir les fichiers de l’ancienne version à l’aide de l’outil sstableupgrade , puis les restaurer ultérieurement dans la nouvelle version.

Ces deux options sont gérables. L’important n’est pas de choisir l’une ou l’autre, mais de s’assurer que les différences de version sont gérées correctement et que les données sont restaurées dans les règles de l’art.

Comment automatiser et planifier les sauvegardes Cassandra de manière fiable ?

Les processus de sauvegarde manuelle, qui sont idéaux pour les petits déploiements, ont toujours leurs inconvénients. Ils sont sujets aux erreurs humaines, aux oublis de programmation et aux fonctionnalités qui ne sont pas détectées avant qu’une catastrophe grave ne se produise. L’automatisation et la planification sont spécifiquement conçues pour résoudre ce problème : elles permettent de s’assurer que les erreurs sont traitées à temps avant qu’elles ne deviennent graves et d’identifier les défaillances à un stade précoce afin de prendre les précautions nécessaires. Cette section couvre de manière exhaustive tout ce que vous devez savoir pour automatiser et planifier de manière fiable vos sauvegardes Cassandra.

Quels modèles de planification minimisent la charge et respectent votre RTO/RPO ?

Lorsque vous choisissez la bonne planification des sauvegardes, vous devez garder à l’esprit deux exigences

• Répondre aux exigences RPO/RTO
• Minimiser la charge de votre cluster

Il existe deux principaux modèles de planification des sauvegardes que vous pouvez envisager

• Instantanés complets quotidiens + sauvegardes incrémentielles horaires

Exécutez un instantané complet une fois par jour et des sauvegardes incrémentielles toutes les heures pour capturer les changements survenant au cours de la journée. Cette combinaison vous aidera à satisfaire votre RPO d’une heure sans avoir à exécuter des instantanés complets de façon répétée.

REMARQUE IMPORTANTE : programmez vos instantanés complets pendant les heures creuses afin de minimiser la concurrence pour le trafic en direct.

• Instantanés complets hebdomadaires + incrémentations quotidiennes

Si, pour la plupart des déploiements, les instantanés complets quotidiens satisfont à la RPO sur 24 heures, ce n’est pas le cas pour les clusters de plus de 50 nœuds, car ils prennent beaucoup de temps. Dans ce cas, la planification d’instantanés complets hebdomadaires combinés à des incrémentations quotidiennes peut être une meilleure option, qui vous permettra de réduire les frais généraux et de maintenir un RPO de 24 heures.

Ci-dessous, nous allons examiner les exigences les plus courantes en matière de RPO et les modèles recommandés pour ces exigences.

Comment rendre les scripts, les outils d’orchestration ou les tâches cron résilients et idempotents ?

Les scripts de sauvegarde ne sont pas performants à bien des égards, et il est essentiel d’y remédier à temps. Le développement de la résilience et de l’idempotence est la solution ultime, garantissant que chaque processus de sauvegarde est traité avec soin.

Voici les étapes concrètes à suivre pour rendre votre automatisation de sauvegarde résiliente et idempotente.

Étape 1 : Effectuez un contrôle préalable avant de lancer la sauvegarde

Avant même d’essayer de créer un nouvel instantané, vérifiez et assurez-vous qu’aucun autre instantané n’existe pour la même fenêtre.

Étape 2 : Utilisez des fichiers de verrouillage

Une fois que vous avez lancé votre automatisation de la sauvegarde, créez un fichier de verrouillage et supprimez-le plus tard. Cette étape vous permettra de vous assurer qu’aucun fichier de sauvegarde n’est exécuté simultanément.

Étape 3 : Vérifiez chaque étape

Vérifiez chaque détail et le code de sortie de chaque commande, y compris les instantanés, la compression et les téléchargements. Cela vous permettra d’identifier les défaillances tout au long du processus et de garder la situation sous contrôle.

Étape 4 : Consignez tout

Consignez toutes les activités, y compris les réussites, les échecs et les avertissements, dans un fichier journal, ce qui vous aidera à vous assurer que les scripts sont résistants.

Étape 5 : Nettoyer en cas d’échec

Balayez automatiquement les instantanés partiels ou les téléchargements incomplets, au cas où votre script de sauvegarde échouerait en cours de route.

Étape 6 : ajouter une logique de réessai

Réessayez automatiquement les défaillances transitoires jusqu’à une limite définie.

Étape 7 : Utilisez les outils d’orchestration

Au lieu d’utiliser des tâches cron, utilisez des outils d’orchestration comme Bacula Enterprise, qui vous permettront de gérer l’ensemble du cycle de vie de la sauvegarde.

Comment surveiller les tâches de sauvegarde et alerter en cas d’échec ?

Tout au long de votre processus de sauvegarde Cassandra, des défaillances peuvent survenir à tout moment. La surveillance des tâches de sauvegarde et l’alerte en cas d’échec sont deux éléments importants qui doivent être pris en compte en cas d’échec.

Lorsque vous lancez votre surveillance des sauvegardes, gardez à l’esprit les questions suivantes pour la rendre efficace.

• Votre sauvegarde a-t-elle été exécutée ?
• S’est-elle déroulée correctement ?
• Combien de temps a-t-elle duré ?
• Quelle était la taille de la sortie ?
• Est-il possible de restaurer la sauvegarde ?

Pour surveiller vos sauvegardes, procédez comme suit :

1. Vérifiez les journaux Cassandra

Examinez le fichier system.log après chaque travail de sauvegarde pour y trouver des erreurs ou des avertissements qui montrent que quelque chose ne s’est pas terminé proprement.

2. Utilisez nodetool pour vérifier vos instantanés

Exécutez nodetool listsnapshots pour vous assurer que votre instantané existe réellement.

3. Suivez les résultats des travaux

Veillez à enregistrer le code de sortie, la taille du fichier et la durée de votre script de sauvegarde afin de pouvoir le comparer ultérieurement avec les versions précédentes.

Lors de l’exécution de votre sauvegarde Cassandra, l’alerte est aussi importante que la surveillance, ce qui vous aide à prendre les précautions nécessaires à temps. En fonction de la gravité du problème, les alertes de défaillance doivent être acheminées vers le canal désigné.

• PagerDuty pour une réponse immédiate sur appel
• Slack pour la visibilité de l’équipe
• Le courrier électronique pour les notifications non urgentes.

Vous pouvez également utiliser des outils tiers tels que Bacula Enterprise, qui offre une sauvegarde et une surveillance unifiées, ainsi que des alertes, afin de garantir que tout est sous contrôle.

Comment la sécurité et la conformité affectent-elles les pratiques de sauvegarde de Cassandra ?

Utiliser la bonne stratégie de sauvegarde Cassandra est important, mais ce n’est que la moitié de l’équation. La sécurité et la conformité constituent la seconde moitié de l’équation. La sécurité garantit que les fichiers sont protégés de tout accès autorisé ou de toute restriction. La conformité, quant à elle, garantit que les pratiques de sauvegarde répondent à toutes les exigences réglementaires.

Comment les sauvegardes Cassandra doivent-elles être chiffrées au repos et en transit ?

Les sauvegardes Cassandra doivent être chiffrées à la fois au repos et en transit. Il s’agit de deux exigences de protection distinctes qui s’attaquent à des points de vulnérabilité différents.

Le chiffrement au repos est le processus de stockage de vos fichiers de sauvegarde sous une forme chiffrée sur le disque ou le stockage de sauvegarde. Il garantit que les fichiers sont protégés et ne sont pas lus, même si le stockage physique est volé.

Le chiffrement en transit, quant à lui, fait référence au processus de transfert de votre sauvegarde du nœud Cassandra vers le stockage de sauvegarde. Ce processus empêche l’interception pendant le transfert, ce qui garantit la protection des données importantes.

Voici ce que les sociétés et les entreprises devraient faire pour sécuriser correctement les sauvegardes Cassandra.

• Utilisez des normes de chiffrement solides telles que AES-256 pour le chiffrement au repos.
• Des protocoles sécurisés tels que HTTPS pour le chiffrement en transit.
• Stockez et gérez les clés de chiffrement à l’aide d’un service de gestion des clés (KMS).
• Restreindre l’accès aux fichiers de sauvegarde.

Comment contrôler l’accès aux sauvegardes et appliquer le principe du moindre privilège ?

Contrôler l’accès à tout pour tout le monde est l’une des pratiques les moins utilisées dans les sauvegardes Cassandra. Cette pratique nécessite d’appliquer le moindre privilège, ce qui signifie donner à chaque système et à chaque personne l’autorisation minimale correspondant à son rôle. Les comptes de service ou les rôles typiques sont les suivants

1. Les agents de sauvegarde qui ont un accès en écriture seule au stockage des sauvegardes, mais qui ne peuvent pas lire ou supprimer les sauvegardes existantes.
2. Les agents de restauration ont un accès en lecture seule et ne peuvent ni supprimer ni modifier quoi que ce soit.
3. L‘administrateur des sauvegardes qui a un accès complet à tout.

De nombreuses entreprises mettent en œuvre des politiques de gestion des identités et des accès (IAM) et des seaux S3 pour contrôler l’accès aux sauvegardes et appliquer le principe du moindre privilège. Ces politiques comprennent, entre autres, le refus des opérations pour les comptes non administrateurs, la restriction de l’accès à une plage d’adresses IP inconnue, l’obligation de chiffrer tous les téléchargements et l’audit des enregistrements de journalisation.

La séparation de ces tâches entre les systèmes et les personnes, et l’identification de qui peut faire quoi et quand, garantissent que tout est sous contrôle et que rien n’est compromis.

Quel est l’impact des politiques de rétention et des exigences de suppression des données sur la stratégie de sauvegarde de Cassandra ?

Les politiques de conservation et les exigences de suppression des données sont deux défis distincts qui ont un impact sur la stratégie de sauvegarde de Cassandra. Les politiques de rétention sont celles qui déterminent la durée de conservation des sauvegardes Cassandra avant leur suppression si elles ne sont plus utilisées.

• Sauvegardes quotidiennes – conservées pendant 30 jours
• Sauvegardes hebdomadaires – conservées pendant 3 mois
• Sauvegardes mensuelles – conservées pendant un an
• Sauvegardes annuelles – conservées pendant 7 ans

Pour résoudre ce problème, les entreprises mettent en œuvre une approche de rétention échelonnée, qui consiste à appliquer simultanément différentes périodes de rétention à différents types de sauvegardes. Les entreprises peuvent ainsi équilibrer leurs coûts de stockage et leur conformité aux réglementations sans avoir à tout conserver pour toujours.

Les exigences en matière de suppression des données constituent un autre défi, car il n’est pas possible de supprimer les données d’utilisateurs spécifiques à partir de fichiers de sauvegarde binaires. Pour résoudre ce problème, les entreprises maintiennent une période de conservation suffisamment courte pour que les données supprimées expirent naturellement dans un délai documenté et défendable.

Comment les sauvegardes immuables et la protection contre les ransomwares s’appliquent-elles à la sauvegarde et à la restauration de Cassandra ?

Les ransomwares constituent l’échec le plus important et le plus catastrophique qui survient au cours du processus de sauvegarde de Cassandra. Dans le cas d’une telle attaque, les ransomwares suivent un schéma prévisible, qui est le suivant :

• Cryptage des données en direct
• Ciblage du fichier de sauvegarde pour empêcher la récupération

Les sauvegardes immuables s’attaquent directement à ce problème. Elles garantissent que les fichiers de sauvegarde ne peuvent pas être modifiés après avoir été écrits, et même un compte administratif totalement compromis ne peut pas supprimer ou chiffrer une sauvegarde immuable.

Le verrouillage des objets S3 met en œuvre l’immuabilité au niveau du stockage AWS :

• Les fichiers écrits dans un godet verrouillé ne peuvent être ni modifiés ni supprimés pendant la période de conservation définie.
• Le mode conformité supprime toute possibilité d’annulation
• Le mode de gouvernance permet aux administrateurs autorisés de passer outre dans des conditions spécifiques.

Comment les sauvegardes en ligne ou hors ligne peuvent-elles réduire l’impact d’une violation ?

Dans la plupart des scénarios, les attaques de ransomware ne se contentent pas de chiffrer les données en direct : elles cherchent constamment à détruire les sauvegardes en ligne et à minimiser les chances de récupération. Le meilleur mécanisme de défense que les attaques de ransomware ne peuvent pas surmonter est celui des sauvegardes aériennes et hors ligne.

Les sauvegardes « air-gapped » sont complètement déconnectées physiquement de tous les réseaux. Cela signifie que les sauvegardes aériennes ne peuvent pas être atteintes, supprimées ou cryptées puisqu’il n’y a pas de connexion internet ou d’accès à distance.

Les sauvegardes hors ligne sont plus vastes et ne sont pas activement connectées aux systèmes actifs au moment d’une violation. Cependant, elles peuvent toujours être accessibles par d’autres moyens.

Quelles sont les meilleures pratiques pour les sauvegardes Cassandra de production ?

Une stratégie de sauvegarde de Cassandra en production semble être un chemin sans fin, qui nécessite des politiques cohérentes, des mesures continues et une documentation claire, pour rester fiable au fil du temps. La section suivante couvre les meilleures pratiques pour les sauvegardes Cassandra en production, en définissant la base de référence et en discutant de tout ce que vous devez savoir.

Quelles sont les règles minimales à mettre en place pour tout déploiement en production ?

Le strict minimum que tout déploiement de Cassandra en production devrait avoir, indépendamment de la taille de l’entreprise, du budget ou de la complexité du cluster, est le suivant :

1. Des instantanés quotidiens automatisés. L’automatisation élimine la dépendance humaine de l’opération de protection des données la plus critique.
2. Stockage hors site. Chaque instantané doit être immédiatement transféré vers un stockage externe, complètement séparé du cluster.
3. Politique de conservation définie. Vous devez documenter la durée de conservation de chaque type de sauvegarde et l’appliquer automatiquement.
4. Surveillance et alerte. La surveillance et l’alerte automatisées sont indispensables pour vous permettre de prendre les précautions nécessaires à temps et d’éviter les défaillances majeures.
5. Processus de restauration testé. Les sauvegardes doivent être testées régulièrement pour garantir la sécurité de vos données.
6. Cryptage. Tous vos fichiers de sauvegarde doivent être cryptés au repos et en transit, sans exception.
7. Contrôle d’accès. Le principe du moindre privilège doit être appliqué à l’ensemble de votre stockage de sauvegarde.
8. Documentation de la version. Chaque sauvegarde doit être étiquetée avec la version de Cassandra sur laquelle elle a été créée.
9. Manuel d’exécution documenté. Vous devez disposer d’un manuel d’exécution documenté comprenant des procédures de restauration détaillées qui peuvent être utilisées en cas de catastrophe majeure.
10. Sauvegardes incrémentielles. Vous devez utiliser des sauvegardes incrémentielles combinées à des sauvegardes d’instantanés complets dont le RPO est inférieur à 24 heures.

Comment documenter les procédures de sauvegarde et de restauration de Cassandra pour les équipes de garde ?

Pour documenter les procédures de sauvegarde et de restauration de Cassandra pour l’équipe d’astreinte, les entreprises disposent d’un runbook, qui est un document servant de guide étape par étape. Un runbook idéal doit être rédigé de manière à ce que même un spécialiste junior qui n’a jamais exécuté de sauvegarde Cassandra puisse le lire et tout exécuter avec succès. Voici ce qu’un tel runbook devrait couvrir :

• Récupération d’une table unique
• Restauration de l’espace-clé
• Restauration d’un cluster complet
• Délais prévus pour chaque étape nécessaire
• Les coordonnées des experts Cassandra et des outils de sauvegarde.

REMARQUE IMPORTANTE : Des conseils doivent être donnés aux personnes qui ne sont pas familiarisées avec ces procédures afin qu’elles puissent comprendre laquelle s’applique à la situation donnée.

Ces runbooks ont une fonction extrêmement importante pour les sociétés et les entreprises. Ils doivent être mis à jour après chaque mise à niveau, chaque restauration ou chaque changement d’outil de sauvegarde.

Quels sont les indicateurs et les accords de niveau de service à suivre pour la santé des sauvegardes ?

Le suivi de la santé des sauvegardes nécessite la surveillance de paramètres spécifiques et l’évaluation de leur performance et de leur dégradation.

Les mesures clés à prendre en compte pour la santé de vos sauvegardes sont les suivantes

1. Taux de réussite. Cette mesure représente le pourcentage de travaux réussis dans la période définie.
2. Durée. Cette mesure définit la durée de chaque tâche. Par exemple, vous pouvez décider qu’un instantané complet aura lieu dans une semaine.
3. Taille. Examinez les chutes ou les pics inattendus qui signalent des anomalies.
4. Temps de restauration. Mesuré par des tests de restauration réguliers, ce paramètre confirme que le RTO réel est réalisable dans la pratique.
5. Âge de la sauvegarde. Identifier l’âge de la dernière sauvegarde réussie.
6. Temps de réponse aux alertes: rapidité avec laquelle les défaillances sont détectées et traitées. SLA : toutes les alertes de sauvegarde sont signalées dans les 15 minutes.

Pour surveiller ces mesures et identifier la santé de vos sauvegardes, vous pouvez utiliser des outils tiers tels que Bacula Enterprise, Medusa ou OpsCenter, qui offrent une plateforme unifiée permettant de faire tout cela en même temps.

A retenir

• Définissez vos RPO et RTO avant de concevoir votre stratégie, car sans eux, votre stratégie de sauvegarde n’a pas d’objectif mesurable.
• Stockez toujours vos instantanés hors site une fois qu’ils sont créés.
• Exécutez des sauvegardes incrémentielles et procédez à l’archivage des journaux, car cela réduira les frais généraux de stockage.
• L’automatisation, la surveillance et les alertes sont indispensables car elles réduisent la probabilité d’erreurs et de défaillances.
• Utilisez toujours le chiffrement, le contrôle d’accès, le stockage immuable et les sauvegardes en mode « air-gapped ». Le chiffrement et le contrôle d’accès empêchent les accès non autorisés. Les sauvegardes immuables et en réseau permettent de s’assurer que les ransomwares ne peuvent pas détruire votre chemin de récupération.
• Testez vos sauvegardes comme des exercices de restauration réguliers qui confirment votre plan de travail de récupération.

Questions fréquemment posées

Les sauvegardes Cassandra peuvent-elles rester cohérentes dans des architectures d’applications distribuées ?

Oui, les sauvegardes Cassandra peuvent rester cohérentes à travers les canaux d’applications distribuées. Cependant, cela est mis en œuvre par le biais d’instantanés coordonnés et de l’archivage des journaux de livraison qui produisent des sauvegardes fiables et restaurables.

Comment sauvegarder en toute sécurité des déploiements Cassandra multi-tenant ?

La sauvegarde en toute sécurité des déploiements Cassandra multi-locataires nécessite des instantanés au niveau de l’espace-clé pour isoler les données des locataires. Veillez à appliquer des contrôles d’accès et un chiffrement stricts pendant le stockage des sauvegardes afin d’éviter l’exposition des données entre locataires.

En quoi les déploiements Cassandra conteneurisés et basés sur Kubernetes modifient-ils la stratégie de sauvegarde ?

Les déploiements Cassandra conteneurisés nécessitent des instantanés de volume persistants au lieu de s’appuyer uniquement sur nodetool snapshot. Dans Kubernetes, vous pouvez utiliser des outils tels que Medusa pour gérer l’orchestration des sauvegardes à travers les pods.