Les SKU utilisés pour facturer les frais de stockage du service Backup and DR dépendent du type de stockage utilisé pour protéger la ressource : un coffre de sauvegarde ou un stockage autogéré.

Si une ressource est protégée dans un coffre de sauvegarde, les frais de stockage seront facturés au projet dans lequel le coffre de sauvegarde a été créé, en utilisant les SKU du service Backup and DR et les tarifs définis dans le tableau ci-dessous.

Si une ressource est protégée dans un espace de stockage autogéré (par exemple, un bucket Cloud Storage ou un instantané de disque persistant), les frais de stockage sont facturés à l'aide des SKU correspondants. Pour plus d'informations sur les tarifs de Cloud Storage, consultez la page Tarifs de Cloud Storage. Pour en savoir plus sur la tarification des instantanés de disque persistant, consultez la page Tarifs des instantanés de disque persistant dans le cloud.

Chaque projet Google Cloud est associé à un compte de facturation qui permet de déterminer qui paie l'utilisation des ressources et des API Google Cloud dans ce projet. Le projet et les SKU utilisés pour la facturation du service Backup and DR sont déterminés par le type de ressource protégée.

Protection indépendante des disques (Persistent Disk et Hyperdisk) dans un coffre-fort de sauvegarde (y compris la protection via Terraform et la CLI Google Cloud)

Les frais de gestion des disques (persistants ou Hyperdisk) sous protection active dans un coffre-fort de sauvegarde sont facturés au projet dans lequel se trouve le disque protégé. Le tableau suivant répertorie les SKU et les tarifs pour la protection des disques dans un coffre-fort de sauvegarde.

Protection des VM Compute Engine dans un coffre-fort de sauvegarde (y compris la protection via Terraform et Google Cloud CLI)

Les frais de gestion des VM sous protection active dans un coffre-fort de sauvegarde sont facturés au projet dans lequel se trouve la VM protégée. Le tableau suivant répertorie les SKU et les prix pour la protection dans un coffre-fort de sauvegarde.

Si une VM n'est plus protégée, mais que des données de sauvegarde sont présentes dans un coffre-fort de sauvegarde, les frais de gestion seront facturés comme indiqué ici.

Protection des VM Compute Engine dans le stockage autogéré

Les frais de gestion pour la protection dans le stockage autogéré sont facturés au projet dans lequel le service Backup and DR a été activé et à partir duquel la console de gestion a été déployée. Cela vaut quels que soient les zones, régions ou projets dans lesquels se trouvent les appliances de sauvegarde/restauration. Le tableau suivant répertorie les SKU et les prix pour la protection dans un espace de stockage autogéré.

Les VM VMware Engine sont protégées via la console de gestion du service Backup and DR. Les frais de gestion des ressources sous protection active via la console de gestion du service Backup and DR sont facturés au projet dans lequel le service Backup and DR a été activé et à partir duquel la console de gestion a été déployée. Cela vaut quels que soient les zones, régions ou projets dans lesquels se trouvent les appliances de sauvegarde/restauration.

La tarification de la sauvegarde VMware Engine est basée sur la consommation et la durée d'engagement. Les options comprennent des tarifs à la demande ou des remises sur engagement d'utilisation pour des durées d'un an et de trois ans.

Le tableau suivant répertorie les SKU et les prix pour la protection des nœuds ve1-standard-72 et des nœuds ve1-standard-72 de stockage uniquement VMware Engine dans un coffre-fort de sauvegarde ou dans un espace de stockage autogéré.

Le tableau suivant répertorie les SKU et les tarifs pour la protection des nœuds VMware Engine ve2 dans un coffre-fort de sauvegarde ou dans un espace de stockage autogéré.

Si une VM n'est plus protégée, mais que des données de sauvegarde sont présentes dans un coffre-fort de sauvegarde, les frais de gestion seront facturés comme indiqué ici.

Les bases de données SQL Server autogérées sont protégées via la console de gestion du service Backup and DR. Les frais de gestion des ressources sous protection active via la console de gestion du service Backup and DR sont facturés au projet dans lequel le service Backup and DR a été activé et à partir duquel la console de gestion a été déployée. Cela vaut quels que soient les zones, régions ou projets dans lesquels se trouvent les appliances de sauvegarde/restauration.

Le tableau suivant répertorie les SKU et les prix pour la protection dans un coffre-fort de sauvegarde.

Si SQL Server n'est plus protégé activement, mais que des données de sauvegarde sont présentes dans un coffre de sauvegarde, des frais de gestion seront facturés comme décrit ici.

Le tableau suivant répertorie les SKU et les prix pour la protection dans un espace de stockage autogéré.

Les bases de données Oracle autogérées sont protégées via la console de gestion du service Backup and DR. Les frais de gestion des ressources sous protection active via la console de gestion du service Backup and DR sont facturés au projet dans lequel le service Backup and DR a été activé et à partir duquel la console de gestion a été déployée. Cela vaut quels que soient les zones, régions ou projets dans lesquels se trouvent les appliances de sauvegarde/restauration.

La tarification de la sauvegarde Oracle dans un coffre de sauvegarde est basée sur la consommation et la durée d'engagement. Les options comprennent des tarifs à la demande ou des remises sur engagement d'utilisation pour des durées d'un an et de trois ans. Le tableau suivant répertorie les SKU et les prix pour la protection dans un coffre-fort de sauvegarde.

Si Oracle n'est plus protégé, mais que des données de sauvegarde sont présentes dans un coffre de sauvegarde, les frais de gestion seront facturés comme décrit ici.

Le tableau suivant répertorie les SKU et les prix pour la protection dans un espace de stockage autogéré.

Les bases de données SAP HANA autogérées sont protégées via la console de gestion du service Backup and DR. Les frais de gestion des ressources sous protection active via la console de gestion du service Backup and DR sont facturés au projet dans lequel le service Backup and DR a été activé et à partir duquel la console de gestion a été déployée. Cela vaut quels que soient les zones, régions ou projets dans lesquels se trouvent les appliances de sauvegarde/restauration. Le tableau suivant répertorie les SKU et les prix pour la protection dans un espace de stockage autogéré.

Le service Backup and DR permet également de protéger d'autres ressources via la console de gestion du service Backup and DR, comme indiqué ci-dessous (par exemple, les systèmes de fichiers, les bases de données MySQL, etc.). Les frais de gestion de ces ressources sous protection active via la console de gestion du service Backup and DR sont facturés au projet dans lequel le service Backup and DR a été activé et à partir duquel la console de gestion a été déployée. Cela vaut quels que soient les zones, régions ou projets dans lesquels se trouvent les appliances de sauvegarde/restauration. Le tableau suivant répertorie les SKU et les prix pour la protection dans un espace de stockage autogéré.

Si une ressource n'est plus protégée (c'est-à-dire que la protection de la ressource est "inactive") dans un coffre-fort de sauvegarde donné, mais qu'elle contient toujours des données de sauvegarde dans ce coffre-fort, des frais de gestion seront facturés au projet dans lequel le coffre-fort de sauvegarde a été créé, en utilisant la SKU et le prix indiqués ci-dessous.

Notez également les scénarios suivants dans lesquels la protection des ressources sera considérée comme "inactive" :

• Consultez les comportements de facturation associés à la désactivation d'une API.
• Pour les ressources protégées par un appareil de sauvegarde/restauration :
• Si l'appliance de sauvegarde/récupération ne communique pas avec le coffre-fort de sauvegarde pendant 24 heures, la protection de la ressource de coffre-fort de sauvegarde associée sera considérée comme "inactive".

Pour calculer les frais de gestion, Backup and DR mesure l'utilisation en fonction de la taille réelle de la charge de travail au niveau du frontend ou de la taille de la charge de travail qu'il gère. L'unité de mesure est le gibioctet (Gio). Un gibioctet = 1 024 * 1 024 * 1 024 octets.

Si la charge de travail gérée indique la taille du volume pour les données, Backup and DR prend en compte la taille du volume indiquée (par exemple, le calcul de l'utilisation pour VMware sera cohérent avec la taille de la VM indiquée dans vCenter).

Si vous gérez 10 Tio de données Oracle réparties sur plusieurs bases de données, Backup and DR indique 10 * 1 024 Gio d'utilisation de données dans ses rapports.

Remarque : La mesure de l'utilisation de Backup and DR ne tient pas compte de la fréquence de capture des données, de l'emplacement de stockage des copies, du nombre de copies effectuées, du taux de modification des données, de la période de conservation ni de la quantité d'espace de stockage occupée par les copies.

Mesure de l'utilisation pour Compute Engine, lors de la sauvegarde vers un espace de stockage autogéré

Lorsqu'une sauvegarde est effectuée sur un espace de stockage autogéré, Backup and DR mesure l'utilisation pour les sauvegardes de VM Compute Engine en fonction de la quantité de stockage PD associé à une VM Compute Engine au moment de la sauvegarde. Backup and DR vous permet d'exclure les volumes PD de la sauvegarde. Dans ce cas, seuls les volumes identifiés pour la sauvegarde sont utilisés pour mesurer l'utilisation.

Par exemple, si deux volumes PD de 1 Tio et 2 Tio sont associés à une VM Compute Engine et que vous configurez le SLT de sauvegarde pour exclure le volume de 2 Tio, l'utilisation de la VM est mesurée à 1 Tio.

De plus, si la VM de 1 Tio augmente ou diminue, Backup and DR mesure l'utilisation en fonction de la taille du volume au moment de la dernière sauvegarde.

Mesure de l'utilisation pour Compute Engine lors de la sauvegarde dans un coffre de sauvegarde

Lorsqu'une sauvegarde est effectuée dans un coffre-fort de sauvegarde, Backup and DR mesure l'utilisation pour la VM Compute Engine comme décrit ci-dessous.

• Les frais de gestion sont basés sur la taille de la VM Compute Engine au moment de la sauvegarde. Par exemple, si une VM dispose d'un espace de stockage total de 1 Tio, les frais de gestion s'appliqueront à ce volume, quelle que soit la quantité de stockage utilisée.
• De plus, si la VM de 1 Tio se développe ou se réduit, Backup and DR mesure l'utilisation en fonction de la taille de la VM au moment de la dernière sauvegarde.

Mesure de l'utilisation lors de la sauvegarde de disques indépendants (disques persistants et hyperdisques) dans un coffre-fort de sauvegarde

Pour les sauvegardes stockées dans un coffre-fort de sauvegarde, Backup and DR calcule l'utilisation des disques persistants/Hyper indépendants comme suit :

• Les frais de gestion sont déterminés par la taille du disque persistant/Hyperdisk au moment de chaque sauvegarde. Cela signifie qu'un disque de 1 Tio sera facturé pour 1 Tio, quelle que soit la quantité de stockage réellement utilisée.
• De plus, Backup and DR recalculera l'utilisation en fonction de la taille actuelle du disque lors de la sauvegarde la plus récente, même si la taille du disque de la VM a changé depuis la sauvegarde précédente.

Mesure de l'utilisation pour VMware Engine sans agent

Pour les nœuds VMware Engine ve1 et ve2

La tarification est calculée en fonction du nombre et du type de nœuds ESXi protégés. Un nœud ESXi est considéré comme protégé si une ou plusieurs des VM qui y sont rattachées sont protégées par le service de sauvegarde et de reprise après sinistre.

Voici un exemple illustrant le processus de facturation pour VMware Engine :

• Prix de la sauvegarde d'un seul nœud ve1 VMware Engine (sauvegardes de VM uniquement) dans la région us-central1 pendant un mois = (prix catalogue de la sauvegarde du nœud/ heure) X (nombre d'heures pendant lesquelles le nœud est actif par jour) X (nombre de jours dans un mois).
• Étant donné que le nœud VMware Engine est actif pendant 24 heures, qu'il y a 30 jours dans un mois et que le prix de sauvegarde d'un nœud est de 0, 46 $× 24 × 30 = 331$.

Pour les nœuds ve2, la tarification dépend à la fois du nombre et du type (méga, grand, standard, petit) de nœuds ESXi protégés.

La tarification ne concerne que la protection de VMware Engine, c'est-à-dire les sauvegardes de VM complètes. Il n'inclut pas les frais de gestion des sauvegardes pour les sauvegardes basées sur un agent, comme les frais pour les sauvegardes cohérentes au niveau des applications pour SAP HANA, SQL Server, MySQL, Postgres, les agents de système de fichiers, etc. Pour estimer les frais pour les sauvegardes basées sur un agent, consultez Mesure de l'utilisation pour les sauvegardes basées sur un agent.

Pour les nœuds de stockage uniquement VMware Engine ve1 et ve2

Le prix de la protection d'un nœud VMware Engine ve1/ve2 dédié au stockage est déterminé par le nombre de nœuds VMware Engine ve1/ve2 dédiés au stockage ajoutés à un cluster qui comporte au moins un ou plusieurs nœuds VMware Engine ve1/ve2 protégés.

Si vous avez un cluster avec des nœuds protégés VMware Engine ve1/ve2 et que vous ajoutez des nœuds de stockage uniquement VMware Engine ve1/ve2 au même cluster, tous les nœuds de stockage uniquement du cluster seront considérés comme protégés par défaut et vous serez facturé pour la protection de tous ces nœuds. Vous ne pouvez pas exclure la protection pour les nœuds de stockage uniquement VMware Engine ve1/ve2 dans un cluster qui comporte au moins un ou plusieurs nœuds protégés VMware Engine ve1/ve2.

Par exemple, supposons que vous ayez un cluster existant de 20 nœuds et que vous en protégiez 10 à l'aide du service de sauvegarde et de reprise après sinistre. Si vous ajoutez trois nœuds de stockage uniquement au cluster, ces trois nœuds seront considérés comme protégés, et vous serez facturé pour la protection de 10 + 3 = 13 nœuds VMware Engine ve1.

Si vous ne protégez aucun nœud VMware Engine ve1/ve2 sur un cluster, les nœuds de stockage uniquement VMware Engine v1/ve2 ne peuvent pas être protégés dans ce cas.

Backup and DR mesure l'utilisation pour les sauvegardes basées sur un agent en fonction de la taille réelle de la charge de travail. Par exemple, si une sauvegarde de base de données SQL Server utilise l'agent Backup and DR et que la somme des fichiers de données d'un serveur SQL est de cinq Tio sur un volume de sept Tio, l'utilisation est mesurée à cinq Tio.

Mesure de l'utilisation pour la sauvegarde de bases de données basée sur un agent

Pour les charges de travail Oracle et SQL Server, seules les bases de données protégées sont comptabilisées dans l'utilisation. Il ne prend pas en compte les fichiers journaux :

• Oracle. La taille allouée des fichiers de base de données protégés est prise en compte dans l'utilisation. La taille allouée inclut les fichiers de données et les fichiers de contrôle.
• Microsoft SQL Server. La taille totale de tous les fichiers de base de données, y compris les fichiers .MDF, .LDF et .NDF sous protection, est prise en compte dans l'utilisation.
• Protection des bases de données avec le suivi des blocs modifiés (CBT) sous Linux Backup and DR permet de sauvegarder efficacement plusieurs bases de données grâce au suivi des blocs modifiés. Ce mode de sauvegarde repose sur des fichiers de données et de journaux de base de données résidant sur des volumes gérés par Linux Logical Volume Manager (LVM). Pour cette catégorie de charges de travail, l'utilisation est mesurée en fonction de la taille réelle de la base de données protégée, à l'aide des requêtes suivantes :
• Db2 : call get_dbsize_info(?,?,?,-1);
• MariaDB : SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='';
• MySQL : SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='';
• PostgreSQL : SELECT pg_database_size('$db');
• SAP ASE : sp_spaceused;
• SAP IQ : sp_iqdbsize * block_size;
• SAP HANA : sélectionnez sum(TOTAL_SIZE) dans sys_databases.M_VOLUME_FILES où file_type='DATA'
• SAP MaxDB : dbmcli -d $DBSID $MAXDB_KEY info DATA
• Protection basée sur le vidage SQL sans CBT Linux. Backup and DR prend en charge les sauvegardes traditionnelles basées sur les vidages SQL. Dans ce mode, l'utilisation est mesurée en fonction de la taille de la base de données telle qu'elle est signalée par la base de données au moment de la sauvegarde.

Facteurs qui influencent la mesure de l'utilisation

Facteurs qui influencent la mesure de l'utilisation dans les scénarios hors bande :

• Volumes compressés Lorsque la compression est activée pour le volume, l'utilisation est comptabilisée selon les valeurs post-compression. Par exemple, si un volume de 2 Tio contient 2,5 Tio de données qui sont compressées en 1,8 Tio, le nombre d'utilisations sera de 1,8 Tio, et non de 2,5 Tio.
• Volumes optimisés pour Windows Pour les volumes optimisés pour Windows, Backup and DR réhydrate le volume pour la sauvegarde, et le nombre d'utilisations correspondra à la valeur réhydratée. Par exemple, si un volume optimisé pour Windows de 1 Tio contient 800 Gio de données, et que sa réhydratation pour la sauvegarde aboutit à un volume de 1,1 Tio, l'utilisation est de 1,1 Tio.
• Tailles des blocsPour les disques de préproduction, Backup and DR mesure l'utilisation en fonction de la taille des blocs du disque de préproduction. Si la taille des blocs du volume source et celle du disque de préproduction sont identiques, les valeurs d'utilisation correspondent exactement à celles du volume source. Si la taille de bloc utilisée sur le disque de préproduction est différente de celle du volume source, il y aura une légère différence, car le calcul de l'utilisation est effectué sur le disque de préproduction.
• Groupes de cohérenceLe nombre d'utilisations d'un groupe de cohérence correspond à la somme des tailles de toutes les charges de travail du groupe de cohérence. Les charges de travail sont mesurées individuellement, puis additionnées.

Mesure de l'utilisation des copies virtuelles

Backup and DR mesure l'utilisation des copies virtuelles à partir du moment où une copie virtuelle d'une charge de travail est créée. Le volume d'utilisation est basé sur la taille de l'application au moment de la dernière sauvegarde. À mesure que de nouvelles sauvegardes sont effectuées, la quantité d'espace utilisé est mise à jour pour refléter la taille actuelle de l'application. La méthode la plus courante pour créer des copies virtuelles consiste à utiliser des jobs de montage. D'autres types de jobs, tels que prep-mount et reprovision, peuvent également créer une copie virtuelle. Les frais d'utilisation sont calculés au prorata de la durée d'utilisation de la copie virtuelle (de l'opération de montage réussie à l'opération de démontage, par tranches d'une heure).

Prenons l'exemple d'une base de données SQL Server de 500 Gio. Les sauvegardes de cette base de données entraînent des frais d'utilisation de la sauvegarde associés à 500 Gio. De plus, une copie virtuelle de cette base de données est provisionnée sur un serveur de test à midi le premier jour du mois à partir de la sauvegarde la plus récente. Le 10 du mois, la taille de la base de données source est réduite à 400 Gio. Le 20 du mois, la copie virtuelle est démontée du serveur de test à 11h. Dans ce scénario, des frais d'utilisation de la copie virtuelle de 500 Gio sont facturés pendant 12 heures le 1er, puis 24 heures par jour du 2 au 10, jusqu'à l'heure de la sauvegarde. Les frais d'utilisation de la copie virtuelle passent à 400 Gio le 10 (au moment de la sauvegarde) et continuent jusqu'au 20 du mois. L'utilisation de la copie virtuelle le 20 juin ne sera comptabilisée que pour 11 heures, et non pour la journée entière. La quantité d'espace utilisée ne change pas lorsque des données supplémentaires sont écrites dans la copie virtuelle.

Si les données sont transférées depuis un coffre-fort de sauvegarde et que la source et la destination se trouvent dans des emplacements Google Cloud différents, des frais de transfert de données entre régions peuvent s'appliquer.

Les frais de transfert de données interrégional s'appliquent actuellement aux transferts associés aux VM VMware Engine, aux bases de données Oracle, aux bases de données SQL Server et aux disques.

Les frais de transfert de données entre régions pour les VM VMware Engine, les bases de données Oracle et les bases de données SQL Server seront facturés au projet dans lequel se trouve le coffre-fort de sauvegarde, en utilisant les SKU Backup and DR listés ci-dessous.

Les frais de transfert de données interrégional pour les disques seront facturés au projet cible du transfert de données et s'appliqueront à la taille des données transférées.

• Pour les restaurations de disques, le projet cible est le projet de la ressource restaurée. La facturation s'effectuera via la SKU de transfert de données interrégional Compute Engine correspondante.

Des frais de transfert de données interrégional s'appliqueront aux VM Compute Engine à l'avenir. Les clients Backup and DR seront prévenus à l'avance avant que les frais de transfert de données entre régions pour les VM Compute Engine ne commencent à s'appliquer.

Les tarifs de transfert de données interrégional basés sur l'utilisation sont indiqués dans le tableau ci-dessous et sont mesurés par Gio de données transférées.

Des frais d'importation peuvent s'appliquer pour la création de sauvegardes multirégionales. Des frais de téléchargement peuvent s'appliquer pour la restauration des sauvegardes multirégionales.

Les frais d'importation et d'exportation s'appliquent actuellement aux transferts associés aux disques et sont calculés en fonction de la taille des données transférées.

Informations supplémentaires :

• Les frais d'importation et de téléchargement sont facturés aux SKU correspondants dont les emplacements géographiques contiennent l'emplacement multirégional.
• Lorsque des frais de mise en ligne/téléchargement s'appliquent à un transfert de données entre des emplacements, les frais de transfert de données interrégional ne s'appliquent pas.
• Facturation des projets
• Les frais d'importation sont facturés, via la SKU du service Backup and DR correspondant, au projet dans lequel le coffre de sauvegarde multirégional a été créé.
• Les frais de téléchargement sont facturés, via le SKU de téléchargement du service Compute Engine correspondant, au projet cible dans lequel les données ont été restaurées.

Exemples de cas d'utilisation :

• "Sauvegarder un disque dans la région "us-central1" dans un coffre-fort de sauvegarde multirégional situé dans l'emplacement "us"
• Des frais d'importation multirégionaux s'appliqueraient.
• La facturation s'effectuera à l'aide du SKU d'importation multirégional "Amérique du Nord" du service Backup and DR.
• Les frais d'importation seraient facturés au projet dans lequel le backup vault a été créé.
• Les frais de transfert de données interrégionaux ne s'appliqueraient pas.
• Restaurer une sauvegarde de disque multirégionale "us" sur une ressource située dans la région "us-central1".
• Des frais de téléchargement multirégionaux s'appliqueraient.
• La facturation s'effectue à l'aide du SKU Compute Engine correspondant (consultez cette page pour en savoir plus sur les tarifs de Compute Engine).
• Les frais de téléchargement seraient facturés au projet cible dans lequel la ressource restaurée a été créée.
• Les frais de transfert de données interrégionaux ne s'appliqueraient pas.
• Restaurer une sauvegarde de disque multirégionale "us" sur une ressource située dans la région "europe-west1".
• Les frais de téléchargement multirégionaux ne s'appliqueraient pas.
• Des frais de transfert de données interrégionaux s'appliqueraient.
• La facturation s'effectue à l'aide du SKU Compute Engine correspondant (pour plus d'informations sur les tarifs de Compute Engine, cliquez ici).
• Les frais de transfert de données interrégional seraient facturés au projet cible dans lequel la ressource restaurée a été créée.

Les frais de transfert (importation et exportation) pour les VM Compute Engine s'appliqueront à l'avenir. Les clients Backup and DR seront prévenus à l'avance avant que les frais de mise en ligne et de téléchargement pour les VM Compute Engine ne commencent à s'appliquer.

Désactivation de l'API dans le projet contenant un coffre-fort de sauvegarde

Lorsque l'API du service Backup and DR est désactivée dans un projet contenant un coffre-fort de sauvegarde, la facturation se déroule comme suit :

• La facturation du stockage se poursuivra jusqu'à l'expiration des sauvegardes, conformément au calendrier d'expiration défini par l'utilisateur.
• Pour les VM Compute Engine protégées dans des coffres de sauvegarde
• La facturation de la gestion pour la protection active continuera pendant 30 jours (dans le projet où se trouve la ressource protégée). Après 30 jours consécutifs de désactivation, la protection des ressources stockées sera considérée comme inactive.
• Si des données de sauvegarde existent dans un coffre-fort de sauvegarde, mais que la ressource associée n'est plus protégée activement, la facturation de la gestion des ressources qui ne sont plus protégées activement s'applique.

Désactivation de l'API dans un projet contenant des VM Compute Engine protégées dans un coffre-fort de sauvegarde

Lorsque l'API du service Backup and DR est désactivée dans un projet contenant une ressource protégée dans un coffre-fort de sauvegarde, la facturation se déroule comme suit :

• La facturation du stockage se poursuivra jusqu'à l'expiration des sauvegardes, conformément au calendrier d'expiration défini par l'utilisateur.
• La facturation de la gestion pour la protection active cessera. Après 30 jours consécutifs de désactivation, la protection des ressources stockées sera considérée comme inactive.
• Si des données de sauvegarde existent dans un coffre-fort de sauvegarde, mais que la ressource associée n'est plus protégée activement, la facturation de la gestion des ressources qui ne sont plus protégées activement s'applique.

L'appliance de sauvegarde/restauration s'exécute en tant que VM Compute Engine dans un projet choisi par le client. Les appliances Backup and DR Service sont disponibles dans trois configurations différentes, comme indiqué dans Configurer et planifier un déploiement Backup and DR Service. Les frais standards d'instance Compute Engine s'appliquent pour l'exécution de ces appliances.