Sauvegardes

Cette page présente les sauvegardes Cloud Bigtable.

Les sauvegardes Cloud Bigtable vous permettent d'enregistrer une copie du schéma et des données d'une table, puis de restaurer depuis la sauvegarde vers une nouvelle table ultérieurement. Avant de lire cette page, vous devez avoir consulté les pages Présentation de Cloud Bigtable et Gérer des tables.

Objectif des sauvegardes

Les sauvegardes vous aident à récupérer des données corrompues au niveau de l'application ou à corriger des erreurs d'opérateur, comme la suppression accidentelle d'une table.

Objectifs exclus des sauvegardes

Les sauvegardes ne sont pas destinées à garantir une protection contre les défaillances régionales ou zonales. Utilisez la réplication si vous avez besoin de basculer vers différentes régions ou zones.

Les sauvegardes ne sont pas lisibles. Elles ne sont donc pas utiles pour les analyses hors ligne.

Principales fonctionnalités

  • Intégration complète : les sauvegardes sont entièrement gérées par le service Cloud Bigtable, sans importation ni exportation.
  • Économies de coûts : l'utilisation de sauvegardes Cloud Bigtable vous permet d'éviter les coûts associés à l'exportation, au stockage et à l'importation de données à l'aide d'autres services.
  • Efficacité du stockage : les sauvegardes sont incrémentielles. Le stockage est optimisé de sorte qu'une sauvegarde ne prend en compte que les données qui ont été modifiées depuis la sauvegarde précédente.
  • Expiration automatique : chaque sauvegarde est associée à une date d'expiration définie par l'utilisateur, pouvant aller jusqu'à 30 jours après la création de la sauvegarde.

Utiliser les sauvegardes

Consultez la page Gérer les sauvegardes pour obtenir des instructions détaillées sur la sauvegarde et la restauration d'une table, ainsi que sur des opérations, telles que la mise à jour et la suppression de sauvegardes.

Pour effectuer des sauvegardes Cloud Bigtable, utilisez les éléments suivants :

Vous pouvez également accéder directement à l'API. Toutefois, nous ne vous le recommandons vivement que si vous ne pouvez pas utiliser une bibliothèque cliente Cloud Bigtable qui appelle l'API.

Fonctionnement des sauvegardes

Storage

Une sauvegarde de table est une ressource au niveau du cluster. Même si une table se trouve dans une instance dotée de plusieurs clusters (ce qui signifie que le cluster utilise la réplication), une sauvegarde est créée et stockée sur un seul cluster de cette instance.

Sauvegarde stockée sur un seul cluster

La sauvegarde d'une table inclut toutes les données qui étaient présentes dans la table au moment de la création de la sauvegarde, sur le cluster dans lequel la sauvegarde est créée. Une sauvegarde ne dépasse jamais la taille de la table source au moment de la création de la sauvegarde. Vous pouvez créer jusqu'à 50 sauvegardes par table et par cluster.

Vous pouvez supprimer une table associée à une sauvegarde. Pour protéger vos sauvegardes, vous ne pouvez pas supprimer un cluster contenant une sauvegarde et vous ne pouvez pas supprimer une instance contenant une ou plusieurs sauvegardes dans un cluster.

Une sauvegarde existe toujours après sa restauration dans une nouvelle table. Vous pouvez le supprimer ou le laisser expirer lorsque vous n'en avez plus besoin. L'espace de stockage de la sauvegarde n'est pas comptabilisé dans la limite de stockage de nœuds d'un projet.

Les données contenues dans les sauvegardes sont chiffrées et stockées dans un format propriétaire.

Coûts

La création ou la restauration d'une sauvegarde est gratuite.

Pour stocker une sauvegarde, vous êtes facturé au tarif de stockage des sauvegardes standard pour la région dans laquelle se trouve le cluster.

Les sauvegardes Bigtable optimisent l'utilisation du stockage des sauvegardes. Les sauvegardes sont incrémentielles. Par conséquent, la quantité de stockage utilisée pour votre sauvegarde dépend de la quantité de données divergentes par rapport au point de sauvegarde précédent.

Remarques sur la réplication

Cette section décrit des concepts supplémentaires à comprendre lors de la sauvegarde et de la restauration d'une table dans une instance qui utilise la réplication.

Sauvegarder

Lorsque vous effectuez la sauvegarde d'une table dans une instance dupliquée, vous choisissez le cluster dans lequel vous souhaitez créer et stocker cette sauvegarde. Il n'est pas nécessaire d'interrompre les opérations d'écriture dans le cluster contenant la sauvegarde, mais vous devez savoir comment sont gérées les écritures répliquées sur le cluster.

Une sauvegarde est une copie de la table dans son état sur le cluster dans lequel la sauvegarde est stockée, au moment de la création de la sauvegarde. Les données de table qui n'ont pas encore été répliquées à partir d'un autre cluster de l'instance ne sont pas incluses dans la sauvegarde.

Chaque sauvegarde possède une heure de début et une heure de fin. Les écritures envoyées au cluster brièvement avant ou pendant l'opération de sauvegarde risquent de ne pas être incluses dans la sauvegarde. Deux facteurs contribuent à cette incertitude :

  • Une opération d'écriture peut être envoyée à une section de la table déjà copiée.
  • Une opération d'écriture sur un autre cluster peut ne pas avoir été répliquée sur le cluster contenant la sauvegarde.

En d'autres termes, il est possible que certaines opérations d'écriture dont l'horodatage est antérieur à l'heure de la sauvegarde n'y soient pas incluses. Si cela ne convient pas à votre activité, vous pouvez utiliser un jeton de cohérence avec vos requêtes d'écriture pour vous assurer que toutes les opérations d'écriture répliquées sont incluses dans une sauvegarde.

Restauration...

Lorsque vous restaurez une sauvegarde dans une nouvelle table, la réplication vers et depuis les autres clusters de l'instance démarre immédiatement après la fin de l'opération de restauration sur le cluster dans lequel la sauvegarde a été stockée.

Performances

Sauvegarder

La création d'une sauvegarde prend généralement moins d'une minute, mais peut durer jusqu'à une heure. En temps normal, la création de sauvegardes n'affecte pas les performances de diffusion.

Pour des performances optimales, ne créez pas une sauvegarde d'une table plus d'une fois toutes les cinq minutes. Créer des sauvegardes plus fréquemment peut entraîner une augmentation notable de la latence de diffusion.

Restauration...

La restauration d'une sauvegarde dans une table au sein d'une instance à cluster unique prend quelques minutes. Dans les instances multicluster, la restauration prend plus de temps, car les données doivent être copiées sur tous les clusters.

Si vous stockez les tables dans des clusters SSD, la latence en lecture sera peut-être initialement supérieure, même une fois la restauration terminée, alors que la table est optimisée. Vous pouvez vérifier l'état à tout moment pendant l'opération de restauration afin de déterminer si l'optimisation est toujours en cours.

Contrôle des accès

Les autorisations IAM contrôlent l'accès aux opérations de sauvegarde et de restauration. Les autorisations de sauvegarde existent au niveau de l'instance et s'appliquent à toutes les sauvegardes de l'instance. Pour créer la sauvegarde d'une table, vous devez avoir l'autorisation de lire la table et de créer des sauvegardes dans l'instance dans laquelle elle se trouve.

Action Autorisation IAM requise
Créer une sauvegarde bigtable.tables.readRows, bigtable.backups.create
Obtenir une sauvegarde bigtable.backups.get
Répertorier des sauvegardes bigtable.backups.list
Supprimer une sauvegarde bigtable.backups.delete
Mettre à jour une sauvegarde bigtable.backups.update
Restaurer une sauvegarde dans une table bigtable.tables.create, bigtable.backups.restore
Obtenir une opération bigtable.instances.get
Répertorier les opérations bigtable.instances.get

Bonnes pratiques

Sauvegardes

  • Ne sauvegardez pas une table plus souvent qu'une fois toutes les cinq minutes.
  • Lorsque vous sauvegardez une table qui utilise la réplication, choisissez le cluster de stockage de la sauvegarde après avoir pris en compte les facteurs suivants :
    • Coût. Un cluster de votre instance peut se trouver dans une région moins coûteuse que les autres.
    • Proximité avec votre serveur d'applications. Vous souhaitez peut-être stocker la sauvegarde aussi près que possible de votre application de diffusion.
    • Utilisation du stockage Vous avez besoin d'un espace de stockage suffisant pour conserver votre sauvegarde à mesure que sa taille augmente. En fonction de votre charge de travail, vous pouvez disposer de clusters de différentes tailles ou présentant une utilisation des disques différente. Cela peut être un facteur de choix du cluster.
  • Si vous devez vous assurer que toutes les écritures répliquées sont incluses dans une sauvegarde lorsque vous sauvegardez une table dans une instance qui utilise la réplication, utilisez un jeton de cohérence associé à vos requêtes d'écriture.

Restaurer des sauvegardes

  • Prévoyez à l'avance le nom de la nouvelle table si vous devez effectuer une restauration à partir d'une sauvegarde. Il est essentiel d'être prêt à l'avance pour ne pas avoir à prendre de décision lorsque vous êtes confronté à un problème.
  • Si vous restaurez une table pour une raison autre qu'une suppression accidentelle, assurez-vous que toutes les opérations de lecture et d'écriture sont adressées à la nouvelle table avant de supprimer la table d'origine.

Quotas et limites

Les requêtes de sauvegarde et de restauration ainsi que le stockage de sauvegarde sont soumis aux quotas et limites de Cloud Bigtable.

Limites

Les limites suivantes s'appliquent aux sauvegardes Cloud Bigtable :

  • Vous ne pouvez pas lire directement à partir d'une sauvegarde.
  • Vous ne pouvez pas restaurer une table vers une table existante ou vers une nouvelle table au sein d'une instance différente.
  • Si vous restaurez une sauvegarde dans la table d'un cluster SSD, puis supprimez la table nouvellement restaurée, la suppression de la table peut prendre un certain temps, car Cloud Bigtable attend la fin de l'optimisation de la table.
  • Les sauvegardes sont zonales et partagent les mêmes garanties de disponibilité que le cluster dans lequel elles sont créées. Les sauvegardes ne protègent pas contre les pannes régionales.
  • Une sauvegarde est une version d'une table au sein d'un seul cluster à un moment donné. Les sauvegardes ne représentent pas un état cohérent. Cela s'applique également aux sauvegardes de la même table au sein de différents clusters.
  • Vous ne pouvez pas sauvegarder plusieurs tables en une seule opération.
  • Vous ne pouvez pas exporter, copier ou déplacer une sauvegarde Cloud Bigtable vers un autre service, tel que Cloud Storage.

Étape suivante