Présentation de Backup and DR pour la console de gestion

Backup and DR pour la console de gestion est une solution de sauvegarde et de reprise après sinistre basée sur un appareil qui vous permet de capturer, stocker, répliquer et récupérer de manière centralisée des machines virtuelles (VM), des systèmes de fichiers et des bases de données autogérées dans des environnementsGoogle Cloud et hybrides. Grâce à une console de gestion des appliances Web dédiée et à des appliances de sauvegarde/récupération déployées par le client, vous pouvez gérer la protection des données de vos charges de travail.

Backup and DR pour la console de gestion capture les données dans un format incrémentiel permanent et les stocke dans son format intégré lisible par l'application. Comme les sauvegardes sont stockées de manière native plutôt que sous forme d'archives de sauvegarde propriétaires, vous pouvez installer instantanément des images de sauvegarde directement à partir d'un appareil de sauvegarde/récupération pour récupérer des charges de travail, provisionner des copies virtuelles à des fins de test et de développement, ou migrer des données avec un temps d'arrêt minimal.

Abandon de Backup and DR pour la console de gestion

Google Cloud Backup and DR ne prendra plus en charge l'ancienne console de gestion des appliances (pile IaaS) et les charges de travail gérées par l'utilisateur qui lui sont associées à compter du 30 septembre 2027. Planifiez votre migration vers d'autres méthodes de sauvegarde dès que possible pour maintenir une protection continue des données.

Charges de travail concernées par l'abandon de la console de gestion

L'abandon de la console de gestion n'affecte que les charges de travail autogérées protégées par l'ancienne console de gestion des dispositifs, y compris :

  • Instances Compute Engine gérées via la console de gestion de l'appareil
  • Bases de données IBM Db2
  • Bases de données Oracle
  • Bases de données SAP HANA
  • Bases de données Microsoft SQL Server
  • VM Google Cloud VMware Engine
  • Applications génériques et groupes de cohérence
  • Systèmes de fichiers gérés par l'utilisateur (systèmes de fichiers Linux et Windows, état du système, NFS et SMB/CIFS)

Les services first party gérés par Google et protégés directement via la consoleGoogle Cloud (y compris les VM Compute Engine, les disques persistants, Cloud SQL, AlloyDB pour PostgreSQL et Filestore) ne sont pas concernés par cet abandon.

Calendrier et étapes de l'abandon

L'abandon de Backup and DR pour la console de gestion suit trois étapes clés d'application :

  • 31 décembre 2026 (suppression des serveurs de gestion inactifs) : tout serveur de gestion de votre projet est automatiquement supprimé après 30 jours consécutifs d'inactivité. Un serveur de gestion n'est considéré comme inactif que s'il ne comporte aucune sauvegarde active, aucune application ou charge de travail protégée, et aucun job de sauvegarde actif.
  • 30 septembre 2027 (gel des sauvegardes) : la création de sauvegardes à l'aide de l'ancienne pile de la console de gestion des appliances ne sera plus possible. Si vous ne migrez pas avant cette date limite, vous ne pourrez plus effectuer de nouvelles sauvegardes des charges de travail concernées.
  • 31 mars 2028 (date limite de restauration) : fin des fonctionnalités de restauration directe via l'ancienne interface de la console de gestion des appliances. Pour restaurer des sauvegardes après cette date limite, vous devez utiliser l'utilitaire et les scripts de récupération de la conservation à long terme (LTR) autonomes.

Alternatives de migration pour les charges de travail de la console de gestion

Pour maintenir la protection des sauvegardes avant le gel des sauvegardes du 30 septembre 2027, migrez vos charges de travail concernées vers l'une des solutions de sauvegarde compatibles suivantes :

Charge de travail Option de migration Référence
Compute Engine Sauvegardes Compute Engine natives de Google Migrez des instances Compute Engine vers une architecture sans dispositif à l'aide de Google Cloud Backup and DR pour les instances Compute Engine.
Bases de données gérées par l'utilisateur (IBM Db2, Oracle, SAP HANA, Microsoft SQL Server, etc.) Sauvegardes stockées dans un vault cohérentes avec les applications à l'aide de scripts personnalisés Utilisez les sauvegardes de VM et de disques persistants Compute Engine sur Google Cloud Backup and DR avec le framework guest-flush, associé à des scripts personnalisés pour des sauvegardes immuables et cohérentes avec les applications.
SAP HANA Sauvegardes Google Cloud basées sur un agent Utilisez l'agent Backint Google Cloud natif ou les instantanés de disque persistant. Consultez le guide de sauvegarde et de récupération de l'agent pour SAP Backint ou le guide de sauvegarde et de récupération d'instantanés de disque.
Charges de travail de VM générales Instantanés de disque Google Cloud natifs Configurez des instantanés de disque standards ou d'archive pour sauvegarder régulièrement des disques virtuels à l'aide du guide sur les instantanés de disque.
Toutes les charges de travail Solutions tierces sur Marketplace Déployez des solutions de sauvegarde d'entreprise alternatives approuvées disponibles sur Google Cloud Marketplace.

Conserver et récupérer des sauvegardes après le 31 mars 2028

Pour conserver les fonctionnalités de récupération des sauvegardes au-delà de la date limite de restauration du 31 mars 2028, migrez vos anciennes données de sauvegarde vers le stockage OnVault dans Cloud Storage avant l'arrêt de vos appliances :

  1. Attribuer des règles OnVault : migrez toutes les anciennes sauvegardes critiques vers des buckets Cloud Storage OnVault.
  2. Synchroniser les métadonnées : assurez-vous que toutes les métadonnées des instantanés de disque persistant sont entièrement synchronisées avec votre bucket Cloud Storage avant l'arrêt de vos appareils locaux. Contactez gcbdr-umdb-transition@google.com ou Cloud Customer Care pour vérifier et effectuer ce transfert de métadonnées.
  3. Utiliser l'utilitaire de récupération : utilisez l'outil et les scripts autonomes pour découvrir et installer des images de sauvegarde OnVault et Persistent Disk directement à partir de vos buckets Cloud Storage. Pour obtenir des instructions, consultez Restaurer des sauvegardes conservées à long terme.

Si vous avez des questions ou si vous avez besoin d'aide pour planifier votre migration, contactez l'équipe de transition à l'adresse gcbdr-umdb-transition@google.com, Cloud Customer Care ou l'équipe responsable de votre compte Google Cloud.

Différences entre Backup and DR pour la console de gestion et Google Cloud Backup and DR

Google propose deux modèles de gestion et d'architecture distincts pour Backup and DR :

  • Backup and DR pour la console de gestion (cet ensemble de documentation) : architecture basée sur des appliances dans laquelle vous déployez et gérez des appliances de sauvegarde/récupération dans votre réseau cloud privé virtuel (VPC) et orchestrez la protection via la console de gestion des appliances dédiée basée sur le Web. Cette offre est conçue pour les bases de données autogérées (telles qu'Oracle, Microsoft SQL Server, SAP HANA et IBM Db2), les VM Google Cloud VMware Engine et VMware vSphere, les systèmes de fichiers et les charges de travail qui nécessitent des installations instantanées basées sur les applications, des clones de bases de données virtuels (LiveClones) ou des workflows Backup and DR automatisés.
  • Google Cloud Backup and DR : une expérience de sauvegarde gérée par SaaS et cloud native, directement intégrée à la consoleGoogle Cloud , à la gcloud CLI, à l'API backupdr et à Terraform. AvecGoogle Cloud Backup and DR, vous protégez les ressources Google Cloud natives (telles que les instances Compute Engine, les disques persistants et les Google Cloud Hyperdisks, les instances Cloud SQL, les clusters AlloyDB et les instances Filestore) directement dans des coffres de sauvegarde immuables gérés par Google, sans déployer ni gérer d'appareils de sauvegarde/récupération.

Le tableau suivant récapitule les principales différences entre les deux offres Backup and DR :

Fonctionnalité Backup and DR pour la console de gestion Google Cloud Backup and DR
Interface de gestion principale Console de gestion d'appliance Web dédiée et API de la console de gestion Google Cloud console, gcloud CLI, API backupdr et Terraform
Architecture et plan de données Architecture d'appareil à trois niveaux composée de la console de gestion de l'appareil, d'appareils de sauvegarde/récupération déployés par le client (VM Compute Engine dans votre VPC) et d'agents Backup and DR légers sur les hôtes de charge de travail Plan de service Google entièrement géré ; aucun dispositif de sauvegarde/récupération déployé par le client ni agent invité n'est requis pour les ressources protégées par un coffre-fort et natives de la console
Modèle de configuration de sauvegarde Modèles de sauvegarde (contenant des règles d'instantané, OnVault et de réplication) combinés à des profils de ressources Plans de sauvegarde natifs de la console et règles de sauvegarde associées directement à un coffre de sauvegarde cible
Cibles de stockage Pools de stockage gérés par l'appliance (pool principal, pool d'instantanés sur disque persistant, pool OnVault dans Cloud Storage et pool miroir sur une appliance distante), ainsi que coffres de sauvegarde gérés par Google pour les charges de travail compatibles Coffres de sauvegarde gérés par Google, immuables et indélébiles, avec conservation forcée et stockage régional ou multirégional
Récupération et accès aux données Restauration complète, installations standards instantanées, installations Application Aware, copies virtuelles (LiveClones), installation et migration, et workflows Backup and DR automatisés Restauration directe vers des ressources Google Cloud nouvelles ou existantes à partir d'un coffre de sauvegarde
Charges de travail compatibles Google Cloud VMware Engine, VM VMware vSphere, instances Compute Engine, systèmes de fichiers Linux et Windows (y compris NFS, SMB et Filestore), Oracle, Microsoft SQL Server, SAP HANA, IBM Db2, PostgreSQL, SAP ASE, SAP IQ, SAP MaxDB, MySQL, MariaDB, groupes de cohérence et applications génériques Instances Compute Engine, disques persistants et Hyperdisks, Cloud SQL, AlloyDB et Filestore (ainsi que la visibilité sur les sauvegardes des coffres de sauvegarde créées par la console de gestion du dispositif)

Architecture et composants principaux de Backup and DR pour la console de gestion

Backup and DR pour la console de gestion utilise une architecture à trois niveaux pour orchestrer et exécuter la protection des données dans votre environnement :

  • Console de gestion des dispositifs : plan de contrôle Web centralisé dans lequel vous gérez les dispositifs de sauvegarde/récupération, enregistrez les hôtes, découvrez les applications, configurez les modèles de sauvegarde et les profils de ressources, et surveillez les jobs de sauvegarde et de récupération. La console de gestion des appliances s'exécute dans un projet locataire géré par Google et communique de manière sécurisée avec vos appliances de sauvegarde/récupération à l'aide de Private Service Connect ou de l'accès privé à Google.
  • Appareils de sauvegarde/restauration : appareils virtuels Compute Engine déployés dans votre projet Google Cloud et votre réseau VPC. L'appareil de sauvegarde/restauration agit comme le plan de données qui capture les données des charges de travail sources, gère les métadonnées du catalogue, gère les pools de stockage, réplique les données sur des appareils ou un stockage d'objets distants, et diffuse des installations instantanées. Vous pouvez choisir parmi quatre facteurs de forme d'appareil en fonction du type de charge de travail, de la taille de l'ensemble de données et de la capacité de stockage.
  • Agents Backup and DR : agents logiciels légers installés sur les systèmes d'exploitation invités Linux ou Windows. L'agent Backup and DR communique avec l'appareil de sauvegarde/récupération pour découvrir les bases de données et les systèmes de fichiers, mettre en veille les applications pour une capture cohérente avec les applications, coordonner le suivi des blocs modifiés (CBT) et les sauvegardes des journaux de transactions, et orchestrer les installations basées sur les applications. La protection sans agent est utilisée pour les VM VMware (via les API vSphere Storage – Data Protection) et les instances Compute Engine (via les instantanés de disque persistant).

Pools de stockage sur un appareil de sauvegarde/restauration

Un dispositif de sauvegarde/récupération organise et stocke les données de sauvegarde capturées dans un maximum de quatre types de pools de stockage :

  • Pool principal : stockage de blocs associé directement à l'appareil de sauvegarde/récupération (à l'aide de disques persistants standards ou SSD) qui stocke les sauvegardes capturées et les données dédupliquées pour une récupération locale rapide et un montage instantané.
  • Pool d'instantanés : stockage qui utilise des instantanés de disque persistant pour stocker des copies ponctuelles de volumes de données pour des opérations de capture et d'installation hautes performances.
  • Pool OnVault : stockage basé sur des objets pour la conservation à long terme qui envoie des données de sauvegarde compressées et incrémentielles à un bucket Cloud Storage (Standard, Nearline, Coldline ou Archive) ou à un coffre de sauvegarde géré par Google.
  • Pool de miroirs : stockage de blocs sur un dispositif de sauvegarde/récupération secondaire dans une autre zone ou région qui reçoit des sauvegardes répliquées asynchrones au niveau des blocs (StreamSnap) pour la reprise après sinistre.

Modèles, règles et profils de ressources de sauvegarde

Dans la console de gestion de l'appareil, vous protégez une charge de travail découverte en appliquant un plan de sauvegarde composé de deux éléments de base réutilisables :

  • Modèle de sauvegarde : définit comment et quand les données sont sauvegardées, conservées et répliquées. Chaque modèle de sauvegarde contient une ou plusieurs règles de sauvegarde qui contrôlent les planifications, les objectifs de point de récupération (RPO) et la conservation entre les niveaux :
    • Production vers instantané : capture les données de la charge de travail de production vers le pool principal ou d'instantanés local.
    • Instantané vers OnVault : copie les sauvegardes d'instantanés vers un pool OnVault dans Cloud Storage ou un coffre de sauvegarde pour une conservation à long terme.
    • OnVault vers OnVault : réplique les données entre les pools OnVault de différentes régions.
    • Production vers miroir (StreamSnap) : réplique les données d'instantané vers un pool miroir sur un dispositif de sauvegarde/récupération distant.
  • Profil de ressource : définit où les données de sauvegarde sont stockées en mappant les règles d'un modèle de sauvegarde sur des pools de stockage d'appareils de sauvegarde/récupération locaux, des pools OnVault et des appareils de réplication distants spécifiques.

Principales fonctionnalités de Backup and DR pour la console de gestion

Backup and DR pour la console de gestion offre les fonctionnalités suivantes pour la sauvegarde, la récupération et la gestion des données de copie d'entreprise :

  • Capture incrémentielle permanente : après une seule sauvegarde complète initiale d'une application ou d'une VM, les sauvegardes suivantes ne capturent que les blocs modifiés ou les deltas de la base de données. L'appareil de sauvegarde/récupération synthétise des images complètes virtuelles à un moment précis sans exécuter de sauvegardes complètes périodiques qui ont un impact sur les performances de production.
  • Protection de base de données cohérente avec les applications et récupération à un moment précis (PITR) : s'intègre de manière native aux API de base de données (telles qu'Oracle RMAN, SQL Server VSS et SAP HANA backint ou les instantanés de stockage) pour capturer des sauvegardes de base de données cohérentes avec les applications, ainsi que des sauvegardes planifiées des journaux de transactions, ce qui vous permet de récupérer des données à un moment précis.
  • Installation instantanée et copies virtuelles : au lieu d'attendre que des téraoctets de données de sauvegarde soient copiés dans l'espace de stockage de production avant de pouvoir démarrer une application, vous pouvez installer une image de sauvegarde directement depuis l'appareil de sauvegarde/récupération sur un hôte cible :
    • Montage standard : expose l'image de sauvegarde en tant que disque ou système de fichiers installé sur un hôte cible pour inspecter ou copier des fichiers individuels.
    • Montage Application-Aware : démarre instantanément une instance de base de données virtuelle directement à partir de l'image de sauvegarde installée sur un serveur de base de données cible, en effectuant éventuellement un roll-forward des journaux de transactions à un moment choisi.
    • Installer et migrer : restaure immédiatement le service via une installation instantanée tout en migrant les fichiers de données sous-jacents vers l'espace de stockage de production en arrière-plan, ce qui réduit les objectifs de temps de récupération (RTO).
    • LiveClone : crée une copie virtuelle indépendante et accessible en écriture d'une image de sauvegarde qui peut être actualisée à la demande ou selon une planification sans consommer l'intégralité de l'espace de stockage physique pour chaque clone.
  • Workflows de sauvegarde et de reprise après sinistre automatisés : les workflows de sauvegarde et de reprise après sinistre automatisent la création, l'actualisation et le masquage des LiveClones et des bases de données virtuelles de manière planifiée ou à la demande. Les équipes de développement, d'assurance qualité et d'analyse peuvent provisionner elles-mêmes des copies à jour des bases de données de production, les données sensibles étant automatiquement nettoyées par des scripts personnalisés.
  • Reprise après sinistre interrégionale : répliquez les images de sauvegarde de manière asynchrone vers un appareil de sauvegarde/récupération secondaire dans une autre région à l'aide de la réplication StreamSnap, ou copiez les sauvegardes dans des buckets Cloud Storage et des coffres de sauvegarde multirégionaux ou birégionaux afin de pouvoir récupérer les charges de travail dans une autre région en cas de panne.

Charges de travail compatibles avec Backup and DR pour la console de gestion

Backup and DR pour la console de gestion protège un large éventail de machines virtuelles, de systèmes de fichiers et de bases de données. Pour en savoir plus sur la compatibilité des versions et des systèmes d'exploitation, consultez la matrice de compatibilité pour les sauvegardes gérées par l'appareil et les systèmes d'exploitation et noyaux compatibles avec Backup and DR.

  • Instances Compute Engine : protection par instantané sans agent et cohérente en cas de panne, et récupération inter-projets ou inter-régions pour les VM Compute Engine.
  • VM Google Cloud VMware Engine et VMware vSphere : sauvegarde sans agent au niveau de la VM, installation instantanée, LiveClone et récupération complète de VM pour les hôtes vCenter et ESX à l'aide du suivi des blocs modifiés (CBT) de VMware.
  • Systèmes de fichiers et Filestore : sauvegarde basée sur des blocs et des fichiers, et installation instantanée pour les systèmes de fichiers Linux et Windows, les partages NFS, les partages SMB/CIFS et les instances Filestore.
  • Bases de données Oracle : protection incrémentielle permanente à l'aide de copies d'images Oracle RMAN et du suivi des modifications, sauvegardes des journaux d'archive pour la récupération à un moment précis, installations instantanées de bases de données virtuelles, et installation et migration.
  • Bases de données Microsoft SQL Server : sauvegardes cohérentes avec les applications pour les instances autonomes et les groupes de disponibilité Always On, sauvegardes des journaux de transactions, installations de bases de données virtuelles et clonage de bases de données.
  • Bases de données SAP HANA : protection au niveau du volume (instantané de disque persistant ou LVM) et au niveau du fichier (backint) pour les systèmes à hôte unique, 1+n et SAP HANA à scaling horizontal.
  • Bases de données IBM Db2 : sauvegardes incrémentielles permanentes au niveau du volume et sauvegardes de vidage complètes et incrémentielles avec capture des journaux de transactions et installations de bases de données virtuelles.
  • Autres bases de données autogérées : protection des bases de données PostgreSQL, MySQL, MariaDB, SAP ASE, SAP IQ et SAP MaxDB, ainsi que des groupes de cohérence et des applications LVM génériques.

Étapes suivantes