Le service Backup and DR permet de sauvegarder les instances Cloud SQL et Compute Engine, ainsi que les disques individuels depuis la console Google Cloud . Les procédures de sauvegarde et de restauration de ces ressources sont disponibles dans la documentation de la console Google Cloud . Si toutes vos charges de travail appartiennent à ces catégories, vous n'avez pas besoin d'appliance de sauvegarde/récupération.
Le service Backup and DR permet également de sauvegarder 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. Ces sauvegardes nécessitent une console de gestion Backup and DR et un ou plusieurs appareils de sauvegarde/restauration. 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. La procédure de configuration consiste à créer un serveur de gestion, à déployer des appliances, puis à utiliser la console de gestion Backup and DR pour configurer les plannings de sauvegarde et définir les éléments à sauvegarder et leur emplacement.
Cette page explique comment effectuer l'activation initiale du service Backup and DR et configurer votre projet.
Avant de commencer
Nous vous recommandons de consulter les Considérations sur le déploiement d'appliances de sauvegarde/récupération avant de planifier le déploiement de vos appliances de sauvegarde/récupération.
Composants de l'architecture de l'appliance de sauvegarde/restauration
L'architecture du service de sauvegarde et de reprise après sinistre est fournie par les composants suivants :
Google Cloud console : la console Google Cloud Google Cloud inclut le produit Backup and DR pour la gestion centralisée de vos sauvegardes mises en coffre-fort de disques persistants, des plans de sauvegarde pour les instances Compute Engine et des sauvegardes améliorées pour Cloud SQL dans ces produits.
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/récupération. 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 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 continue, et fournit la reconnaissance 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.
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 Google Cloud Backup and DR
Types d'appareils de sauvegarde/récupération
Le service Backup and DR propose 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 que l'appliance de sauvegarde/récupération est en service, elle fonctionne 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 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. Cet appareil ajoute 4 To de capacité de disque équilibrée lors du déploiement. Vous pouvez ajouter 63 disques de 4 To supplémentaires. Cet appareil 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 les instances Compute Engine, les instances Cloud SQL et les 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'appliance 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,ainsi que des applications de données basées sur des disques persistants.
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 les bases de données, les VM VMware et d'autres ressources. Cet appareil 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. Vous pouvez ajouter 63 disques de 4 To supplémentaires des types suivants :
- 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'une appliance et projectid à l'ID de votre projet Google Cloud .
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
Configurations de pare-feu
Les règles de pare-feu requises suivantes pour le trafic entrant vers le service Backup and DR sont automatiquement ajoutées.
| 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'appliance de sauvegarde/récupération | *.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 Google Cloud 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 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 |
 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 | ||
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 | ||
europe-west9 |
Paris |
Faibles émissions de CO2
|
|
europe-west10 |
Berlin | ||
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 appliances de sauvegarde/restauration peuvent être déployées 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.