Backup and DR permet de sauvegarder des instances Cloud SQL, des clusters AlloyDB, des instances Compute Engine et des disques individuels depuis la consoleGoogle Cloud . Les procédures de sauvegarde et de restauration de ces ressources sont disponibles dans leur documentation. Si toutes vos charges de travail entrent dans ces catégories, vous n'avez pas besoin d'un appareil de sauvegarde/récupération.
La sauvegarde et la reprise après sinistre pour les VM VMware et les bases de données SAP HANA, IBM Db2, Oracle et Microsoft SQL Server qui s'exécutent dans des instances Compute Engine nécessitent une console de gestion de l'appareil Backup and DR et un ou plusieurs appareils de sauvegarde/récupération. Lorsque vous utilisez cette configuration, vous devez choisir la taille de vos appliances de sauvegarde/récupération en fonction des applications que vous sauvegardez. Le flux de cette configuration implique de créer un serveur de gestion, de déployer des appliances, puis d'utiliser la console de gestion des appliances pour configurer les planifications de sauvegarde et définir ce qui est sauvegardé et où.
Pour obtenir un aperçu des stratégies permettant d'optimiser l'utilisation de vos appliances de sauvegarde/récupération, consultez Considérations sur le déploiement des appliances de sauvegarde/récupération.
Cette page explique comment activer Backup and DR pour la première fois et configurer votre projet.
Composants de l'architecture de l'appareil de sauvegarde/restauration
L'architecture de Backup and DR est fournie via les composants suivants :
ConsoleGoogle Cloud : la console Google Cloud inclut le produit Backup and DR pour la gestion centralisée de vos sauvegardes protégées Persistent Disk, des plans de sauvegarde pour les instances Compute Engine et de la sauvegarde améliorée pour Cloud SQL dans ces produits.
Console de gestion des dispositifs : la console de gestion des dispositifs sert de plan de gestion pour vos dispositifs de sauvegarde/récupération. Chaque déploiement Backup and DR inclut une seule console de gestion des appliances qui gère un nombre illimité d'appliances de sauvegarde/récupération. La console de gestion de l'appliance 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 assure une résilience contre les pannes zonales.
Appareils de sauvegarde/restauration : l'appareil de sauvegarde/restauration est l'outil de transfert de données qui capture, déplace et gère efficacement le cycle de vie des données de sauvegarde au sein de votre entreprise. Les appareils de sauvegarde/restauration sont déployés dans l'entité de charge de travail pour les charges de travail cloud. Si vous déployez plusieurs appliances de sauvegarde/récupération, chacune d'elles doit être associée à un compte de service unique.
Agents Backup and DR : l'agent Backup and DR appelle les API natives de l'application pour capturer efficacement les données des applications de production de manière incrémentielle et fournit l'Application Awareness 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 nécessaire.
La console de gestion de l'appareil 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.
Configurer Backup and DR dans la console Google Cloud
Accédez à la console Google Cloud pour activer l'API backupdr et configurer les autorisations pour votre compte :
Activer Google Cloud Backup and DR
Types d'appareils de sauvegarde/restauration
Backup and DR fournit des types de dispositifs 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'appareil le mieux adapté à vos charges de travail. Une fois l'appareil de sauvegarde/récupération en service, il s'exécute en continu, toujours prêt à exécuter et à réexécuter des tâches de sauvegarde, de restauration et d'autres tâches à tout moment.
Backup and DR propose les types d'appareils suivants :
- Standard pour les VM VMware et d'autres bases de données ou ressources : ce type de machine n2-standard-16 offre des performances optimales pour sauvegarder les bases de données de production, les VM VMware et d'autres ressources. Cette appliance ajoute 4 To de capacité de disque équilibré lors du déploiement, et vous pouvez ajouter 63 disques supplémentaires de 4 To. Cette appliance peut gérer jusqu'à 1 500 applications et 5 000 instantanés quotidiens.
- Standard pour les VM Compute Engine ou les bases de données SAP HANA : ce type de machine e2-standard-4 est idéal pour sauvegarder des instances Compute Engine, des instances Cloud SQL, des clusters AlloyDB et des ressources de données qui utilisent Persistent Disk pour les sauvegardes : bases de données IBM Db2 et SAP HANA configurées pour utiliser Persistent Disk. Ce type d'appareil dispose d'une capacité de disque persistant minimale de 10 Go. Cette appliance peut gérer jusqu'à 5 000 instances Compute Engine et Cloud SQL, clusters AlloyDB et applications de données basées sur Persistent Disk.
De base pour les VM VMware et d'autres bases de données ou ressources : ce type de machine e2-standard-16 offre des performances modérées pour sauvegarder des bases de données, des VM VMware et d'autres ressources. Cette appliance peut gérer jusqu'à 1 500 applications et 5 000 instantanés quotidiens. Cet appareil ajoute 4 To de capacité de disque standard lors du déploiement, et vous pouvez ajouter 63 disques supplémentaires de 4 To des types suivants :
- Disque persistant de capacité minimale : cette option fournit 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 de blocs rapide. Ce type est recommandé pour Google Cloud VMware Engine, les bases de données ou les applications de système 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 Compte de service.
Le nom du compte de service s'affiche au format d'adresse e-mail :
APPLIANCE_NAME@PROJECT_ID.iam.gserviceaccount.com
Remplacez les éléments suivants :
- APPLIANCE_NAME : nom de votre appareil de sauvegarde/récupération.
- PROJECT_ID : ID de votre projet Google Cloud (source).
Vous pouvez déplacer les sauvegardes nécessitant une conservation à long terme vers les classes de stockage Standard, Nearline et Coldline, en fonction de la fréquence d'accès prévue aux données.
Configurations de pare-feu
Les règles de pare-feu requises suivantes pour l'entrée dans Backup and DR sont ajoutées automatiquement.
| Objectif | Source | Cible | Port (TCP) |
|---|---|---|---|
| Trafic d'assistance (assistance vers l'appareil) | SSH_CLIENT_IP | Appareil de sauvegarde/restauration | 26 |
| Sauvegarde iSCSI (hôte vers l'appareil) | AGENT_HOST_IP | Appareil de sauvegarde/restauration | 3260 |
| Trafic StreamSnap (d'appareil à appareil) | SOURCE_APPLIANCE_IP | Appareil de sauvegarde/restauration | 5107 |
| Connectivité de l'appareil de sauvegarde/restauration à la console de gestion de l'appareil | APPLIANCE_IP | *.backupdr.googleusercontent.com | 443 |
Remplacez les éléments suivants :
- SSH_CLIENT_IP : adresse IP de l'hôte exécutant le client SSH.
- AGENT_HOST_IP : adresse IP de l'hôte exécutant l'agent Backup and DR.
- SOURCE_APPLIANCE_IP : adresse IP de l'appareil source.
- APPLIANCE_IP : adresse IP ou sous-réseau de l'appareil de sauvegarde/restauration.
Pour en savoir plus sur la configuration de cette règle, consultez Se préparer à déployer 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 (appareil vers 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 Google Cloud VMware Engine qui utilisent NFS pour les installations, 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 Backup and DR.
Régions où le service est disponible
La section suivante liste les régions prises en charge par la console de gestion des appliances et les appliances de sauvegarde/récupération.
Régions prises en charge par la console de gestion des dispositifs
Bien que Backup and DR puisse être utilisé pour sauvegarder des charges de travail compatibles dans n'importe quelle régionGoogle Cloud , la console de gestion des appliances 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 |
 Faibles émissions de CO2
|
|
northamerica-northeast2 |
Toronto |
Faibles émissions de CO2
|
|
us-central1 |
Iowa |
Faibles émissions de CO2
|
|
us-east1 |
Caroline du Sud | ||
us-east4 |
Virginie du Nord | ||
us-east5 |
Columbus | ||
us-south1 |
Dallas |
Faibles émissions de CO2
|
|
us-west1 |
Oregon |
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 |
Faibles émissions de CO2
|
|
southamerica-west1 |
Santiago |
Faibles émissions de CO2
|
|
| Europe | |||
europe-central2 |
Varsovie |
Faibles émissions de CO2
|
|
europe-north1 |
Finlande |
Faibles émissions de CO2
|
|
europe-north2 |
Stockholm |
Faibles émissions de CO2
|
|
europe-southwest1 |
Madrid |
Faibles émissions de CO2
|
|
europe-west1 |
Belgique |
Faibles émissions de CO2
|
|
europe-west2 |
Londres |
Faibles émissions de CO2
|
|
europe-west3 |
Francfort | ||
europe-west4 |
Pays-Bas |
Faibles émissions de CO2
|
|
europe-west6 |
Zurich |
Faibles émissions de CO2
|
|
europe-west8 |
Milan |
Faibles émissions de CO2
|
|
europe-west9 |
Paris |
Faibles émissions de CO2
|
|
europe-west10 |
Berlin | ||
europe-west12 |
Turin |
Faibles émissions de CO2
|
|
| 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 (northamerica-south1), Montréal (northamerica-northeast1) et Osaka (asia-northeast2) ne sont pas compatibles avec la séparation entre zones. Cela signifie que les différentes zones de chacune de ces régions peuvent ne pas être situées dans des campus de centres de données physiquement distincts. Par conséquent, un seul sinistre physique localisé pourrait potentiellement affecter plusieurs zones d'une même région, ce qui augmente le risque de perte de données par rapport aux régions qui acceptent la séparation entre zones.
Régions prises en charge par les dispositifs de sauvegarde/récupération
Les appliances de sauvegarde/récupération peuvent être déployées dans n'importe quelle zoneGoogle Cloud .
Le service de workflow permettant de déployer l'appareil de sauvegarde/récupération est compatible avec les régions listées. Si le service Workflow n'est pas disponible dans une région où votre appareil de sauvegarde/récupération est déployé, Backup and DR 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 que vous avez sélectionnée). Si vous avez défini une règle d'administration pour empêcher 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 restreindre la région us-central1 après le déploiement de l'appareil de sauvegarde/restauration.