Comment sauvegarder Kubernetes?

Bien que l’hypothèse selon laquelle Kubernetes fût auparavant utilisée principalement par les équipes DevOps ait pu être quelque peu correcte, de nombreuses entreprises déploient désormais activement des conteneurs dans des environnements opérationnels. Elles choisissent également de plus en plus souvent des approches centrées sur les conteneurs plutôt que sur les VM traditionnelles. Cela est dû aux divers avantages de flexibilité, de performance et de coût que les conteneurs peuvent souvent offrir. Cependant, à mesure que les conteneurs se déplacent vers le côté opérationnel de l’environnement informatique, les aspects de sécurité des conteneurs dans un environnement critique, notamment leurs données persistantes dans le contexte des processus de sauvegarde et de restauration, suscitent de plus en plus d’inquiétudes.

À l’origine, l’écrasante majorité des applications conteneurisées étaient apatrides, ce qui leur permettait de bénéficier d’un processus de déploiement beaucoup plus facile sur un cloud public. Mais cela a changé avec le temps, et beaucoup plus d’applications étatiques ont été déployées dans des conteneurs qu’auparavant. Ce changement est la raison pour laquelle la sauvegarde et la récupération dans Kubernetes est maintenant un sujet important pour beaucoup d’organisations.

Caractéristiques importantes d’une solution de sauvegarde Kubernetes fonctionelle

La nature dynamique des environnements Kubernetes fait qu’il est plus difficile pour les systèmes et techniques de sauvegarde plus traditionnels de bien fonctionner dans le contexte des nœuds et applications Kubernetes. Le RPO et le RTO peuvent devoir être beaucoup plus stricts, car les applications doivent être constamment opérationnelles, ou particulièrement critiques, et ainsi de suite.

Cela nous amène à discerner trois fonctionnalités différentes qui sont hautement recommandées pour chaque entreprise en général, et une nécessité évidente lorsqu’il s’agit de sauvegardes Kubernetes de meilleure pratique :

• Récupération après sinistre
• Sauvegarde et restauration
• Haute disponibilité locale

Dans un environnement Kubernetes, le contexte de ces trois aspects de la sauvegarde peut légèrement changer par rapport à leur définition normale :

La haute disponibilité locale en tant que fonctionnalité concerne davantage la prévention/protection des pannes à l’intérieur d’un centre de données spécifique ou à travers des zones de disponibilité (si nous parlons de cloud, par exemple). Une défaillance « locale » est celle qui se produit dans l’infrastructure/le nœud/l’application utilisée pour exécuter l’application. Dans un scénario parfait, votre solution de sauvegarde Kubernetes devrait être capable de réagir à cette défaillance en maintenant l’application en fonctionnement, ce qui signifie essentiellement qu’il n’y a pas de temps d’arrêt pour l’utilisateur final. L’un des exemples les plus courants de défaillance locale est le blocage d’un volume de cloud après la défaillance d’un nœud.

Dans cette perspective, la haute disponibilité locale en tant que fonctionnalité peut être considérée comme une base du système global de protection des données. D’une part, pour effectuer une telle tâche, votre solution doit offrir une sorte de système de réplication des données au niveau local et elle doit également se trouver sur le chemin des données en premier lieu. Il est important de mentionner que la fourniture d’une disponibilité locale par le biais d’une restauration de sauvegarde est toujours considérée comme une sauvegarde et une restauration et non comme une haute disponibilité locale, en raison du temps de récupération global.

La sauvegarde et la restauration sont une autre partie importante d’un système de sauvegarde Kubernetes. Dans la plupart des cas d’utilisation, il sauvegarde l’ensemble de l’application hors site à partir d’un cluster Kubernetes local. Le contexte de Kubernetes soulève également une autre considération importante – si le logiciel de sauvegarde « comprend » ce qui est inclus dans une application Kubernetes, comme :

• Configuration App
• Ressources Kubernetes
• Données

Une sauvegarde Kubernetes correcte doit enregistrer toutes les parties ci-dessus comme une seule unité pour qu’elle soit utile dans le système Kubernetes après sa restauration. Le fait de cibler des VM, des serveurs ou des disques spécifiques ne signifie pas qu’un logiciel « comprend » les applications Kubernetes. Idéalement, un logiciel Kubernetes devrait être capable de sauvegarder des applications spécifiques, des groupes spécifiques d’applications, ainsi que l’ensemble de l’espace de noms Kubernetes. Cela ne veut pas dire qu’il est complètement différent du processus de sauvegarde habituel – les sauvegardes Kubernetes peuvent également bénéficier grandement de certaines des fonctionnalités régulières d’une sauvegarde habituelle, notamment la rétention, la planification, le cryptage, la hiérarchisation, etc.

La capacité de récupération après sinistre (DR) est probablement essentielle pour toute organisation utilisant Kubernetes dans une situation critique, tout comme pour l’utilisation de toute autre technologie. Tout d’abord, la restauration après sinistre doit « comprendre » le contexte des sauvegardes Kubernetes, tout comme la sauvegarde et la restauration. Elle peut également avoir différents niveaux de RTO et de RPO et différents niveaux de protection en fonction de ces niveaux. Par exemple, il peut y avoir une exigence stricte de Zero RPO qui implique un temps d’arrêt strictement nul, ou il peut y avoir un RPO de 15 minutes, avec des exigences un peu moins strictes. Il n’est pas rare non plus que des applications différentes aient des RTO et RPO complètement différents au sein d’une même base de données.

Une autre distinction importante d’un système de restauration après sinistre spécifique à Kubernetes est qu’il doit également être capable de travailler avec les métadonnées dans une certaine mesure (étiquettes, répliques d’applications, etc.). L’incapacité à fournir cette fonctionnalité pourrait facilement conduire à une récupération disjointe en général, ainsi qu’à une perte de données générale ou à un temps d’arrêt supplémentaire.

Types de données qui doivent être sauvegardées dans Kubernetes

Comme tout système complexe, Kubernetes et Docker possèdent un certain nombre de types de données spécifiques dont ils auront besoin pour reconstruire correctement l’ensemble de la base de données en cas de sinistre. Pour faciliter les choses, il est possible de diviser tous les types de données et de fichiers de configuration en deux catégories différentes : la configuration et les données persistantes.

La configuration comprend :

• La base de données Kubernetes etcd
• Fichiers Docker
• Images des fichiers Docker

Les données persistantes (modifiées ou créées par les conteneurs eux-mêmes) sont :

• Bases de données
• Volumes persistants

Base de données Kubernetes etcd

C’est une partie intégrante du système contenant les informations sur les états du cluster. Elle peut être sauvegardée manuellement ou automatiquement, en fonction de votre solution de sauvegarde. La méthode manuelle est via la commande etcdctl snapshot save db, qui crée un fichier unique avec le nom snapshot.db.

Une autre méthode pour faire la même chose consiste à déclencher cette même commande juste avant de créer une sauvegarde du répertoire dans lequel ce fichier apparaîtrait. C’est l’une des façons d’intégrer cette sauvegarde spécifique à l’ensemble de l’environnement.

Fichiers Docker

Puisque les conteneurs Docker eux-mêmes sont exécutés à partir d’images, ces images doivent être basées sur quelque chose – et celles-ci sont, à leur tour, créées à partir de fichiers Docker. Pour une configuration Docker correcte, il est recommandé d’utiliser une sorte de dépôt comme système de contrôle de version pour l’ensemble de vos fichiers Docker (GitHub, par exemple). Pour faciliter le retrait des versions antérieures, tous les fichiers Docker doivent être stockés dans un dépôt spécifique qui permet aux utilisateurs de retirer les anciennes versions de ces fichiers si nécessaire.

Un dépôt supplémentaire est également recommandé pour les fichiers YAML associés à tous les déploiements Kubernetes, qui existent sous forme de fichiers texte. Il est également indispensable de sauvegarder ces dépôts, en utilisant soit des outils tiers, soit les capacités intégrées de quelque chose comme GitHub.

Il est important de mentionner que vous pouvez toujours aspirer les fichiers Docker à sauvegarder, même si vous exécutez des conteneurs à partir d’images sans leurs fichiers Docker. Il existe une commande spécifique, docker image history, qui vous permet de créer un fichier Docker à partir de votre image actuelle. Il existe également plusieurs outils tiers qui peuvent faire la même chose.

Images à partir de fichiers Docker

Les images Docker elles-mêmes doivent également être sauvegardées dans un référentiel. Le référentiel privé et le référentiel public peuvent tous deux être utilisés dans ce but précis. Divers fournisseurs de cloud computing ont tendance à fournir des référentiels privés à leurs clients. S’il vous manque l’image à partir de laquelle votre conteneur fonctionne, une commande spécifique qui est docker commit devrait pouvoir vous créer cette image.

Bases de données

L’intégrité est également cruciale lorsqu’il s’agit de bases de données que les conteneurs utilisent pour stocker leurs données. Dans certains cas, il est possible d’arrêter le conteneur en question avant de créer une sauvegarde des données, mais là encore, le temps d’arrêt nécessaire risque d’entraîner de nombreux problèmes pour l’entreprise en question.

Une autre méthode pour effectuer des sauvegardes de bases de données à l’intérieur de conteneurs consiste à se connecter au moteur de base de données lui-même. Il convient d’utiliser au préalable un mount bind pour attacher un volume qui pourrait être sauvegardé en premier lieu, puis vous pouvez utiliser la commande mysqldump (ou similaire) pour créer une sauvegarde. Le fichier de sauvegarde en question doit également être sauvegardé par la suite à l’aide de votre système de sauvegarde.

Volumes persistants

Il est juste de dire qu’il existe plusieurs méthodes différentes pour que les conteneurs puissent accéder à une forme de stockage persistant. S’il s’agit de volumes Docker traditionnels, ils résident dans un répertoire situé sous la configuration Docker. Les montages liés, quant à eux, peuvent être n’importe quel répertoire monté à l’intérieur d’un conteneur. Bien que les volumes traditionnels soient préférés par la communauté Docker, les deux sont relativement identiques lorsqu’il s’agit de sauvegarder des données. Une troisième façon d’effectuer la même opération consiste à monter un répertoire NFS ou un objet unique comme volume à l’intérieur d’un conteneur.

Ces trois méthodes présentent le même problème lorsqu’il s’agit de sauvegarder des données : la cohérence d’une sauvegarde n’est pas complète si les données contenues dans un conteneur changent au milieu de la sauvegarde. Bien sûr, il est toujours possible d’assurer la cohérence en arrêtant le volume avant de sauvegarder, mais dans la plupart des cas, il est hors de question d’arrêter ces systèmes pour assurer la continuité des activités.

Il existe des moyens de sauvegarder les données dans les conteneurs qui sont spécifiques à une méthode. Par exemple, les volumes docker traditionnels peuvent être montés dans un autre conteneur qui ne modifiera aucune des données jusqu’à la fin du processus de sauvegarde. Ou si vous utilisez un volume monté par liaison, il est possible de créer une image tar d’un volume entier, puis de sauvegarder cette image.

Malheureusement, toutes ces options sont très difficiles à mettre en œuvre avec Kubernetes. C’est précisément pour cette raison qu’il est toujours recommandé de stocker les informations d’état dans la base de données et en dehors du système de fichiers du conteneur.

Ceci étant dit, si vous utilisez un répertoire monté par bind ou un système de fichiers monté par NFS comme stockage persistant, il est également possible de sauvegarder ces données en utilisant les méthodes habituelles, comme un snapshot. Cela devrait vous permettre d’obtenir une cohérence bien plus grande que la sauvegarde traditionnelle au niveau des fichiers du même volume.

Solutions de sauvegarde de Kubernetes

Dans le contexte de ces trois facteurs/caractéristiques importants, examinons quelques autres exemples de solutions de sauvegarde et de récupération de Kubernetes.  Les exemples que nous utilisons ici sont Kasten, Portworx, Cohesity, OpenEBS et Rancher Longhorn.

Kasten K10 (récemment acquis par Veeam) est une solution de sauvegarde et de restauration qui est également fière de ses systèmes de mobilité et de restauration après sinistre. Le processus de sauvegarde avec Kasten est simplifié grâce à sa capacité à découvrir automatiquement les applications, ainsi qu’à de nombreuses autres fonctionnalités, comme le cryptage des données, le contrôle d’accès basé sur les rôles et une interface conviviale. En même temps, il peut fonctionner avec de nombreux services de données différents, tels que MySQL, PostgreSQL, MongoDB, Cassandra, AWS, etc.

La haute disponibilité locale n’est pas disponible avec lui, car Kasten ne prend pas directement en charge la réplication au sein d’un seul cluster et s’appuie plutôt sur les systèmes de stockage de données sous-jacents.  La restauration après sinistre n’est également que partiellement « présente » puisque Kasten ne peut pas atteindre des cas de RPO zéro en raison de l’absence d’un composant de cheminement des données. Il convient également de noter que les sauvegardes de Kasten sont uniquement asynchrones, ce qui représente généralement un temps d’arrêt supplémentaire entre les opérations.

Portworx PX-Backup est une société de gestion de données qui développe une plateforme de stockage dans le cloud pour gérer et accéder à la base de données des projets Kubernetes. C’est un autre exemple de solution de gestion des données et, malgré ses limites en tant que telle, l’un des principaux avantages de l’utilisation de Portworx est la haute disponibilité des données.

Les opérations de sauvegarde et de restauration, la compréhension des applications Kubernetes, la haute disponibilité locale, la récupération après sinistre, entre autres fonctionnalités – tout cela fait de Portworx une bonne solution pour la sauvegarde de Kubernetes – si vous en cherchez une qui se spécialise dans les tâches liées à Kubernetes.

Une autre partie importante de PX-Backup est son évolutivité, permettant des sauvegardes à la demande / des sauvegardes planifiées de centaines d’applications à la fois. La solution prend également en charge les configurations multi-bases de données et peut restaurer les applications directement sur les services de cloud computing, tels qu’Amazon, Google, Microsoft, etc.

Cohesity est un concurrent relativement populaire dans le domaine de la sauvegarde et de la restauration générales, mais ses capacités liées à Kubernetes ont encore une certaine marge de progression. Tout d’abord, Kubernetes est un ajout relativement nouveau pour eux, et ils ont ajouté la « compréhension » pour les applications Kubernetes dès le départ, mais dans le même temps, il ne fonctionne que pour toutes les applications dans le même espace de noms, et vous ne pouvez pas protéger des applications spécifiques dans ce seul espace de noms.

D’autre part, il existe également des capacités de récupération rapide, des sauvegardes incrémentielles de l’app-tier basées sur des politiques, la consolidation de l’état des données et de nombreuses autres capacités.

OpenEBS est un autre exemple qui a réussi à obtenir certains résultats avec une seule des trois fonctionnalités de notre liste, et dans ce cas, il s’agit de la haute disponibilité locale.

Dans le même temps, OpenEBS peut également s’intégrer à Velero, créant ainsi une solution Kubernetes combinée qui excelle dans la migration de données Kubernetes. OpenEBS seul ne peut que sauvegarder des applications individuelles (un opposé direct de ce que fait Cohesity). Il existe également des fonctionnalités telles que le stockage multi-cloud, sa nature open-source et une liste gigantesque de plateformes Kubernetes prises en charge, d’AWS et Digital Ocean à Minikube, Packet, Vagrant, GCP, etc.

Cependant, cela peut ne pas couvrir les besoins d’un utilisateur, car certains utilisateurs peuvent avoir besoin de ces sauvegardes d’espaces de noms dans des cas d’utilisation spécifiques.

Rancher Longhorn est le dernier de nos exemples, et celui-là est probablement le moins connu de tous. Sa communauté est relativement restreinte pour une solution open-source, et il ne permet pas d’effectuer des sauvegardes complètes de Kubernetes avec des métadonnées et des ressources pour permettre une récupération adaptée aux applications. Cependant, il y a une fonctionnalité unique qui se démarque, et elle s’appelle DR Volume. DR Volume peut être configuré à la fois comme source et comme destination, rendant le volume actif dans un nouveau cluster basé sur les dernières données sauvegardées.

Les capacités de Rancher à travailler avec de nombreux types de plateformes de conteneurs et à permettre différentes méthodes de sauvegarde sont ce qui le différencie des autres, et il est déjà possible de prendre en charge le moteur Kubernetes, les déploiements Docker et les distributions K3. Les conteneurs Docker, par exemple, doivent créer un tarball qui pourrait servir de sauvegarde pour Rancher.

Comme il apparaît clairement dans ce billet, le sujet de Kubernetes est encore relativement nouveau et le marché essaie encore de rattraper la liste complète des fonctionnalités que tout système basé sur Kubernetes exige dès le départ. La nature même de Kubernetes transforme les applications en un animal très différent de ce qu’il était auparavant, ce qui nous amène à la liste actuelle des solutions qui excellent dans un domaine et peinent à rattraper leur retard dans l’autre.

Il est clair que Kubernetes est un domaine technologique en pleine expansion, et l’on peut donc affirmer sans risque de se tromper que d’autres solutions verront bientôt le jour, et que les solutions actuelles deviendront probablement encore meilleures qu’elles ne le sont actuellement. Un exemple de solution Kubernetes nouvelle et puissante est représenté par Bacula Enterprise.

La solution de sauvegarde Kubernetes de Bacula Enterprise

La nature même des environnements Kubernetes les rend à la fois très dynamiques et potentiellement complexes. La sauvegarde d’un cluster Kubernetes ne doit pas ajouter inutilement à la complexité. Et bien sûr, il est généralement important – voire critique – pour les administrateurs système et les autres personnels informatiques d’avoir un contrôle centralisé sur le système complet de sauvegarde et de restauration de l’ensemble de l’organisation, y compris de tout environnement Kubernetes. De cette façon, des facteurs tels que la conformité, la facilité de gestion, la vitesse, l’efficacité et la continuité des activités deviennent beaucoup plus réalistes. Dans le même temps, l’approche agile des équipes de développement ne doit ainsi en aucun cas être compromise.

Bacula Enterprise est unique dans cet espace car il s’agit d’une solution d’entreprise complète pour les environnements informatiques complets (pas seulement Kubernetes) qui offre également une sauvegarde et une restauration Kubernetes intégrées nativement, y compris pour les clusters multiples, que les applications ou les données résident à l’extérieur ou à l’intérieur d’un cluster spécifique. Le département des opérations de chaque entreprise reconnaît la nécessité de disposer d’une stratégie de récupération appropriée lorsqu’il s’agit de la récupération d’un cluster, de mises à niveau et d’autres situations. Un cluster qui est dans un état irrécupérable peut être ramené à l’état stable avec Bacula si les fichiers de configuration et les volumes persistants du cluster ont été correctement sauvegardés au préalable.

Une autre façon de montrer les méthodes de travail de Bacula est d’utiliser l’image ci-dessous :

L’un des principaux avantages du module Kubernetes de Bacula est la possibilité de sauvegarder diverses ressources Kubernetes, notamment :

• Dossiers
• Services
• Déploiements
• Volumes persistants.

Caractéristiques du module Kubernetes de Bacula Enterprise

Le fonctionnement de ce module est le suivant : la solution elle-même ne fait pas partie de l’environnement Kubernetes, mais accède aux données pertinentes à l’intérieur du cluster via des pods Bacula attachés à des nœuds Kubernetes individuels dans un cluster. Le déploiement de ces pods est automatique et fonctionne selon les besoins.

Parmi les autres fonctionnalités offertes par le module de sauvegarde Kubernetes, citons :

• La sauvegarde et la restauration Kubernetes pour les volumes persistants
• La restauration d’une seule ressource de configuration Kubernetes
• La possibilité de restaurer les fichiers de configuration et/ou les données des volumes persistants vers le répertoire local
• La possibilité de sauvegarder la configuration des ressources des clusters Kubernetes.

Il convient également de noter que Bacula prend en charge plusieurs plateformes de stockage en nuage simultanément, notamment AWS, Google, Glacier, Oracle Cloud et Azure, au niveau de l’intégration native. Des capacités de cloud hybride sont ainsi intégrées, y compris des fonctions avancées de gestion du cloud et de mise en cache automatisée du cloud, permettant une intégration facile des services de cloud public ou privé pour prendre en charge diverses tâches.

La flexibilité des solutions est particulièrement importante de nos jours, car de nombreuses sociétés et entreprises deviennent de plus en plus complexes en termes de familles d’hyperviseurs et de conteneurs différents. Dans le même temps, cela augmente considérablement la demande de flexibilité des fournisseurs de bases de données. Les capacités de Bacula à cet égard sont substantiellement élevées, combinant sa large liste de compatibilité avec diverses technologies pour atteindre des standards de flexibilité particulièrement élevés sans s’enfermer dans un seul fournisseur.

La complexité toujours croissante des différents aspects du travail de toute organisation est en constante augmentation, et il est le plus souvent plus facile et plus rentable d’utiliser une seule solution pour l’ensemble de l’environnement informatique, et non plusieurs solutions à la fois. C’est exactement ce que propose Bacula, qui est également capable de fournir une interface web traditionnelle pour vos besoins de configuration, ainsi qu’une ligne de commande classique. Ces deux interfaces peuvent même être utilisées simultanément.

Le plugin de sauvegarde Kubernetes de Bacula permet deux types de cibles principales pour les opérations de restauration :

• Restauration vers un répertoire local
• Restauration vers un cluster

Des sauvegardes régulières et/ou automatisées sont fortement recommandées pour assurer le meilleur environnement de sauvegarde et de restauration possible pour les conteneurs. Tester vos sauvegardes de temps en temps devrait également être obligatoire pour votre administrateur système. Dans l’image suivante, vous verrez une partie du processus de restauration, à savoir la partie Sélection de la restauration, dans laquelle vous pouvez choisir les fichiers et/ou les répertoires que vous voulez restaurer :

Une autre partie du processus de restauration que vous rencontrerez est la page des options de restauration avancées, qui ressemble à ceci :

Vous pouvez y spécifier plusieurs options différentes, telles que le format de sortie, le chemin du fichier de configuration KBS, le port du point de terminaison, etc.

Il est également facile de surveiller l’ensemble du processus de restauration une fois la personnalisation terminée, grâce à la page de journal du travail de restauration qui enregistre chaque action une par une :

Une autre capacité importante du module Kubernetes est la fonction Plugin Listing, qui offre de nombreuses informations utiles sur vos ressources Kubernetes disponibles, notamment les espaces de noms, les volumes persistants, etc. Pour ce faire, le module utilise une commande spéciale .ls avec un paramètre spécifique plugin=<plugin>.

Le module Kubernetes de Bacula offre une variété de fonctionnalités, dont certaines sont :

• Redéploiement rapide et efficace des ressources du cluster
• Sauvegarde de l’état du cluster Kubernetes
• La sauvegarde des configurations pour être utilisées dans d’autres operations
• Maintien des configurations modifiées aussi sûres que possible et restauration du même état exact qu’auparavant

Bien que cela arrive souvent, il est fortement recommandé d’éviter de payer votre fournisseur en fonction du volume de données. Il est insensé de se faire rançonner, maintenant ou à l’avenir, par un fournisseur prêt à profiter de votre organisation de cette manière. Au lieu de cela, examinez attentivement les modèles de licence de Bacula Systems, qui permettent à ses clients de ne pas être exposés aux frais de croissance des données, tout en facilitant la prévision des coûts futurs pour les services d’achat des clients. Cette approche plus raisonnable de Bacula vient de ses racines open source et résonne bien dans un environnement DevOps.

Velero & Bacula Enterprise : Quelle est la différence ?

Cela ne veut pas dire qu’il n’y a pas d’autres solutions sur le marché, qu’elles soient payantes ou gratuites. Par exemple, Velero.

Velero (précédemment appelé Heptio Ark) est une solution de sauvegarde et de restauration open-source gratuite qui se concentre principalement sur le travail avec les clusters / volumes persistants Kubernetes. Elle a la capacité de travailler avec un certain nombre de plateformes cloud différentes via des plugins spécifiques, et vous pouvez choisir si vous voulez l’exécuter sur place ou au sein de la plateforme de cloud public de votre choix.

Les trois principaux domaines cibles des capacités de Velero sont les suivants :

• La réplication de cluster de production à des fins de test ou de développement
• Capacités générales de sauvegarde et de restauration pour les clusters Kubernetes
• Fonctionnalité de migration de clusters.

L’idée du fonctionnement de Velero est constituée de deux parties principales : un serveur travaillant au sein de votre cluster et un client local représenté par une ligne de commande pour vos besoins d’exploitation. Il est également assez unique dans la façon dont il fonctionne avec les clusters Kubernetes, ainsi.

L’API Kubernetes est utilisée pour capturer l’état spécifique des clusters et effectuer le processus de restauration si nécessaire. C’est différent de ce que la majorité des autres solutions font – elles accèdent directement aux bases de données Kubernetes etcd et interagissent avec les données en question par ce biais (Bacula Pods est un tel exemple). Les avantages de tout faire via l’API sont les suivants :

• Même si les ressources exposées via l’API sont stockées dans une base de données distincte, elles peuvent toujours être sauvegardées et/ou restaurées rapidement et efficacement
• Les sauvegardes peuvent être quelque peu sélectives, capturant des sous-ensembles spécifiques des ressources d’un cluster, filtrées par type de ressource, espace de noms, etc., ce qui offre beaucoup plus de flexibilité en ce qui concerne les données que vous souhaitez sauvegarder
• Il n’est pas rare que les utilisateurs d’offres Kubernetes gérées n’aient pas accès à la base de données etcd sous-jacente, ce qui rend les sauvegardes et restaurations directes pratiquement impossibles et les oblige à utiliser diverses solutions de contournement.

Lorsqu’il s’agit de comparer directement Velero et Bacula, on peut dire que chacun a ses propres avantages et bénéfices.

Bacula est beaucoup plus complet en termes de solution de sauvegarde et de restauration d’entreprise, et offre une gamme particulièrement large de fonctionnalités et de technologies que l’on peut attendre d’une solution d’entreprise lourde. Par conséquent, Bacula offre une solution complète de sauvegarde sur une seule plate-forme pour les moyennes et grandes entreprises. Bacula dispose également de « BWeb », une interface web complète pour les nombreuses fonctionnalités qu’il propose. Bacula est probablement la solution qu’un directeur informatique choisirait lorsqu’il a besoin de sauvegarder des environnements informatiques complexes et changeants à l’aide d’une plateforme unique et moderne.

Velero, en revanche, est spécifique dans le sens où il n’essaie pas de couvrir tous les aspects de la sauvegarde de toutes les applications, données et types de stockage, mais se concentre plutôt uniquement sur le travail avec Kubernetes. Certains utilisateurs pourraient trouver cela plus attrayant plutôt qu’une solution tout-en-un. Il y a aussi l’approche unique adoptée par Velero pour travailler avec les données et les sauvegardes – via une API. Enfin, et ce n’est pas le moindre des avantages, Velero est gratuit et open source. Malgré tous les avantages dont dispose Bacula, il est conçu pour être une solution haut de gamme pour les moyennes et grandes entreprises, et cela, bien sûr, n’est pas représentatif de tous les utilisateurs de Kubernetes.