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 permettent d'enregistrer une copie le schéma et les données d'une table, puis d'effectuer une restauration à partir de la sauvegarde vers une nouvelle table plus tard. Vous pouvez créer des sauvegardes manuellement ou activer pour permettre à Bigtable de créer des sauvegardes quotidiennes. Vous pouvez aussi créer une copie d'une sauvegarde.

Avant de lire cette page, vous devez connaître les Présentation de Bigtable et Gérer de données.

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 l'espace de 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 possède une date d'expiration définie par l'utilisateur qui jusqu'à 90 jours après la création de la sauvegarde. Toi peuvent conserver 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 crée des sauvegardes quotidiennes.

Cas d'utilisation

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

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

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

Objectif Stratégie de sauvegarde Stratégie de restauration
Vous protéger contre les erreurs humaines : vous devez toujours Gardez une sauvegarde récente de vos données à portée de main en cas d'incident sa suppression ou sa corruption. Déterminez le calendrier de création des sauvegardes adapté à votre les besoins de l'entreprise, par exemple, tous les jours. Si vous le souhaitez, créez des copies périodiques de les sauvegardes et les stocker dans un autre projet ou une autre région une isolation et une protection accrues. Pour encore plus de protection, stockez la sauvegarde des copies dans un projet ou une instance avec des autorisations d'accès restreintes. Restaurez dans une nouvelle table à partir de la sauvegarde ou de la copie, puis réacheminez vers la nouvelle table.
Indisponibilité de la zone : assurez-vous que dans dans l'éventualité peu probable qu'une zone Google Cloud soit indisponible, vos données restent disponibles. Créez des sauvegardes régulières, par exemple tous les jours. Ensuite, périodiquement créer une copie de la sauvegarde la plus récente et la stocker sur un ou plusieurs des clusters dans différentes zones (éventuellement dans une autre instance ou projet). Si la zone dans laquelle votre cluster de diffusion devient indisponible, restaurez de la copie de sauvegarde distante vers une nouvelle table, puis réacheminer vers la nouvelle table.
Cupture de données : utilisez une sauvegarde pour procéder à une récupération. certaines données d'une table, par exemple lorsqu'une partie de la table source comporte risque de s'endommager. Créez régulièrement des sauvegardes de vos données. Restaurez à partir de la sauvegarde dans une nouvelle table sur la nouvelle instance. Ensuite, écrire une application à l'aide d'une bibliothèque cliente Bigtable Dataflow, qui lit les données puis réécrit les données dans la table source. Lorsque données ont été copiées dans le tableau d'origine, supprimez le nouveau tableau.

Utiliser les sauvegardes Bigtable

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

Action Options de destination
Créer une sauvegarde
  • Tout cluster situé dans 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
  • N'importe quel projet
Copier une sauvegarde
  • N'importe quelle instance
  • N'importe quelle région Bigtable
  • N'importe quel projet

Consultez l'article Gérer les sauvegardes pour obtenir des instructions détaillées sur ces actions, ainsi que des opérations telles que la mise à jour supprimer 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 le faire. uniquement si vous ne pouvez pas utiliser une bibliothèque cliente Cloud Bigtable qui crée 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 Bigtable.

Stockage des sauvegardes

Vous pouvez créer une sauvegarde de table manuellement, ou activer la sauvegarde automatique pour permettre pour effectuer des sauvegardes quotidiennes. Une sauvegarde de table est stockée dans un cluster Compute Engine. Dans le cas des sauvegardes manuelles, la sauvegarde de votre table est stockée dans un cluster du que vous sélectionnez. Lorsque la sauvegarde automatique est activée, une sauvegarde de table est stockée sur chaque un 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 utilisée par une sauvegarde dépend de la taille de la table et de l'étendue il peut partager le stockage de données non modifiées avec la table d'origine ou d'autres sauvegardes d'une même table. Pour cette raison, la taille d'une sauvegarde dépend de la quantité des données divergentes depuis la précédente sauvegarde.

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 supprimer ou bien la laisser expirer lorsque vous n'en avez plus besoin. Le stockage des sauvegardes ne compte pas de 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 durée de conservation maximale pour le pendant 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 3 jours. Vous pouvez modifier la durée de conservation d'une sauvegarde jusqu'à 90 jours au moment de la 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.

Une nouvelle table restaurée à partir d'une sauvegarde n'hérite pas de la récupération de mémoire de la table source. Configurer les stratégies de récupération de mémoire dans le nouveau avant de commencer à écrire de nouvelles données dans la table. Pour en savoir plus, consultez Configurez la récupération de mémoire.

Coûts

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

Coûts de stockage

Pour stocker une sauvegarde ou une copie d'une sauvegarde, le montant de la sauvegarde standard de stockage pour la région dans laquelle le cluster sauvegarde ou une 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 de les optimisations de stockage intégrées de Bigtable, le coût de stockage d'une sauvegarde ou d'une copie d'une sauvegarde peut être inférieure au coût d'une physique 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, vous êtes facturé au tarif standard du réseau pour le coût de copie des données cluster de destination. Le trafic réseau ne vous est pas facturé lorsque vous créez un dans la même région que la sauvegarde source.

Coûts liés à la 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 l'instance de sauvegarde et l'instance de destination n'ont pas au moins dans un cluster de la même région, vous payez un coût unique pour les données initiales copiez-les dans le cluster de destination en respectant les tarifs réseau standards.

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 créer et stocker la sauvegarde. Pour les tableaux avec sauvegarde automatique activée, une sauvegarde est effectuée quotidiennement sur chaque cluster du Compute Engine.

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 auquel 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 s'applique également aux sauvegardes créées lorsque la sauvegarde automatique est activée. Les sauvegardes d'une instance ne sont pas des copies exactes les unes des autres car les délais de sauvegarde peuvent varier d'un cluster à l'autre.

Si cette incohérence n'est pas acceptable pour les besoins de votre entreprise, vous pouvez utiliser une cohérence à vos requêtes d'écriture pour vous assurer que toutes les instances répliquées les écritures 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.

Performance

Lors de la création de sauvegardes, appliquez les bonnes pratiques suivantes pour vous assurer que les 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 seule table plus de 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 ont 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 le source, créer une sauvegarde dans l'instance de destination, projet.

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 en compte les 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, jeton de cohérence à 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

  • Il n'est pas possible de lire directement les données 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 restaurer à 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 de copie d'une sauvegarde qui expire 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, la destination doit également être protégé par des clés CMEK.

Étape suivante