Sauvegardes

Cette page présente les sauvegardes Cloud Bigtable.

Les sauvegardes 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 articles Présentation de 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. Vous pouvez effectuer une restauration à partir d'une sauvegarde dans une nouvelle table de l'instance sur laquelle la sauvegarde a été créée ou sur une autre instance.

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.

Fonctionnalités

  • Intégration complète : les sauvegardes sont entièrement gérées par le service Bigtable, sans importation ni exportation.
  • Réduction des 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.
  • 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.
  • Options de restauration flexibles : vous pouvez effectuer une restauration à partir d'une sauvegarde dans une table d'une instance différente à partir de laquelle la sauvegarde a été créée.

Voici les raisons pour lesquelles vous pourriez effectuer une restauration vers une autre instance :

  • Vous souhaitez interroger une table qui a été restaurée à partir d'une sauvegarde ou exécuter des tests dessus, mais vous ne souhaitez pas que vos tests affectent l'instance sur laquelle la sauvegarde a été créée.

  • Vous souhaitez restaurer une instance qui possède des paramètres d'accès différents de l'instance source. Par exemple, vous pouvez accorder l'accès à des développeurs afin d'effectuer des tests, des opérations de débogage ou de développement à l'aide d'une table créée à partir d'une sauvegarde d'une table de production, tout en maintenant un accès limité à la table de production.

  • Vous voulez déplacer des données vers une autre région, mais vous ne souhaitez pas modifier la configuration de la réplication sur l'instance qui contient la sauvegarde. Vous pouvez restaurer la sauvegarde sur une instance contenant un cluster dans la région dans laquelle vous souhaitez stocker vos données.

  • Vous souhaitez copier certaines données d'une table restaurée à partir d'une sauvegarde et les écrire dans la table source. Par exemple, vous pouvez restaurer sur une autre instance, puis écrire une application à l'aide d'une bibliothèque cliente Bigtable ou de Dataflow qui lit la nouvelle table et écrit les données dans la table source. Cela peut être utile si seules certaines données sont corrompues ou si vous avez une autre raison de ne restaurer qu'une partie d'une table.

  • Vous souhaitez obtenir une copie de vos données sur une instance plus économique que celle que vous utilisez en production. Par exemple, supposons que vous disposiez d'une table de production de 700 To dans une instance comportant trois clusters SSD de 300 nœuds (300 nœuds x 2,5 To d'espace de stockage par nœud). Si vous n'avez pas besoin de réplication ni d'une faible latence pour la copie, vous pouvez restaurer une nouvelle table à partir de la sauvegarde sur une instance HDD à cluster unique comportant 88 nœuds (700 To ÷ 8 To de stockage par nœud). En revanche, si vous restaurez une copie de cette table de 700 To sur la même instance que la table source, vous devez effectuer un scaling à la hausse de 1 800 nœuds pour accepter la copie, ce qui augmente le coût de l'instance de production.

  • Vous souhaitez changer le type de stockage sur lequel vos données sont stockées. Vous pouvez utiliser des sauvegardes pour déplacer vos données depuis un disque SSD vers un stockage HDD, ou inversement. Pour ce faire, vous devez créer une sauvegarde de la table que vous souhaitez déplacer, puis la restaurer sur une instance qui utilise le type de stockage souhaité.

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 les opérations telles que la mise à jour et la suppression de sauvegardes.

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

Vous pouvez également accéder directement à l'API. Toutefois, nous vous conseillons vivement de n'employer cette méthode que dans le cas où vous ne pouvez pas utiliser une bibliothèque cliente Bigtable qui envoie des appels de sauvegarde à l'API.

Fonctionnement des sauvegardes

Stockage

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

Une sauvegarde de 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 où elle 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 qui dispose d'une sauvegarde. Pour protéger vos sauvegardes, vous ne pouvez pas supprimer un cluster contenant une sauvegarde ni une instance possédant une ou plusieurs sauvegardes dans un cluster.

Une sauvegarde existe toujours après sa restauration dans une nouvelle table. Vous pouvez la supprimer ou la laisser expirer lorsque vous n'en avez plus besoin. Le stockage des sauvegardes 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 et la restauration d'une sauvegarde sont gratuites.

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

Une sauvegarde est une copie logique complète d'une table. En arrière-plan, Bigtable optimise l'utilisation du stockage des sauvegardes. En effet, une sauvegarde partage l'espace de stockage physique avec la table d'origine ou avec d'autres sauvegardes de la table lorsque c'est possible. Grâce aux optimisations de stockage intégrées de Bigtable, le coût de sauvegarde peut parfois être inférieur au coût engendré par une copie physique complète de la sauvegarde de table.

Si vous restaurez une table dans une instance qui utilise la réplication, un coût de réplication ponctuel vous est facturé pour la copie des données dans tous les clusters dans l'instance.

Si vous effectuez une restauration sur une instance différente de celle où la sauvegarde a été créée, et que l'instance de la sauvegarde et l'instance de destination ne disposent pas d'au moins un cluster dans la même région, un coût unique vous est facturé pour la copie initiale des données sur le cluster de destination selon les tarifs réseau standards

CMEK

Lorsque vous créez une sauvegarde dans une instance protégée par une clé de chiffrement gérée par le client (CMEK), la sauvegarde est épinglée à la version principale de la clé CMEK de la table à l'instant où la sauvegarde est capturée. Une fois la sauvegarde créée, la clé et la version de clé associées ne peuvent plus être modifiées, même si la clé KMS est alternée.

Lorsque vous restaurez une table à partir d'une sauvegarde, la version de clé à laquelle la sauvegarde est épinglée doit être activée pour que le processus de déchiffrement de la sauvegarde fonctionne. La nouvelle table est protégée par la dernière version principale de la clé CMEK de l'instance cible. Cela signifie que si vous souhaitez effectuer une restauration à partir d'une sauvegarde protégée par une clé CMEK vers une autre instance, l'instance de destination doit utiliser la même clé CMEK que l'instance source.

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 sauvegardez une table d'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 où 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 peu 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 aux besoins de votre entreprise, 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.

Restaurer

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 où 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.

Restaurer

La restauration d'une sauvegarde dans une table 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. Bigtable choisit toujours la route la plus efficace pour copier des données.

Si vous effectuez une restauration sur une autre instance à partir de laquelle la sauvegarde a été créée, l'opération de restauration prend plus de temps que restaurer sur la même instance. Cela est particulièrement vrai si l'instance de destination ne dispose pas de cluster dans la même zone que le cluster dans lequel la sauvegarde a été créée.

La restauration d'une table plus grande prend plus de temps qu'une petite table.

Si vous stockez vos tables dans des clusters SSD, il est possible que la latence en lecture soit initialement supérieure, même après la restauration, pendant l'optimisation de la table. 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.

Si vous effectuez une restauration sur une autre instance à partir de laquelle la sauvegarde a été créée, l'instance de destination peut utiliser le stockage HDD ou SSD. Il n'est pas nécessaire d'utiliser le même type de stockage que l'instance source.

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.

Le compte que vous utilisez pour créer une sauvegarde de table doit être autorisé à lire la table et à créer des sauvegardes dans l'instance contenant la table (instance source).

Le compte que vous utilisez pour restaurer une table à partir d'une sauvegarde doit être autorisé à créer une table sur l'instance sur laquelle vous effectuez la restauration.

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, tenez compte des facteurs suivants avant de choisir le cluster dans lequel stocker la sauvegarde :
    • 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 souhaiterez peut-être stocker la sauvegarde le plus près 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 avec une utilisation de disque 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 exploite la réplication, utilisez un jeton de cohérence avec 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 bien préparé pour ne pas avoir à prendre de décision lorsqu'un problème surgit.
  • 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.
  • Si vous prévoyez d'effectuer la restauration sur une autre instance, créez l'instance de destination avant de lancer l'opération de sauvegarde/restauration.

Quotas et limites

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

Limites

Les limites suivantes s'appliquent aux sauvegardes Bigtable :

  • Vous ne pouvez pas lire directement les données d'une sauvegarde.
  • Vous ne pouvez pas effectuer de restauration à partir d'une sauvegarde sur une table existante.
  • Vous ne pouvez restaurer qu'une instance qui existe déjà. Bigtable ne crée pas d'instance lors de la restauration à partir d'une sauvegarde. Si l'instance de destination spécifiée dans une requête de restauration n'existe pas, l'opération de restauration échoue.
  • Si vous restaurez une sauvegarde dans une table d'un cluster SSD, puis supprimez la table nouvellement restaurée, la suppression de la table peut prendre un certain temps, car Bigtable attend la fin de son optimisation.
  • Les sauvegardes sont zonales et partagent les mêmes garanties de disponibilité que le cluster où elles sont créées. Les sauvegardes ne vous protègent pas contre les pannes régionales.
  • Une sauvegarde est une version d'une table au sein d'un cluster unique à un moment donné. Les sauvegardes ne représentent pas un état cohérent. Cela s'applique également aux sauvegardes d'une même table situées dans des clusters différents.
  • Vous ne pouvez pas sauvegarder plusieurs tables en une seule opération.
  • Vous ne pouvez pas exporter, copier ni déplacer une sauvegarde Bigtable vers un autre service, tel que Cloud Storage.

Étape suivante