Configurer et planifier un déploiement du service Backup and DR

Cette page explique comment effectuer l'activation initiale du service Backup and DR et configurer votre projet.

Composants de l'architecture Backup and DR

L'architecture du service de sauvegarde et de reprise après sinistre est fournie par les composants suivants :

  • Console de gestion : la console de gestion sert de plan de gestion pour vos dispositifs de sauvegarde/restauration. Chaque déploiement Backup and DR inclut une seule console de gestion qui gère un nombre illimité d'appliances de sauvegarde/restauration. La console de gestion est déployée dans le projet d'administration des sauvegardes et est disponibilité élevée dans la région déployée, ce qui offre une résilience contre les pannes zonales.

  • Appareils de sauvegarde/restauration : l'appareil de sauvegarde/restauration est le moteur de déplacement des données qui capture, déplace et gère efficacement le cycle de vie des données de sauvegarde dans votre entreprise. Les appliances de sauvegarde/restauration sont déployées dans l'entité de charge de travail pour les charges de travail cloud.

  • Agents de sauvegarde et de reprise après sinistre : l'agent de sauvegarde et de reprise après sinistre appelle les API natives de l'application pour capturer efficacement les données des applications de production de manière incrémentielle et continue, et fournit la connaissance de l'application au moment de la récupération. L'agent est installé sur les hôtes d'application où résident les applications à protéger. Si vous ne protégez que l'intégralité de la VM ou un sous-ensemble de ses disques, l'agent Backup and DR n'est pas requis.

La console de gestion est activée dans un réseau VPC producteur de services. Ce VPC de producteur de services communique avec votre projet à l'aide de l'accès privé à Google.

La communication entre le serveur de gestion et les appliances, entre les appliances, et entre les appliances et les agents hôtes est sécurisée par l'authentification TLS mutuelle.

Observations relatives à la mise en œuvre

Voici quelques considérations importantes qui affectent la façon dont vous déployez le service Backup and DR :

  • Quelles sont les exigences de votre organisation en termes d'objectif de temps de récupération (RTO) ? Le RTO correspond à la durée maximale pendant laquelle vous pouvez vous passer de vos données. Par exemple, si votre RTO est de quatre heures,vous devez pouvoir accéder à vos données dans les quatre heures suivant un sinistre.

  • Avez-vous besoin de centraliser la gestion de vos sauvegardes ? Vous devez décider si vous souhaitez gérer vos sauvegardes de manière centralisée ou non.

    • La gestion centralisée des sauvegardes signifie que vous disposez d'une seule console de gestion pour gérer les sauvegardes de toutes vos charges de travail dans tous les secteurs d'activité. Cela peut être un moyen plus efficace de gérer les sauvegardes, car vous n'avez besoin de gérer qu'une seule console d'administration.
    • La gestion décentralisée des sauvegardes signifie que vous disposez d'une console de gestion distincte pour chaque branche d'activité. Le mode de fonctionnement varie d'une organisation à l'autre.
  • Quel est votre cas d'utilisation de la sauvegarde ? Avez-vous besoin de sauvegardes pour la reprise après sinistre en cas de catastrophe dans une région de production, ou est-il suffisant de protéger vos données localement ? Si vous avez besoin d'une fonctionnalité de reprise après sinistre, vous devez envisager les sauvegardes interrégionales. Cela signifie que vous devez stocker vos sauvegardes à plusieurs endroits. Ainsi, si un sinistre touche l'un de ces emplacements, vos données resteront accessibles.

Les charges de travail se trouvent dans une seule région.

La meilleure stratégie de sauvegarde dans une région dépend de vos besoins.

Si vous n'avez pas besoin de reprise après sinistre

Pour optimiser les performances et réduire les coûts, déployez la console de gestion et les dispositifs de sauvegarde/restauration dans la même région que celle où vos charges de travail sont exécutées. Stockez vos images de sauvegarde dans la même région que vos charges de travail.

Si vous souhaitez également disposer de copies de sauvegarde hors site, vous pouvez les stocker dans une autre région ou utiliser le stockage birégional ou multirégional. Le stockage des sauvegardes dans une autre région entraîne des frais de réseau et de stockage.

Si vous avez besoin à la fois d'une sauvegarde et d'une reprise après sinistre

Pour optimiser les performances et réduire les coûts, déployez une console de gestion dans la même région que la région de charge de travail de production, et une deuxième console de gestion dans la région que vous pouvez utiliser pour la reprise après sinistre.

Déployez des appliances de sauvegarde/restauration dans la région de charge de travail de production et dans la région de reprise après sinistre pour minimiser l'objectif de temps de récupération (RTO). Cela permet de s'assurer qu'un environnement de reprise après sinistre est entièrement préprovisionné et disponible en cas de sinistre.

Stockez les images de sauvegarde dans la région de production et une copie dans la région de reprise après sinistre, ou utilisez un stockage birégional ou multirégional. La copie de sauvegarde de la région de production peut répondre aux besoins de sauvegarde de routine avec des performances plus rapides. Les données copiées dans votre région de reprise après sinistre peuvent être utilisées pour récupérer vos charges de travail en cas d'indisponibilité de la région de production.

Les charges de travail se trouvent dans plusieurs régions.

La meilleure stratégie de sauvegarde multirégionale dépend de vos besoins.

L'accès aux coffres de sauvegarde multirégionaux n'est disponible que sur invitation. Si vous souhaitez demander l'accès aux coffres-forts de sauvegarde multirégionaux dans votre projet Google Cloud, contactez votre conseiller commercial.

Si vous n'avez pas besoin de reprise après sinistre

Pour optimiser les performances et réduire les coûts, déployez la console de gestion dans l'une des régions où vos charges de travail sont exécutées. Cela permet une gestion centralisée de toutes les charges de travail et régions.

Déployez un ou plusieurs appareils de sauvegarde/récupération dans chaque région où les charges de travail sont exécutées. Stockez vos sauvegardes dans la même région que vos charges de travail.

Si vous souhaitez également disposer de copies de sauvegarde hors site, vous pouvez les stocker dans une autre région ou utiliser le stockage birégional ou multirégional. Le stockage des sauvegardes dans une région ou une multirégion différente entraîne des frais de réseau et de stockage.

Si vous avez besoin à la fois d'une sauvegarde et d'une reprise après sinistre

Déployez une console de gestion dans chacune des régions de charge de travail de production et une autre console de gestion dans la région de reprise après sinistre.

Déployez des appliances de sauvegarde/restauration dans les régions de charge de travail de production et dans la région de reprise après sinistre pour minimiser l'objectif de temps de récupération (RTO). Cela garantit qu'un environnement de reprise après sinistre est entièrement préprovisionné et disponible en cas de sinistre.

Stockez les sauvegardes dans la région de charge de travail de production et une copie dans la région de reprise après sinistre, ou utilisez le stockage birégional ou multirégional. La copie de sauvegarde de la région de production peut être utilisée pour répondre aux besoins de sauvegarde.

Une image de sauvegarde dans la région de reprise après sinistre peut être utilisée pour récupérer les charges de travail si la région de production est indisponible.

Configurer le service Backup and DR dans la console Google Cloud

Accédez à la console Google Cloud pour activer l'API Backup and DR Service et configurer les autorisations pour votre compte :

Activer la sauvegarde et la reprise après sinistre Google Cloud

Types d'appareils de sauvegarde/récupération

Le service Backup and DR fournit des types d'appliances optimisés pour différentes charges de travail : VM Compute Engine, VM VMware, bases de données et systèmes de fichiers. Vous pouvez choisir le type d'appareil qui répond le mieux à vos besoins. Il est important de sélectionner le type d'appliance le mieux adapté à vos charges de travail. Une fois l'appliance de sauvegarde/récupération en service, elle s'exécute en continu, toujours prête à exécuter et à réexécuter des tâches de sauvegarde, de restauration et autres à tout moment.

Le service Backup and DR propose les types d'appliance suivants :

  • Standard pour les VM Compute Engine ou les bases de données SAP HANA : sélectionnez cette option si vous souhaitez sauvegarder uniquement les instances Compute Engine ou les bases de données SAP HANA à l'aide d'un disque persistant. Par défaut, cet appliance ajoute un type de machine e2-standard-4 avec une capacité de disque persistant minimale de 10 Go. Cet appliance peut gérer jusqu'à 5 000 VM Compute Engine.
  • Standard pour les VM VMware et autres bases de données ou ressources : sélectionnez cette option si vous souhaitez une configuration standard qui offre des performances optimales pour sauvegarder des bases de données, des VM VMware et d'autres ressources. Par défaut, cet appliance ajoute un type de machine n2-standard-16. Cela ajoute 4 To de capacité de disque équilibrée comme capacité de disque minimale. Cet appareil peut gérer jusqu'à 1 500 applications.
  • De base pour les VM VMware et les autres bases de données ou ressources : sélectionnez cette option si vous souhaitez disposer d'une configuration de base qui offre des performances modérées pour sauvegarder les bases de données, les VM VMware et d'autres ressources. Par défaut, cet appliance ajoute un type de machine e2-standard-16. Cet appareil peut gérer jusqu'à 1 500 applications. Vous pouvez choisir l'un des types de disques suivants pour stocker vos données.

    • Disque persistant de capacité minimale : cette option offre une capacité de disque minimale de 10 Go. Dans ce type de stockage, les sauvegardes sont stockées sous forme d'instantanés de disque persistant et n'utilisent pas l'espace de stockage local de l'appliance de sauvegarde/restauration.
    • Disque persistant standard : sélectionnez ce type de stockage si vous souhaitez disposer d'un stockage de blocs efficace. Recommandé pour les VM Google Cloud VMware Engine, les bases de données ou les applications de système de fichiers avec un volume d'E/S moyen à élevé, ainsi que pour les VM Compute Engine. Cela ajoute 4 To de capacité de disque persistant comme capacité de disque minimale.
    • Disque persistant SSD : sélectionnez ce type de stockage si vous souhaitez disposer d'un stockage de blocs rapide. Recommandé pour les applications Google Cloud VMware Engine, de bases de données ou de systèmes de fichiers avec un nombre très élevé d'E/S, ainsi que pour les VM Compute Engine. Cela ajoute 4 To de capacité de disque persistant comme capacité de disque minimale.

Lorsque vous déployez une appliance, un compte de service est créé automatiquement, quel que soit le type d'appliance. Vous pouvez afficher le compte de service sur la page Compte de service.

Le nom du compte de service apparaît dans l'adresse e-mail au format my-service-account@my-project.iam.gserviceaccount.com, où appliance-name correspond au nom d'un appareil et projectid à l'ID de votre projet Google Cloud .

Choisir un type de stockage

L'appliance de sauvegarde/restauration stocke les données de sauvegarde dans le pool d'instantanés de l'appliance locale. Vous pouvez le copier dans un stockage d'objets pour une conservation à long terme.Google Cloud propose les trois types de stockage d'objets locaux suivants :

  • Disque persistant de capacité minimale : les images de sauvegarde sont stockées sous forme d'instantanés de disque persistant qui n'utilisent pas l'espace de stockage local de l'appliance de sauvegarde/restauration.

  • Disque persistant standard : ce type de stockage offre un stockage de blocs efficace, avec un disque persistant de 4 To minimum. Cette option est recommandée pour les applications VMware Engine et de base de données ou de système de fichiers avec un volume d'E/S moyen à élevé.

  • Disque persistant SSD : ce type de stockage offre un stockage de blocs rapide, avec un disque persistant de 4 To minimum. Recommandé pour les VM VMware Engine et les applications de base de données ou de système de fichiers avec un nombre très élevé d'E/S. Google Cloud

Vous pourrez augmenter la capacité de vos pools de disques par la suite.

Vous pouvez déplacer les sauvegardes nécessitant une conservation à long terme vers le stockage Standard, Nearline ou Coldline, en fonction de vos besoins d'accès aux données. Google Cloud

Topologie réseau recommandée pour le service Backup and DR

Google Cloud recommande d'utiliser un VPC partagé lors du déploiement du service Backup and DR. Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau VPC commun, afin que ces ressources puissent communiquer entre elles de manière sécurisée et efficace en utilisant les adresses IP internes de ce réseau. Lorsque vous utilisez un VPC partagé, vous désignez un projet en tant que projet hôte et vous lui associez un ou plusieurs projets de service. Les réseaux VPC du projet hôte sont appelés réseaux VPC partagés. Les ressources éligibles des projets de service peuvent utiliser des sous-réseaux du réseau VPC partagé.

Un VPC partagé permet aux administrateurs d'une organisation de déléguer des responsabilités administratives, comme la création et la gestion d'instances, à des administrateurs de projet de service tout en conservant un contrôle centralisé sur les ressources réseau, telles que les sous-réseaux, les routes et les pare-feu.

La console de gestion est activée dans un réseau VPC producteur de services. Le VPC de ce producteur de services communique avec votre projet à l'aide de l'accès privé à Google. L'objectif principal de cette connexion est de permettre à la console de gestion et aux appliances de sauvegarde/récupération d'échanger des métadonnées. Le trafic de sauvegarde ne transite pas par ce lien. Toutefois, une console de gestion doit communiquer avec tous les appareils de sauvegarde/restauration déployés sur n'importe quel réseau.

Bonnes pratiques pour le VPC partagé

Les bonnes pratiques suivantes sont recommandées :

  • Se connecter à la console de gestion : il est préférable de connecter le réseau du fournisseur de services à un VPC partagé au sein de votre réseau. Tout le trafic provenant de la console de gestion transite par ce VPC et, par conséquent, par le projet hôte. Le provisionnement de la connectivité au service Backup and DR via un VPC partagé permet également une connexion fluide entre les projets dans lesquels les charges de travail sont exécutées (projets de service) et le service Backup and DR.

  • Emplacement de l'appliance de sauvegarde/restauration : les appliances de sauvegarde/restauration doivent être déployées dans un sous-réseau sur lequel l'accès privé à Google est activé pour la connectivité à la console de gestion. Nous vous recommandons deux stratégies pour sélectionner les projets des appliances de sauvegarde/restauration :

    • Dans le projet hôte central : dans cette stratégie, le service Backup and DR est traité comme un service informatique central. L'équipe de sauvegarde centrale régit le provisionnement du service. Par conséquent, tous les dispositifs de sauvegarde/restauration sont provisionnés dans le projet hôte, ce qui permet aux administrateurs centraux de regrouper toutes les ressources de sauvegarde dans un projet central. Cette approche présente l'avantage de regrouper toutes les ressources liées aux sauvegardes et leur facturation dans un seul projet.

    • Dans les projets de service : cette stratégie convient aux équipes plus décentralisées où les projets de service sont créés et leur gestion est déléguée à des équipes distribuées. Dans ce scénario, la bonne pratique recommandée consiste à provisionner un VPC pour les projets de service en aval. Les appliances de sauvegarde/restauration sont installées dans les projets de service de ces VPC. Cela permet la colocation de la charge de travail et de l'appliance de sauvegarde/restauration dans un même projet.

    • Accès privé à Google : nous vous recommandons d'activer l'accès privé à Google pour chaque sous-réseau sur lequel vous installez un dispositif de sauvegarde/récupération. Cela permet de s'assurer que l'appliance de sauvegarde/récupération peut communiquer avec les API, telles que Compute Engine, Cloud Storage et Cloud Logging, ce qui est important pour le bon fonctionnement de la surveillance et des alertes. Pour simplifier et améliorer les connexions aux API Google Cloud , envisagez de configurer la résolution DNS pour private.googleapis.com, comme indiqué dans la section Résumé des options de configuration. Configurez également les règles de pare-feu des appliances de sauvegarde/récupération pour autoriser les connexions à la plage CIDR 199.36.153.8/30 sur le port TCP 443.

Configurations de pare-feu

Les règles de pare-feu requises suivantes pour le trafic entrant vers le service Backup and DR sont ajoutées automatiquement.

Objectif Source Cible Port (TCP)
Trafic d'assistance (assistance vers l'appliance) Hôte exécutant le client SSH Appareil de sauvegarde/restauration 26
Sauvegarde iSCSI (hôte vers appliance) Hôte exécutant l'agent Backup and DR Appareil de sauvegarde/restauration 3260
Trafic StreamSnap (d'un appareil à un autre) Appareil de sauvegarde/restauration Appareil de sauvegarde/restauration 5107
Connectivité de l'appliance de sauvegarde/restauration à la console de gestion Adresse IP ou sous-réseau de l'appareil de sauvegarde/restauration *.backupdr.googleusercontent.com 443

Pour en savoir plus sur la configuration de cette règle, consultez Préparer le déploiement du service Backup and DR.

Pour tout hôte exécutant l'agent Backup and DR, vous devez ajouter manuellement le port TCP suivant pour autoriser la connectivité avec une règle de pare-feu d'entrée.

Objectif Source Cible Port (TCP)
Trafic de l'agent (de l'appliance à l'hôte) Appareil de sauvegarde/restauration Hôte exécutant l'agent Backup and DR 5106

Pour les hôtes utilisant NFS pour le trafic de sauvegarde ou pour les hôtes ESX exécutés dans VMware Engine et utilisant NFS pour les montages, vous devez ajouter manuellement les ports TCP et UDP suivants pour autoriser la connectivité avec une règle de pare-feu d'entrée.

Objectif Source Cible Port (TCP/UDP)
Sauvegarde ou installation NFS Hôte exécutant l'agent ou hôte ESXi exécutant le montage Appareil de sauvegarde/restauration 111, 756, 2049, 4001, 4045

Pour obtenir la liste des autorisations utilisées lors de cette opération, consultez Documentation de référence sur les autorisations d'installation de la sauvegarde et de la reprise après sinistre.

Régions où le service est disponible

La section suivante liste les régions compatibles avec la console de gestion et les appliances de sauvegarde/restauration.

Régions compatibles avec la console de gestion

Bien que le service Backup and DR puisse être utilisé pour sauvegarder les charges de travail compatibles dans n'importe quelle régionGoogle Cloud , la console de gestion ne peut être activée que dans les régions suivantes :

Zone géographique Nom de la région Description de la région
Amérique du Nord
northamerica-northeast1 * Montréal Icône Feuille Faibles émissions de CO2
northamerica-northeast2 Toronto Icône Feuille Faibles émissions de CO2
us-central1 Iowa Icône Feuille Faibles émissions de CO2
us-east1 Caroline du Sud
us-east4 Virginie du Nord
us-east5 Columbus
us-south1 Dallas Icône Feuille Faibles émissions de CO2
us-west1 Oregon Icône Feuille Faibles émissions de CO2
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas
northamerica-south1 * Querétaro
Amérique du Sud
southamerica-east1 São Paulo Icône Feuille Faibles émissions de CO2
southamerica-west1 Santiago icône feuille Faibles émissions de CO2
Europe
europe-central2 Varsovie
europe-north1 Finlande Icône Feuille Faibles émissions de CO2
europe-southwest1 Madrid Icône Feuille Faibles émissions de CO2
europe-west1 Belgique Icône Feuille Faibles émissions de CO2
europe-west2 Londres icône feuille Faibles émissions de CO2
europe-west3 Francfort icône feuille Faibles émissions de CO2
europe-west4 Pays-Bas Icône Feuille Faibles émissions de CO2
europe-west6 Zurich Icône Feuille Faibles émissions de CO2
europe-west8 Milan
europe-west9 Paris Icône Feuille Faibles émissions de CO2
europe-west10 Berlin Icône Feuille Faibles émissions de CO2
europe-west12 Turin
Moyen-Orient
me-central1 Doha
me-central2 Dammam
me-west1 Israël
Afrique
africa-south1 Johannesburg
Asie-Pacifique
asia-east1 Taïwan
asia-east2 Hong Kong
asia-northeast1 Tokyo
asia-northeast2 * Osaka
asia-northeast3 Séoul
asia-southeast1 Singapour
asia-southeast2 Jakarta
australia-southeast1 Sydney
australia-southeast2 Melbourne
Inde
asia-south1 Mumbai
asia-south2 Delhi

* Querétaro, Montréal et Osaka comportent chacune trois zones hébergées dans un ou deux centres de données physiques. En cas de catastrophe (ce qui est rare), les données stockées dans ces régions peuvent être perdues.

Régions compatibles avec les appareils de sauvegarde/récupération

Des appareils de sauvegarde/restauration peuvent être déployés dans n'importe quelle zoneGoogle Cloud .

Le service de workflow permettant de déployer le dispositif de sauvegarde/récupération est disponible dans les régions listées. Si le service Workflow n'est pas disponible dans une région où votre appliance de sauvegarde/récupération est déployée, le service Backup and DR exécute le workflow par défaut dans la région us-central1 (l'appliance elle-même est toujours créée dans la région que vous avez sélectionnée). Si vous avez une règle d'administration qui empêche la création de ressources dans d'autres régions, vous devez la modifier temporairement pour autoriser la création de ressources dans la région us-central1. Vous pouvez limiter la région us-central1 après le déploiement de l'appliance de sauvegarde/restauration.

Étapes suivantes