Tarifs
- Où puis-je trouver des informations sur les tarifs du service Backup and DR ?
- Pour en savoir plus sur les tarifs du service Backup and DR, consultez la page des tarifs du service Backup and DR.
- Quand une charge de travail est-elle considérée comme gérée par le service Backup and DR ?
- La facturation du service de sauvegarde et de reprise après sinistre (également appelée "utilisation du SKU") tient compte de toute charge de travail utilisant au moins une sauvegarde non expirée avec le service. Les images de sauvegarde peuvent être conservées dans un instantané ou un pool OnVault pendant de longues périodes (des années) à des fins de conformité lorsque la charge de travail source n'est plus activement protégée.
- La compression des sauvegardes a-t-elle un impact sur l'utilisation ?
- La compression obtenue par le système dans les pools d'instantanés et d'OnVault n'affecte pas la mesure de l'utilisation, car le nombre d'utilisation est basé sur la taille de la charge de travail du frontend et non sur la consommation de stockage du backend.
- Quel est l'impact de la réplication entre les appareils de sauvegarde/récupération sur l'utilisation ?
- Le service Backup and DR mesure l'utilisation en fonction de la taille de la charge de travail côté client. Il ne tient pas compte du nombre de copies conservées ni de leur emplacement. L'ajout d'un appareil à des fins de reprise après sinistre n'a aucune incidence sur l'utilisation des SKU du service Backup and DR.
- Quel est l'impact des chemins d'élagage et des listes d'exclusion sur la facturation de Backup and DR ?
Si votre charge de travail de système de fichiers contient 3 To de données, que vous utilisez des chemins d'élagage et des listes d'exclusion pour exclure 1 To de fichiers de la gestion et que vous utilisez l'agent de sauvegarde et de reprise après sinistre pour sauvegarder le système de fichiers, l'utilisation est mesurée en fonction de la quantité réelle de données gérées, qui est de 2 To dans cet exemple.
Si vous sauvegardez le système de fichiers sans l'agent Backup and DR (par exemple, avec une sauvegarde complète de la VM VMware/Compute Engine sans agent), l'utilisation est mesurée en fonction de la taille du ou des volumes, qui est de 3 To.
- Le nombre d'utilisations de ma charge de travail semble être inférieur à celui indiqué hier. Pourquoi ?
L'utilisation du service Backup and DR est basée sur la copie réussie la plus récente, et non sur la plus grande copie récupérable. Les charges de travail diminuent ou augmentent au fil du temps (indépendamment des taux de changement impliqués). Lorsque la taille de la charge de travail diminue, cela se reflète sur la lecture d'utilisation de la sauvegarde la plus récente.
- Quel est l'impact du taux de modification de la base de données sur l'utilisation ?
Le service Backup and DR mesure l'utilisation en fonction de la taille de la dernière copie réussie. Par conséquent, pour une base de données Oracle de 4 Tio avec un taux de modification quotidien de 10 %, mais dont la taille est toujours de 4 Tio, le calcul de l'utilisation sera de 4 Tio. Sauf si la taille de la charge de travail change, le taux de modification n'a pas d'incidence directe sur le calcul de l'utilisation.
- Comment éviter de payer une double protection si je protège une charge de travail et sa VM ?
Le service Backup and DR compte l'utilisation d'une VM VMware et de ses charges de travail séparément, ce qui peut entraîner une double comptabilisation. Si vous gérez une charge de travail SQL Server exécutée sur une VM VMware à l'aide de l'agent de sauvegarde et de reprise après sinistre, et si vous gérez également l'ensemble de la VM VMware, la base de données SQL est comptabilisée séparément de la VM et en plus de celle-ci. Dans de tels scénarios, il est recommandé de gérer séparément le volume de l'OS de la VM et les charges de travail qui y résident. Cela élimine efficacement la double protection et donc la double comptabilisation.
- Comptez-vous uniquement la taille de la base de données ou incluez-vous les fichiers journaux dans la mesure de l'utilisation ?
Le service Backup and DR ne mesure que les fichiers de base de données gérés nécessaires à une sauvegarde cohérente de la base de données. Les fichiers journaux ne sont pas comptabilisés dans la mesure de l'utilisation.
- Comment vérifier mon utilisation des VM VMware ?
Les mesures d'utilisation du service Backup and DR pour les VM VMware sont cohérentes avec la taille indiquée par vCenter pour cette VM.
La sortie du -h *.vmdk du dossier de VM approprié sur le datastore correspond au nombre d'utilisations.
- Comment vérifier mon utilisation de la base de données Oracle ? Les mesures d'utilisation du service de sauvegarde et de reprise après sinistre
- pour Oracle sont basées sur la taille allouée à la base de données. Voici un exemple de requête pour vérifier la taille de la base de données Oracle.
select (d.total + c.total) total from (select sum(bytes) total from v$datafile) d, (select sum(block_size*file_size_blks) total from v$controlfile) c;
Ensuite, soustrahissez les éléments suivants: select sum(bytes) free from dba_free_space;
- Comment vérifier mon utilisation des systèmes de fichiers ?
- Mesures de l'utilisation du service Backup and DR pour le système de fichiers en fonction des charges de travail :
- Windows : taille du système de fichiers utilisé indiquée par DiskManager
- Linux : taille du système de fichiers utilisé indiquée par
df - k
Migration vers une tarification basée sur les nœuds pour la sauvegarde de Google Cloud VMware Engine
- Qu'inclut la tarification basée sur les nœuds pour la sauvegarde de Google Cloud VMware Engine ?
- Les tarifs ne s'appliquent qu'à la protection de Google Cloud VMware Engine (sauvegardes de VM complètes). Il n'inclut pas les frais de gestion des sauvegardes pour les sauvegardes basées sur des agents, tels que les frais de sauvegardes cohérentes pour les applications pour SAP HANA, SQL Server, MySQL ou Postgres. Pour estimer les frais de sauvegarde basée sur des agents, la taille de production de chacun de ces types de bases de données est nécessaire. Les sauvegardes basées sur des agents sont facturées selon les tarifs standards deGoogle Cloud sauvegarde et reprise après sinistre.
- Comment les tarifs actuels basés sur la licence de données gérées (MDL) se comparent-ils aux nouveaux tarifs basés sur le nombre de nœuds pour la sauvegarde de Google Cloud VMware Engine ?
- Voici un exemple illustrant la différence entre les tarifs existants et les nouveaux tarifs pour la sauvegarde de la nouvelle version de Google Cloud VMware Engine.
- Mes remises tarifaires existantes seront-elles applicables aux nouveaux codes SKU de sauvegarde associés à Google Cloud VMware Engine ?
- Vos remises tarifaires existantes resteront applicables aux nouveaux SKU de sauvegarde associés à Google Cloud VMware Engine.
- Puis-je choisir entre la tarification basée sur la licence de données gérées (MDL) existante et la nouvelle tarification basée sur les nœuds pour sauvegarder les VM Google Cloud VMware Engine ?
- À l'avenir, seul le nouveau modèle de tarification basé sur les nœuds sera pris en charge pour tous les clients qui souhaitent sauvegarder des VM Google Cloud VMware Engine à l'aide deGoogle Cloud Backup and DR .
- Que dois-je faire pour passer au nouveau modèle de tarification basé sur les nœuds de Google Cloud VMware Engine ?
- Tous les clients Google Cloud existants de sauvegarde et de reprise après sinistre qui protègent des charges de travail Google Cloud VMware Engine doivent mettre à jour chacun de leurs appareils de sauvegarde/récupération vers la version 11.0.5 ou ultérieure pour adopter le nouveau modèle tarifaire. Une fois que tous les appareils de sauvegarde seront passés à la version 11.0.5 ou ultérieure, après le 4 août 2023, les tarifs passeront automatiquement au nouveau tarif basé sur les nœuds.
- Que se passe-t-il si je ne souhaite pas passer du modèle de tarification basé sur la licence de données gérées (MDL) existante au nouveau modèle de tarification basé sur les nœuds pour la sauvegarde des VM Google Cloud VMware Engine ?
- Vous pouvez continuer à utiliser le modèle de tarification existant en ne mettant pas à niveau l'appliance de sauvegarde/restauration vers la version 11.0.5 ou ultérieure. Toutefois, vous devez mettre à niveau votre appareil et adopter le nouveau modèle de tarification une fois qu'il n'est plus pris en charge.
Nouveau système de création de rapports pour le service Backup and DR
- En quoi consiste le nouveau système de création de rapports et quels sont ses avantages par rapport au gestionnaire de rapports existant ?
Google Cloud Le service de sauvegarde et de reprise après sinistre a ajouté un nouveau système de création de rapports basé sur les services intégrés Google Cloud : Cloud Monitoring, Cloud Logging et BigQuery. Vous bénéficiez ainsi d'une expérience de reporting plus fluide, évolutive et complète.
Vous pouvez effectuer les opérations suivantes à l'aide du nouveau système de création de rapports:
- Découvrir, afficher et analyser les tendances des données de reporting via Cloud Logging
- Afficher, analyser et récupérer des métriques liées aux jobs via Cloud Monitoring
- Créer des rapports personnalisés dans BigQuery à l'aide du langage de requête SQL
- Configurer des alertes personnalisées sur les données de rapport via Cloud Logging et Cloud Monitoring
- Envoyer des rapports par e-mail, planifier automatiquement l'actualisation des données et analyser les données à l'aide des outils
- Pourquoi dois-je passer du gestionnaire de rapports existant à un nouveau système de reporting d'ici le 20 avril 2024 ?
Le gestionnaire de rapports existant sera abandonné le 20 avril 2024. Le lien existant vers le Gestionnaire de rapports dans la console de gestion sera désactivé et vous ne pourrez plus y accéder via la console de gestion ou les scripts après le 20 avril 2024.
- Que se passe-t-il si je ne passe pas au système de signalement d'ici le 20 avril 2024 ?
Si vous ne configurez pas le nouveau système de reporting d'ici le 20 avril 2024, vous ne pourrez accéder qu'aux rapports intégrés au format CSV. Pour ce faire, exportez les rapports vers un bucket Cloud Storage depuis la console de gestion.
- Quelles fonctionnalités du gestionnaire de rapports existant ne sont plus disponibles dans le système de reporting ?
Le tableau suivant explique les fonctionnalités compatibles avec le nouveau système de création de rapports et le gestionnaire de rapports existant.
| Fonctionnalité | Gestionnaire de rapports existant |
Nouveau système de création de rapports |
|---|---|---|
| Rapports prédéfinis | Compatible | Compatible |
| Flexibilité pour exporter des rapports | Compatible | Compatible |
| Filtrer ou trier les données du rapport et effectuer une personnalisation de base (réorganiser ou masquer des colonnes) | Compatible | Compatible |
| Possibilité de définir une durée de conservation personnalisée pour les rapports et les données de reporting | Compatible | Compatible |
| Générer des rapports à la demande | Compatible | Non applicable1 |
| Accéder au rapport depuis la console de gestion | Compatible | Compatible |
| Envoyer des rapports par e-mail | Non compatible | Compatible |
| Possibilité d'interroger et de créer des rapports personnalisés | Non compatible | Compatible |
| Fonctionnalité d'alerte en cas d'événement important | Non compatible | Compatible |
| Possibilité de créer des tableaux de bord personnalisés | Non compatible | Compatible |
| Analyser les données en temps réel à l'aide des outils d'analyse | Non compatible | Compatible |
1 Le nouveau système de création de rapports prend en charge les rapports sur les jobs en quasi-temps réel.
- Toutes mes données de reporting existantes dans le Gestionnaire de rapports seront-elles disponibles dans le nouveau système de reporting ?
- Non, vos données historiques ne sont pas disponibles dans le nouveau système de reporting. Vous pourrez continuer à accéder aux rapports intégrés historiques et existants jusqu'au 30 avril 2025 via l'onglet Exporter l'historique des rapports de la console de gestion. Vous pouvez exporter ces rapports au format CSV vers un bucket Cloud Storage.
- L'exportation d'historiques de rapports au format CSV vers un bucket Cloud Storage entraîne-t-elle des frais ?
- Le service de sauvegarde et de reprise après sinistre n'est pas facturé pour l'exportation des rapports historiques au format CSV vers un bucket Cloud Storage. Le stockage de données dans un bucket Cloud Storage entraîne des frais. Pour en savoir plus, consultez la section Tarifs de stockage de données pour un compte Cloud Storage.
- Quand l'option d'exportation des rapports historiques sera-t-elle disponible ?
- L'option Exporter les rapports historiques sera disponible à partir du 1er avril 2024. Vous pourrez exporter des rapports à l'aide de la nouvelle option Exporter l'historique des rapports disponible dans le menu Rapports de la console de gestion.
- Quels sont les rapports intégrés historiques et existants qui pourront être exportés ?
Vous pourrez exporter les rapports intégrés suivants au format CSV vers un bucket Cloud Storage.
- L'utilisation du système de création de rapports entraîne-t-elle des coûts supplémentaires ?
Le prix de l'utilisation du nouveau système de reporting dépend des facteurs suivants:
- Volume et durée de conservation des données de journal dans Cloud Logging.
- Volume de données en streaming, stockées et interrogées dans BigQuery.
Pour en savoir plus sur la tarification, consultez la section Tarifs du nouveau système de rapports sur la sauvegarde et la reprise après sinistre.
- Comment passer au nouveau système de reporting ?
Pour commencer à utiliser le nouveau système de création de rapports pour Google Cloud Backup and DR, vous devez mettre à jour votre appareil de sauvegarde/restauration vers la version 11.0.9. Après avoir mis à jour l'appliance, vous pouvez effectuer les opérations suivantes:
- Qui puis-je contacter pour toute question concernant la configuration du système de signalement ?
Vous pouvez contacter l'équipe d'assistanceGoogle Cloud pour toute question ou tout problème lié au système de signalement.