Présentation des sauvegardes Bigtable

Cette page présente les sauvegardes Bigtable. Le contenu présenté ici est destiné aux administrateurs et aux développeurs Bigtable.

Les sauvegardes Bigtable vous permettent d'enregistrer une copie du schéma et des données d'une table, puis de la restaurer ultérieurement à partir de la sauvegarde dans une nouvelle table. Vous pouvez créer des sauvegardes manuellement ou activer la sauvegarde automatique pour permettre à Bigtable de créer des sauvegardes quotidiennes. Vous pouvez également créer une copie d'une sauvegarde.

Avant de lire cette page, vous devez vous familiariser avec la présentation de Bigtable et la section Gérer les tables.

Fonctionnalités

  • Intégration complète : les sauvegardes sont entièrement gérées par le service Bigtable, sans importation ni exportation.
  • Incrémentiel: une sauvegarde partage le stockage physique avec la table source et d'autres sauvegardes de la table.
  • 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 a une date d'expiration définie par l'utilisateur qui peut aller jusqu'à 90 jours après la création de la sauvegarde. Vous pouvez stocker une copie d'une sauvegarde pendant 30 jours maximum.
  • 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.
  • Sauvegarde automatique: activez la sauvegarde automatique pour permettre à Bigtable de créer des sauvegardes quotidiennes.

Cas d'utilisation

Les sauvegardes sont utiles pour les cas d'utilisation suivants:

  • Continuité des opérations
  • Conformité réglementaire
  • Tests et développement
  • Reprise après sinistre

Envisagez les scénarios de reprise après sinistre suivants:

Objectif Stratégie de sauvegarde Stratégie de restauration
Protection contre les erreurs humaines : nous vous conseillons de toujours disposer d'une sauvegarde récente de vos données en cas de suppression ou de corruption accidentelle. Déterminez le calendrier de création des sauvegardes adapté aux besoins de votre entreprise, par exemple quotidiennement. Vous pouvez également créer des copies périodiques des sauvegardes et les stocker dans un autre projet ou une autre région pour renforcer l'isolation et la protection. Pour une protection supplémentaire, stockez les copies de sauvegarde dans un projet ou une instance avec des autorisations d'accès limitées. Restaurez dans une nouvelle table à partir de la sauvegarde ou de la copie, puis réacheminez les requêtes vers la nouvelle table.
Indisponibilité de la zone : vous devez vous assurer que vos données restent disponibles dans le cas peu probable où une zone Google Cloud devient indisponible. Créez des sauvegardes régulièrement, par exemple quotidiennement. Ensuite, créez régulièrement une copie de la sauvegarde la plus récente et stockez-la sur un ou plusieurs clusters dans différentes zones (éventuellement dans une autre instance ou un autre projet). Si la zone dans laquelle votre cluster de diffusion devient indisponible, restaurez-la à partir de la copie de sauvegarde à distance vers une nouvelle table, puis réacheminez les requêtes vers la nouvelle table.
corruption des données : utilisez une sauvegarde pour récupérer certaines données d'une table, par exemple lorsqu'une partie de la table source a été corrompue. Créez régulièrement des sauvegardes de vos données. Effectuez une restauration à partir de la sauvegarde dans une nouvelle table de la nouvelle instance. Ensuite, écrivez une application à l'aide d'une bibliothèque cliente Bigtable ou de Dataflow, qui lit les données dans la nouvelle table, puis les réécrit dans la table source. Une fois les données copiées dans la table d'origine, supprimez la nouvelle table.

Utiliser les sauvegardes Bigtable

Les actions suivantes sont disponibles pour les sauvegardes Bigtable. Dans tous les cas, le projet, l'instance et le cluster de destination doivent déjà exister. Vous ne pouvez pas créer ces ressources dans le cadre d'une opération de sauvegarde. Vous ne pouvez pas créer de copie d'une copie de sauvegarde.

Action Options de destination
Créer une sauvegarde
  • Tout cluster de la même instance que la table source
Restaurer à partir d'une sauvegarde dans une nouvelle table
  • N'importe quelle instance
  • N'importe quelle région Bigtable
  • Tout projet
Copier une sauvegarde
  • N'importe quelle instance
  • N'importe quelle région Bigtable
  • Tout projet

Consultez la page Gérer les sauvegardes pour obtenir des instructions détaillées sur ces actions, ainsi que sur les opérations telles que la mise à jour et la suppression des sauvegardes.

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

Vous pouvez également accéder directement à l'API Cloud Bigtable Admin, mais nous vous recommandons vivement de ne le faire que si vous ne pouvez pas utiliser une bibliothèque cliente Cloud Bigtable qui effectue des appels de sauvegarde vers l'API.

Fonctionnement des sauvegardes Bigtable

Pour créer une sauvegarde, vous devez comprendre le stockage et la conservation des sauvegardes dans Bigtable.

Stockage des sauvegardes

Une sauvegarde de table peut être créée manuellement ou vous pouvez activer la sauvegarde automatique pour permettre à Bigtable d'effectuer des sauvegardes quotidiennes. Une sauvegarde de table est stockée sur le cluster d'une instance. En cas de sauvegardes manuelles, la sauvegarde de table est stockée sur un cluster de l'instance sélectionnée. Lorsque la sauvegarde automatique est activée, une sauvegarde de table est stockée sur chaque cluster de l'instance.

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.

Les sauvegardes Bigtable sont incrémentielles. L'espace de stockage consommé par une sauvegarde dépend de la taille de la table et de la mesure dans laquelle elle peut partager le stockage de données inchangées avec la table d'origine ou d'autres sauvegardes de la même table. Pour cette raison, la taille d'une sauvegarde dépend de la quantité de données divergentes depuis la sauvegarde précédente.

Vous pouvez créer jusqu'à 150 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 les supprimer ou les laisser expirer lorsque vous n'en avez plus besoin. Le stockage des sauvegardes n'est pas comptabilisé dans la limite de stockage des nœuds d'un projet.

Les données contenues dans les sauvegardes sont chiffrées.

Conservation

Vous pouvez spécifier une durée de conservation maximale de 90 jours pour une sauvegarde. Si vous créez une copie d'une sauvegarde, la période de conservation maximale de la copie est de 30 jours à compter de sa création.

Pour les tables sur lesquelles la sauvegarde automatique est activée, la durée de conservation par défaut est de trois jours. Vous pouvez modifier la durée de conservation d'une sauvegarde jusqu'à 90 jours à compter de la date de création de la sauvegarde.

Stockage post-restauration

Le coût de stockage d'une nouvelle table restaurée à partir d'une sauvegarde est le même que pour n'importe quelle table.

Une table restaurée à partir d'une sauvegarde peut ne pas consommer la même quantité de stockage que la table d'origine, et sa taille peut diminuer après la restauration. La différence de taille dépend de la survenue récente du compactage sur le cluster source et le cluster de destination.

Comme le compactage est effectué de manière progressive, il est possible que le compactage se produise dès la création de la table. Toutefois, le compactage peut prendre jusqu'à une semaine.

Coûts

Les frais de réseau standards s'appliquent lorsque vous utilisez des sauvegardes. Les opérations de sauvegarde, y compris la création, la copie ou la restauration d'une sauvegarde, ne vous sont pas facturées.

Coûts de stockage

Pour stocker une sauvegarde ou une copie d'une sauvegarde, des frais vous sont facturés au tarif de stockage de sauvegarde standard pour la région dans laquelle se trouve le cluster contenant la sauvegarde ou la copie de sauvegarde.

Une sauvegarde est une copie logique complète d'une table. En arrière-plan, Bigtable optimise l'utilisation du stockage des sauvegardes. Cette optimisation signifie qu'une sauvegarde est incrémentielle : elle partage l'espace de stockage physique avec la table d'origine ou avec d'autres sauvegardes de la table dans la mesure du possible. En raison des optimisations de stockage intégrées de Bigtable, le coût de stockage d'une sauvegarde ou d'une copie d'une sauvegarde peut parfois être inférieur au coût d'une copie physique complète de la sauvegarde de table.

Dans les instances répliquées où la sauvegarde automatique est activée, les coûts de stockage peuvent être plus élevés, car des sauvegardes sont créées quotidiennement sur chaque cluster.

Coûts liés à la copie d'une sauvegarde

Lorsque vous créez une copie d'une sauvegarde dans une région différente de celle de la sauvegarde source, les tarifs de réseau standards pour le coût de la copie des données vers le cluster de destination vous sont facturés. Le trafic réseau ne vous est pas facturé lorsque vous créez une copie dans la même région que la sauvegarde source.

Frais de restauration

Lorsque vous restaurez une nouvelle table à partir d'une sauvegarde, les frais de réplication du réseau vous sont facturés. Si la nouvelle table se trouve dans une instance qui utilise la réplication, des frais de réplication uniques vous sont facturés pour la copie des données dans tous les clusters de l'instance.

Si vous restaurez sur une instance différente de celle où la sauvegarde a été créée, et que l'instance de sauvegarde et l'instance de destination n'ont pas au moins un cluster dans la même région, des frais uniques vous sont facturés pour la copie de données initiale sur le cluster de destination aux tarifs standards du réseau.

CMEK

Lorsque vous créez une sauvegarde dans un cluster protégé par une clé de chiffrement gérée par le client (CMEK ou "Customer-Managed Encryption Key"), la sauvegarde est épinglée à la version principale de la clé CMEK du cluster au moment de sa création. Une fois la sauvegarde créée, la clé et la version de clé associées ne peuvent plus être modifiées, même si une rotation de clé KMS est appliquée.

Lorsque vous effectuez une restauration à 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 pour chaque cluster de l'instance de destination. Si vous souhaitez effectuer une restauration à partir d'une sauvegarde protégée par une clé CMEK sur une autre instance, l'instance de destination doit également être protégée par la clé CMEK, mais ne doit pas nécessairement avoir la même configuration 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.

Réplication et sauvegarde

Lorsque vous sauvegardez manuellement une table dans une instance répliquée, vous choisissez le cluster dans lequel vous souhaitez créer et stocker la sauvegarde. Pour les tables où la sauvegarde automatique est activée, une sauvegarde quotidienne est effectuée sur chaque cluster de l'instance.

Il n'est pas nécessaire d'interrompre les opérations d'écriture dans le cluster contenant la sauvegarde, mais vous devez comprendre 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 é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. Cela est également vrai pour les sauvegardes créées lorsque la sauvegarde automatique est activée. Les sauvegardes d'une instance ne sont pas des copies exactes, car la durée des sauvegardes peut varier d'un cluster à l'autre.

Si cette incohérence n'est pas acceptable pour les besoins de votre entreprise, vous pouvez utiliser un jeton de cohérence avec vos requêtes d'écriture pour vous assurer que toutes les écritures répliquées sont incluses dans une sauvegarde.

Réplication et 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 de destination.

Performances

Lorsque vous créez des sauvegardes, appliquez les bonnes pratiques suivantes pour vous assurer que vos performances restent optimales.

Performances lors de la sauvegarde

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 de sauvegarde d'une table unique 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.

Performances lors de la restauration

La restauration d'une sauvegarde dans une table d'une instance à cluster unique prend quelques minutes. Dans les instances répliquées, 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 disposez d'une instance 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 copier une sauvegarde doit être autorisé à lire la sauvegarde source, et à en créer une dans l'instance et le projet de destination.

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
Copier une sauvegarde bigtable.backups.read, bigtable.backups.create
Restaurer à partir d'une sauvegarde dans une nouvelle table bigtable.tables.create, bigtable.backups.restore
Obtenir une opération bigtable.instances.get
Répertorier les opérations bigtable.instances.get

Bonnes pratiques

Vous devez prendre connaissance des bonnes pratiques suivantes avant de créer une stratégie de sauvegarde.

Créer des 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 vos sauvegardes à mesure qu'elles s'accumulent. 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 utilise la réplication, utilisez un jeton de cohérence avec vos requêtes d'écriture.

Restaurer à partir de 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 :

Général

  • Vous ne pouvez pas lire directement à partir d'une sauvegarde.
  • 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.
  • Les sauvegardes Bigtable ne contiennent que des données Bigtable et ne sont pas intégrées aux sauvegardes d'autres services Google ni liées à celles-ci.

Restauration

  • Vous ne pouvez pas effectuer de restauration à partir d'une sauvegarde dans 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.

Copie

  • Vous ne pouvez pas créer la copie d'une sauvegarde arrivée à expiration dans les 24 heures.
  • Vous ne pouvez pas créer de copie d'une copie de sauvegarde.

CMEK

  • Une sauvegarde protégée par une clé CMEK doit être restaurée dans une nouvelle table d'une instance protégée par une clé CMEK.
  • Lorsque vous créez une copie d'une sauvegarde protégée par une clé CMEK, le cluster de destination doit également l'être.

Étapes suivantes