Google Cloud Backup : le guide complet sur le BaaS

Comment repérer un fournisseur dont la solution n'a pas été véritablement conçue pour GCP

Vous pouvez déterminer si un fournisseur de solutions de sauvegarde a réellement conçu sa solution pour Google Cloud en fonction des questions qu'il pose lors du premier entretien commercial. Si ses premières questions sont « de combien de serveurs de sauvegarde avez-vous besoin » ou « quelle est votre capacité maximale en téraoctets », c’est qu’il n’a pas conçu sa solution pour Google Cloud. Il a développé une appliance fixe qu’il a ensuite déployée sur GCP.

Ce schéma se répète si souvent que je m’en sers désormais comme critère de diagnostic. Les questions posées par un fournisseur révèlent l’architecture qu’il propose. Les architectures natives du cloud ne nécessitent pas ce type de réponses. Les appliances hébergées dans le cloud, en revanche, en ont besoin.

Cet article passe en revue ce qu’un véritable service BaaS pour Google Cloud doit offrir, les bonnes questions à poser pour évaluer les fournisseurs, ainsi que ce que couvrent les fonctionnalités natives de GCP et les lacunes qu’elles laissent. 

Pourquoi les fonctionnalités intégrées de Google Cloud ne constituent pas une stratégie

Google fournit des éléments de protection utiles : les instantanés de Persistent Disk, les sauvegardes automatisées de Cloud SQL, le contrôle de version des objets GCS, les instantanés de tables BigQuery. Ils ne constituent toutefois pas une stratégie de sauvegarde. 

Le modèle de responsabilité partagée de GCP est explicite. Google gère la sécurité et la disponibilité de l’infrastructure. Le client gère les données. Si un administrateur supprime un projet, si un ransomware chiffre un disque persistant, si une erreur de configuration efface des données Cloud SQL ou si un développeur supprime la mauvaise table BigQuery, Google appliquera consciencieusement cette action. La restauration relève de la responsabilité du client.

Quatre lacunes que les fonctionnalités natives ne comblent pas : la conservation indépendante, afin que les sauvegardes subsistent même si la charge de travail source est supprimée ; la cohérence des applications, afin que les bases de données et les applications soient restaurées de manière intacte, et non pas simplement dans un état cohérent au moment du crash ; L’isolation interrégionale et interprojet, afin qu’une compromission dans un emplacement ne compromette pas la protection. Et la restauration granulaire, afin qu’un fichier, une table ou une machine virtuelle puisse être restauré sans avoir à tout reconstruire.

Ce que signifie réellement une couverture GCP complète

Un fournisseur qui ne protège que les machines virtuelles Compute Engine propose une solution de sauvegarde cloud datant de 2018. Un véritable BaaS protège toutes les catégories de charges de travail via un seul plan de gestion.

Les bonnes questions à poser à tout fournisseur de sauvegarde GCP

Cinq questions qui mettent en évidence la différence entre une architecture native du cloud et des appliances hébergées dans le cloud.

La solution peut-elle évoluer de manière élastique avec Google Cloud ? La réponse est oui, grâce aux politiques de sauvegarde et aux compartiments Cloud Storage, sans qu’il soit nécessaire de provisionner des nœuds ni de prévoir la capacité. Ajoutez un nouveau projet GCP demain et la protection devrait s’appliquer automatiquement, sans intervention opérationnelle.

Dans quelle mesure la solution est-elle native et intégrée ? Trois tests concrets. Premièrement, l’IAM. Le service s’authentifie-t-il via l’IAM de Google Cloud, en héritant des autorisations existantes et de la structure du projet ? Deuxièmement, l’interface API. Le service fonctionne-t-il via les API de Google Cloud afin que les données ne quittent jamais les limites de GCP ? Troisièmement, la facturation. Peut-on y accéder via Google Cloud Marketplace, les frais étant intégrés à la facturation GCP existante ? 

Prend-il en charge Cloud SQL, BigQuery, GKE et SAP HANA, et pas seulement Compute Engine ? Une sauvegarde limitée aux machines virtuelles (VM) passe à côté de la plupart des éléments qui s’exécutent dans les environnements GCP modernes. Demandez des précisions sur chaque catégorie de charge de travail. Des réponses génériques sont synonymes d’une protection générique. 

À quoi ressemble la restauration interrégionale et interprojet ? Les charges de travail évoluent vers des déploiements multirégionaux et multiprojet. Le mécanisme de sauvegarde qui fonctionnait dans un seul projet ne fonctionne plus au niveau des frontières. Demandez au fournisseur de vous présenter une démonstration de restauration couvrant les deux aspects.

Comment la tarification évolue-t-elle à mesure que l’environnement s’étend ? Recherchez un modèle économique de « paiement à l’utilisation » basé sur les données sources effectivement sauvegardées, et non sur la capacité maximale réservée.

Trois piliers : sauvegarde, migration et reprise après sinistre

Le BaaS pour Google Cloud couvre trois cas d’utilisation étroitement liés. Les solutions performantes gèrent ces trois aspects via une seule plateforme, un cadre de politiques unique et un modèle de reprise unique.

La sauvegarde proprement dite. Sauvegarde et reprise cohérentes au niveau de l’application pour chaque catégorie de charge de travail, en utilisant les snapshots natifs de Google Cloud comme premier niveau de protection et Google Cloud Storage pour la conservation à long terme. L’intégration étroite à la plateforme garantit un impact quasi nul sur les performances de production. 

Migration vers et au sein de GCP. Le même mécanisme de sauvegarde sert également de mécanisme de migration. Transférez (lift and shift) des charges de travail de production depuis un environnement sur site, depuis un autre cloud ou d’une région GCP vers une autre, en utilisant les données de sauvegarde existantes comme source de migration. La cohérence applicative est préservée tout au long du transfert. 

Reprise après sinistre à l’aide de GCP. Google Cloud sert de cible de reprise après sinistre pour les charges de travail sur site ou provenant d’autres clouds. Le modèle économique est déterminant. Stockez en continu des copies de sauvegarde dans GCP à faible coût, mais ne consommez de la puissance de calcul et du stockage haute performance que lorsqu’une reprise après sinistre est effectivement déclenchée. La majeure partie de l’année, vous ne payez que pour le stockage. Les rares jours où une catastrophe survient, vous payez pour la puissance de calcul. Cela ne représente qu’une fraction du coût d’une reprise après sinistre en mode « toujours actif ».

Comment le « lift-and-shift » de GCP fonctionne concrètement avec les données de sauvegarde

Le processus technique comporte quatre étapes lors de la migration de charges de travail Compute Engine depuis un environnement sur site. 

Récupérez l’image disque de la machine virtuelle de production à partir de la sauvegarde existante. Exportez-la vers une cible SMB ou NFS accessible depuis le poste de travail de migration.

Installez le SDK Google Cloud sur le poste de travail. 

Créez un compartiment Cloud Storage dans le projet de destination et téléversez-y les fichiers du disque de la machine virtuelle.

Importez les disques en tant qu’images personnalisées Compute Engine à l’aide de la commande `gcloud compute images import`, en précisant le compartiment source et le système d’exploitation.

Une fois l’image personnalisée créée, de nouvelles instances Compute Engine peuvent être lancées directement à partir de celle-ci. Ce même modèle s’applique à la migration interrégionale au sein de GCP et à la migration depuis d’autres clouds.

Questions fréquentes sur la sauvegarde GCP

Puis-je me fier uniquement aux fonctionnalités intégrées de Google Cloud ?

Non. Ces fonctionnalités intégrées constituent des éléments de base utiles, mais elles ne permettent pas une conservation indépendante, la cohérence des applications sur des charges de travail multi-ressources, l’isolation entre projets, ni la restauration granulaire pour de nombreux types de charges de travail. Un véritable service BaaS vient se superposer à ces fonctionnalités intégrées.

Comment puis-je récupérer mes données après une suppression accidentelle ou une attaque par ransomware ? 

Restaurez les données à n’importe quel moment de conservation, même après une suppression ou un chiffrement. Les options de restauration vont d’un fichier unique au sein d’une machine virtuelle, d’une table unique dans BigQuery ou d’un espace de noms unique dans GKE, jusqu’à la restauration complète d’une machine virtuelle ou d’un projet entier, dans la région d’origine ou dans une autre. La conservation est indépendante de la charge de travail source. 

Le service BaaS de GCP est-il sécurisé et conforme ?

Chiffrement en transit et au repos, intégration avec Google Cloud IAM, et certifications SOC 2, HIPAA et RGPD. Grâce à une architecture native du cloud, les données de sauvegarde restent entièrement au sein de l’environnement GCP. 

Le BaaS fonctionne-t-il avec SAP HANA, GKE et BigQuery ?

Il devrait. SAP HANA nécessite une sauvegarde adaptée aux applications et intégrée à la gestion des journaux de HANA. GKE nécessite une granularité au niveau des conteneurs, des volumes persistants et des espaces de noms. BigQuery nécessite une sauvegarde au niveau des ensembles de données et des tables. Un fournisseur qui ne prend en charge que les machines virtuelles Compute Engine passe à côté de la majeure partie de ce qui s’exécute dans l’environnement GCP moderne.

Testez-le dans votre environnement

HYCU R-Cloud pour Google Cloud est disponible directement sur le Google Cloud Marketplace. La version d’essai utilise votre compte GCP réel, vos charges de travail réelles et vos données réelles. Vous pouvez le faire fonctionner en 15 minutes. La plupart des équipes savent en quelques jours si la solution leur convient. Le lien vers la version d’essai se trouve à l’adresse hycu.com/trial.