Pourquoi sauvegarder les données Google Cloud ?

Cette question ne doit pas être prise à la légère. Malheureusement, elle fait souvent partie des dernières prises en compte lors de la planification d’une migration vers le cloud. Actuellement, la tendance consiste à penser que par défaut, tout ce qui est transféré dans le cloud est protégé. D’ailleurs, pourquoi ne serait-ce pas le cas ? Après tout, la sécurité du cloud ne fait-elle pas partie intégrante du concept « en mode service » ?

Certes, les fournisseurs de cloud public à très grande échelle comme Google garantissent la disponibilité et la fiabilitéde l’infrastructure qu’ils mettent à votre disposition pour créer et déployer des applications et services, mais aussi pour stocker des données. Mais c’est toujours à vous, le client, qu’il appartient de sécuriser et de protéger les données réelles que vous transférez dans le cloud, et c’est encore à vous qu’il incombe de les sauvegarder.

Modèle de responsabilité de Google

Prenons un exemple simple : vous hébergez sur Google Cloud Platform (GCP) quelques VM qui constituent l’environnement de votre équipe de développement. La responsabilité de Google est de s’assurer que ces VM sont opérationnelles chaque fois que vous en avez besoin pour respecter vos contrats de niveau de service. Google doit également veiller à ce que ces machines soient toujours disponibles, même si le datacenter qui les héberge est endommagé par une catastrophe naturelle. Dans n’importe quelle situation similaire, pouvant entraîner une interruption des services informatiques, Google est tenu de s’assurer que les services que vous utilisez sont répliqués et disponibles via un deuxième datacenter situé dans une autre région. En revanche, en cas de problème causé par des données avec lesquelles vos développeurs ont travaillé — la suppression accidentelle d’une VM, par exemple —, Google ne serait responsable pour AUCUN type de service fourni (IaaS, PaaS ou SaaS).

Il ne s’agit-là que d’un risque parmi d’autres auxquels vous vous exposez en ne sauvegardant pas correctement les données stockées sur GCP. Toute activité malveillante ou erreur de configuration d’autorisations exposant vos données accessibles via une adresse IP publique sera, là encore, en dehors de la responsabilité de Google, à savoir fournir une infrastructure fiable pour répondre à vos besoins.

Par conséquent, si vous prévoyez de migrer vers Google Cloud Platform, vous devez IMPÉRATIVEMENT mettre en place une stratégie de sauvegarde et restauration efficace pour vos workloads cloud.

Comment sauvegarder des données Google Cloud ?

La réponse à cette question est très simple : la méthode est différente de celle employée pour les données locales.

En général, le premier réflexe des utilisateurs faisant appel à la sauvegarde Google Cloud consiste à utiliser un agent. Après tout, nous n’avons pas accès à l’hyperviseur sous-jacent qui héberge nos VM, et tout fonctionne parfaitement… à première vue. Une approche basée sur des agents, loin d’être inefficace, peut même dans certains cas présenter des avantages en termes de traitement prenant en charge les applications. Pourtant, les agents ne sont pas toujours la solution idéale. Ils ne sont pas compatibles avec toutes les plateformes et ne peuvent pas tirer parti des structures d’évolutivité, de sécurité et de stockage natives (qui ont motivé notre migration vers le cloud), sans parler de la gestion de la restauration, qui peut tourner au cauchemar.

Il existe une bien meilleure méthode ! Une solution native conçue pour GCP.

Comment choisir une solution native cloud ?

Il est de plus en plus évident que pour les workloads basés sur GCP, vous avez besoin d’une solution de sauvegarde et restauration native Google, adaptée aux spécificités du cloud. Ce serait d’ailleurs encore mieux si cette solution pouvait également protéger et gérer les données de vos autres environnements, car il est probable que vous gériez une infrastructure hybride et n’ayez pas prévu que 100 % des workloads résident dans un cloud. Ensuite, comment choisir le fournisseur qui vous convient ? Existe-il une solution intégrée dans les services Google ?

GCP propose bien évidemment des méthodes natives pour sauvegarder les instances Google Compute Engine. Ces méthodes vous permettent de créer des snapshots natifs de vos données, et même de planifier l’exécution régulière de snapshots que vous pouvez ensuite transférer dans des buckets Google Cloud Storage.

Toutefois, ce type de méthode n’est pratique qu’à très petite échelle ou à des fins de test. Dans les environnements de production plus étendus, il est plus difficile d’atteindre des objectifs de niveaux de service (SLO). S’appuyer uniquement sur des scripts et snapshots écrits en interne peut représenter des risques de sécurité et de perte de données. Les snapshots ne constituent pas à eux seuls une solution optimale si vous avez besoin d’une durée de rétention plus longue. De plus, ils ne sont pas automatiquement isolés de l’environnement de production.

La bonne nouvelle, c’est que Veeam a établi un partenariat avec Wiley pour créer un autre guide de sa célèbre série « pour les Nuls » : Sauvegarde Google Cloud pour les Nuls. Cet e-book GRATUIT vous aidera à mieux comprendre les risques liés aux données cloud et les éléments nécessaires pour être certain qu’une infrastructure cloud est à la fois fiable et résiliente. Vous y découvrirez des instructions détaillées pour assurer la haute disponibilité des données Google Cloud, ainsi que des conseils pratiques pour concevoir un plan de sauvegarde et restauration à partir de zéro ou optimiser une stratégie existante. Enfin et surtout, vous bénéficierez des conseils d’experts en sécurité du cloud, qui vous aideront à tirer le meilleur parti des outils de protection des données natifs Google et de solutions tierces natives conçues spécifiquement, comme Veeam Backup for Google Cloud Platform.

Recevez votre exemplaire gratuit dès aujourd’hui !

NOUVELLE
V11A

Limitez les pertes de données
Bloquez les ransomwares

#1 Backup and Recovery

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.