Cette page explique comment effectuer l'activation initiale du service de sauvegarde et de reprise après sinistre, et configurer les configurations de votre projet.
Composants de l'architecture de sauvegarde et de reprise après sinistre
L'architecture du service de sauvegarde et de reprise après sinistre est fournie via les composants suivants:
Console de gestion: la console de gestion sert de plan de gestion à vos dispositifs de sauvegarde/restauration. Chaque déploiement de sauvegarde et de reprise après sinistre comprend une console de gestion unique 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 garantit la résilience en cas de pannes zonales.
Appareils de sauvegarde/restauration: l'appareil de sauvegarde/restauration est un outil de transfert de données qui capture, déplace et gère efficacement le cycle de vie des données de sauvegarde dans votre entreprise. Les appareils de sauvegarde/restauration sont déployés 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 fournit la connaissance de l'application au moment de la récupération. L'agent est installé sur les hôtes d'application où se trouvent les applications à protéger. Si vous ne protégez que l'ensemble de la VM ou un sous-ensemble de ses disques, l'agent de sauvegarde et de DR n'est pas nécessaire.
La console de gestion est activée dans un réseau VPC de producteur de services. Le VPC de ce producteur de services communique avec votre projet à l'aide de l'accès Google privé.
Observations relatives à la mise en œuvre
Vous trouverez ci-dessous 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 vous permet de gérer les sauvegardes de toutes vos charges de travail dans tous vos secteurs d'activité à partir d'une seule console de gestion. Il peut s'agir d'un moyen plus efficace de gérer les sauvegardes, car vous n'avez qu'à gérer une seule console de gestion.
- La gestion décentralisée des sauvegardes signifie que vous disposez d'une console de gestion distincte pour chaque secteur 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 préparation à la reprise après sinistre en cas de sinistre dans une région de production, ou suffit-il de protéger vos données localement ? Si vous avez besoin de fonctionnalités de reprise après sinistre, vous devez envisager des sauvegardes interrégionales. Cela signifie que vous devez stocker vos sauvegardes à plusieurs endroits afin que, si un emplacement est affecté par un sinistre, vos données restent 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 (DR)
Pour des performances optimales et des coûts réduits, déployez la console de gestion et les appareils de sauvegarde/restauration dans la même région que vos charges de travail. 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 stocker les sauvegardes dans une autre région ou utiliser un stockage birégional ou multirégional. Le stockage des sauvegardes dans une région différente entraîne des frais de réseau et de stockage.
Si vous avez besoin à la fois de sauvegarde et de reprise après sinistre
Pour des performances plus rapides et des coûts réduits, déployez une console de gestion dans la même région que celle de la 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 appareils de sauvegarde/restauration dans la région de la 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 des 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 de panne de la région de production.
Les charges de travail se trouvent dans plusieurs régions
La meilleure stratégie de sauvegarde pour toutes les régions dépend de vos besoins.
Si vous n'avez pas besoin de reprise après sinistre (DR)
Pour des performances optimales et des coûts réduits, déployez la console de gestion dans l'une des régions où vos charges de travail s'exécutent. 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 s'exécutent. 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 stocker les sauvegardes dans une autre région ou utiliser un stockage birégional ou multirégional. Le stockage de sauvegardes dans une région ou un emplacement multirégional entraîne des frais de réseau et de stockage.
Si vous avez besoin à la fois de sauvegarde et de 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 appareils de sauvegarde/restauration dans les régions de charge de travail de production et dans la région de reprise après sinistre afin de minimiser l'objectif de temps de récupération (RTO). Cela garantit qu'un environnement de DR est entièrement préprovisionné et disponible en cas de sinistre.
Stockez les sauvegardes dans la région de la charge de travail 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 être utilisée pour répondre aux besoins de sauvegarde.
Une image de sauvegarde dans la reprise après sinistre peut être utilisée pour récupérer des 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 Service de sauvegarde et de reprise après sinistre, puis configurez les autorisations de votre compte:
Activer la sauvegarde et la reprise après sinistre Google Cloud
Types d'appareils de sauvegarde/restauration
Le service de sauvegarde et de reprise après sinistre 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 meilleur type d'appliance pour vos charges de travail. Une fois l'appliance de sauvegarde/récupération en service, elle s'exécute en continu, et est toujours prête à exécuter et à réexécuter des sauvegardes, des restaurations et d'autres tâches à tout moment.
Le service Backup and DR propose les types d'appliances suivants:
- Standard pour les VM Compute Engine ou les bases de données SAP HANA : sélectionnez cette option si vous ne souhaitez sauvegarder que des instances Compute Engine ou des bases de données SAP HANA à l'aide de disques persistants. Par défaut, cet appareil ajoute un type de machine e2-standard-4 avec une capacité minimale de disque persistant de 10 Go. Cet appareil peut gérer jusqu'à 5 000 VM Compute Engine.
- Standard pour les VM VMware et les 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 appareil ajoute un type de machine n2-standard-16. Cela ajoute 4 To de capacité de disque équilibrée en tant que capacité de disque minimale. Cet appareil peut gérer jusqu'à 1 500 applications.
Standard 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 compatible avec des performances modérées pour sauvegarder des bases de données, des VM VMware et d'autres ressources. Par défaut, cet appareil 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'appareil de sauvegarde/restauration.
- Disque persistant standard: sélectionnez ce type de stockage si vous souhaitez disposer d'un stockage de blocs efficace. Cette option est recommandée 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 en tant que capacité de disque minimale.
- Disque persistant SSD: sélectionnez ce type de stockage si vous souhaitez disposer d'un stockage en blocs rapide. Cette option est recommandée pour les applications Google Cloud VMware Engine, les bases de données ou les 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 en tant que capacité de disque minimale.
Lorsque vous déployez un appareil, un compte de service est créé automatiquement, quel que soit le type d'appareil. Vous pouvez afficher le compte de service sur la page Service account (Compte de service).
Le nom du compte de service apparaît au format d'adresse e-mail mon-compte-de-service@mon-projet.iam.gserviceaccount.com, où "nom-de-l'appareil" correspond au nom d'un appareil et "projectid" correspond à l'ID de votre projet Google Cloud .
Choisir un type de stockage
L'appareil de sauvegarde/restauration stocke les données de sauvegarde dans le pool d'instantanés de l'appareil local. Vous pouvez le copier dans le stockage d'objets pour le conserver à 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'appareil de sauvegarde/restauration.
Disque persistant standard: ce type de stockage offre un stockage de blocs efficace, à partir d'un disque persistant de 4 To. Cette option est recommandée pour les VM VMware Engine et les applications 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, à partir d'un disque persistant de 4 To. Cette option est recommandée pour les VM VMware Engine Google Cloudet les applications de base de données ou de système de fichiers avec un nombre très élevé d'E/S.
Vous pourrez augmenter la capacité de vos pools de disques ultérieurement.
Vous pouvez déplacer des sauvegardes avec des besoins de conservation à long terme vers les espaces de stockage standard, Nearline et Coldline de Google Cloud , en fonction de vos besoins d'accès aux données.
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 de sauvegarde et de reprise après sinistre. Un VPC partagé permet à une organisation de connecter des ressources provenant de différents projets à un réseau VPC (VPC) commun, afin que ces ressources puissent communiquer entre elles de manière sécurisée et efficace à l'aide des 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 réseau 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 de producteur de services. Ce VPC de producteur de services communique avec votre projet à l'aide de l'accès privé à Google. L'objectif principal de cette connexion est d'échanger des métadonnées entre la console de gestion et les appliances de sauvegarde/restauration. Le trafic de sauvegarde ne traverse pas ce lien. Toutefois, une console de gestion doit communiquer avec tous les appareils de sauvegarde/restauration déployés sur un réseau.
Bonnes pratiques concernant les VPC partagés
Les bonnes pratiques suivantes sont recommandées:
Se connecter à la console de gestion: nous vous recommandons de connecter le réseau du fournisseur de services à un VPC partagé de votre réseau. Tout le trafic provenant de la console de gestion passe par ce VPC et, par conséquent, par le projet hôte. Le provisionnement de la connectivité au service de sauvegarde et de reprise après sinistre via un VPC partagé permet également de connecter facilement les projets où les charges de travail s'exécutent (projets de service) au service de sauvegarde et de reprise après sinistre.
Emplacement de l'appareil de sauvegarde/restauration: les appareils de sauvegarde/restauration doivent être déployés dans un sous-réseau sur lequel l'accès privé à Google est activé pour la connectivité à la console de gestion. Nous recommandons deux stratégies pour sélectionner les projets des appareils de sauvegarde/restauration:
Dans le projet hôte central: dans cette stratégie, le service Backup and DR est traité comme un service central de l'IT. L'équipe de sauvegarde centrale gère 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ù des projets de service sont créés et leur gestion est déléguée à des équipes distribuées. Dans ce scénario, il est recommandé de provisionner un VPC pour les projets de service en aval. Les appareils de sauvegarde/restauration sont installés dans les projets de service de ces VPC. Cela permet de colocaliser la charge de travail et l'appareil 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 appareil de sauvegarde/restauration. Cela garantit que l'appli de sauvegarde/restauration peut communiquer avec des API telles que Compute Engine, Cloud Storage et Cloud Logging, ce qui est important pour que la surveillance et les alertes fonctionnent. 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écapitulatif des options de configuration. Configurez également les règles de pare-feu des appareils de sauvegarde/restauration pour autoriser les connexions à la plage CIDR199.36.153.8/30sur le port TCP443.
Configurations de pare-feu
Les règles de pare-feu requises suivantes pour l'accès au service de sauvegarde et de reprise après sinistre sont automatiquement ajoutées.
| Objectif | Source | Cible | Port (TCP) |
|---|---|---|---|
| Trafic d'assistance (assistance à l'appareil) | Hôte exécutant le client SSH | Appareil de sauvegarde/restauration | 26 |
| Sauvegarde iSCSI (hôte vers appareil) | Hôte exécutant l'agent Backup and DR | Appareil de sauvegarde/restauration | 3260 |
| Trafic StreamSnap (appareil à appareil) | Appareil de sauvegarde/restauration | Appareil de sauvegarde/restauration | 5107 |
| Connectivité de l'appareil de sauvegarde/restauration à la console de gestion | Adresse IP ou sous-réseau de l'appareil de sauvegarde/récupération | *.backupdr.googleusercontent.com | 443 |
Pour en savoir plus sur la configuration de cette règle, consultez la section Préparer le déploiement du service Backup and DR.
Pour chaque hôte exécutant l'agent de sauvegarde et de 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 (appareil vers hôte) | Appareil de sauvegarde/restauration | Hôte exécutant l'agent Backup and DR | 5106 |
Pour les hôtes qui utilisent NFS pour le trafic de sauvegarde ou pour les hôtes ESX exécutés dans VMware Engine qui utilisent 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 l'installation | Appareil de sauvegarde/restauration | 111, 756, 2049, 4001, 4045 |
Pour obtenir la liste des autorisations utilisées lors de cette opération, consultez la documentation de référence sur les autorisations d'installation de sauvegarde et de DR.
Régions où le service est disponible
La section suivante liste les régions compatibles avec la console de gestion et les appareils de sauvegarde/restauration.
Régions où la console de gestion est disponible
Bien que le service de sauvegarde et de reprise après sinistre 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. Notez que vous ne pouvez pas déplacer la console de gestion vers une autre région.
| Zone géographique | Nom de la région | Description de la région | |
|---|---|---|---|
| Amériques | |||
us-central1 |
Iowa |
 Faibles émissions de CO2
|
|
us-east1 |
Caroline du Sud | ||
us-east4 |
Virginie du Nord | ||
us-east5 |
Columbus | ||
us-west1 |
Oregon |
Faibles émissions de CO2 |
|
us-west2 |
Los Angeles | ||
us-west4 |
Las Vegas | ||
southamerica-east1 |
São Paulo |
Faibles émissions de CO2
|
|
| Europe | |||
europe-west1 |
Belgique |
Faibles émissions de CO2
|
|
europe-west2 |
Londres |
Faibles émissions de CO2
|
|
europe-west3 |
Francfort |
Faibles émissions de CO2
|
|
europe-west4 |
Pays-Bas |
Faibles émissions de CO2
|
|
| Asie-Pacifique | |||
asia-east1 |
Taïwan | ||
asia-southeast1 |
Singapour | ||
australia-southeast1 |
Sydney | ||
| Inde | |||
asia-south1 |
Mumbai | ||
asia-south2 |
Delhi |
Régions compatibles avec les appareils de sauvegarde/restauration
Les appliances de sauvegarde/restauration du service de sauvegarde et de reprise après sinistre peuvent être déployées dans n'importe quelle zone .
Le service de workflow permettant d'effectuer le déploiement de l'appliance de sauvegarde/récupération est compatible avec les régions listées. Si le service de workflow n'est pas disponible dans la région où votre appareil de sauvegarde/restauration est déployé, le service de sauvegarde et de reprise après sinistre exécute par défaut le workflow dans la région us-central1 (l'appareil lui-même est toujours créé dans la région sélectionnée). Si une règle d'administration est définie pour empêcher la création de ressources dans d'autres régions, vous devez temporairement mettre à jour votre règle d'administration 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.