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 simplement transféré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, elles, en ont besoin. 

Cet article présente ce qu’un véritable 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 primitives 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. Elles ne constituent 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 rançongiciel chiffre un Persistent Disk, 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. 

Quelles sont les quatre lacunes que les fonctionnalités natives ne comblent pas ? Une 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 se rétablissent correctement, et pas seulement de manière cohérente en cas de panne. L’isolation interrégionale et interprojet, afin qu’une compromission à 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. 

Que signifie réellement une couverture complète de GCP 

 Un fournisseur qui ne protège que les machines virtuelles Compute Engine propose une solution de sauvegarde dans le 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 à des politiques de sauvegarde et à des 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 Google Cloud IAM, en reprenant les autorisations existantes et 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 l’environnement GCP ? Troisièmement, la facturation. Peut-on y accéder via Google Cloud Marketplace, les frais étant facturés via le système de facturation GCP existant ? 

Prend-il en charge Cloud SQL, BigQuery, GKE, et SAP HANA, et pas seulement Compute Engine ? Une sauvegarde limitée aux machines virtuelles passe à côté de la majeure partie de ce qui s’exécute dans les environnements GCP modernes. Demandez des précisions sur chaque catégorie de charge de travail. Des réponses génériques impliquent 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 multiprojets. Le mécanisme de sauvegarde qui fonctionnait dans un projet unique ne fonctionne plus à la frontière entre les projets. Demandez au fournisseur de vous présenter une démonstration de restauration couvrant les deux. 

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 : la sauvegarde, la migration et la reprise après sinistre 

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

La sauvegarde elle-même. Sauvegarde et restauration cohérentes au niveau de l’application pour chaque catégorie de charge de travail, en utilisant les instantanés 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) les 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 des applications est préservée tout au long du transfert. 

Reprise après sinistre à l’aide de GCP. Google Cloud sert de destination 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 des ressources de calcul et de stockage haute performance que lorsqu’une reprise après sinistre est effectivement déclenchée. La majeure partie de l’année, vous payez pour le stockage. Le jour rare où un sinistre survient, vous payez pour les ressources de calcul. Cela ne représente qu’une fraction du coût d’une reprise après sinistre en mode « toujours actif ». 

Comment fonctionne concrètement le « lift-and-shift » de GCP 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échargez-y les fichiers de 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 processus s’applique à la migration interrégionale au sein de GCP ainsi qu’à la migration depuis d’autres clouds. 

Questions fréquentes sur la sauvegarde dans 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 procéder à une restauration après une suppression accidentelle ou une attaque par ransomware ? 

Restaurez les données à n’importe quel moment antérieur, même après une suppression ou un chiffrement. Les options de récupération 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 durée de 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 le GCP moderne. 

Testez-le sur 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.