Cette page a été traduite par l'API Cloud Translation.

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 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. Bigtable propose deux types de sauvegardes. Le type de sauvegarde que vous créez dépend de vos exigences de reprise après sinistre (PRA) et du type de stockage (HDD ou SSD) utilisé par votre cluster Bigtable.

Les sauvegardes standards sont optimisées pour la conservation à long terme. Lorsque vous effectuez une restauration à partir d'une sauvegarde standard vers un cluster SSD, Bigtable doit effectuer une optimisation supplémentaire pour que la table atteigne des performances de niveau de production. Pour en savoir plus, consultez la section Performances lors de la restauration.
Les sauvegardes à chaud offrent la restauration la plus efficace des performances de production et un service à faible latence. Pour en savoir plus, consultez la section Sauvegardes à chaud.

Vous pouvez créer des sauvegardes de différentes manières:

Activez la sauvegarde automatique pour que Bigtable crée des sauvegardes quotidiennes à votre place.
Créez une sauvegarde à la demande à l'aide de la console Google Cloud, de gcloud CLI ou d'une bibliothèque cliente Bigtable.
Créer une copie d'une sauvegarde

Avant de lire cette page, vous devez avoir consulté la présentation de Bigtable et la gestion des tables.

Fonctionnalités

Intégration complète : les sauvegardes sont entièrement gérées par le service Bigtable, sans importation ni exportation.
Incrémentielle: 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 est associée à une date d'expiration définie par l'utilisateur, pouvant 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.
Sauvegardes à chaud: planifiez la reprise après sinistre avec des sauvegardes à chaud prêtes à être utilisées en production.

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érons les scénarios de reprise après sinistre suivants:

Objectif	Stratégie de sauvegarde	Stratégie de restauration
Protégez-vous contre les erreurs humaines : vous devez toujours avoir une sauvegarde récente de vos données à portée de main 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 quotidien. Vous pouvez également créer des copies périodiques des sauvegardes et les stocker dans un projet ou une région différents pour une isolation et une protection renforcées. Pour une protection encore plus efficace, 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 redirigez les requêtes vers la nouvelle table.
Indisponibilité de la zone : vous devez vous assurer que, dans l'éventualité peu probable qu'une zone Google Cloud devienne indisponible, vos données restent disponibles.	Activez la sauvegarde automatique pour permettre à Bigtable de créer une sauvegarde quotidienne sur chaque cluster de l'instance. Vous pouvez également créer des sauvegardes régulièrement, puis créer périodiquement une copie de la sauvegarde la plus récente et la stocker sur un ou plusieurs clusters dans différentes zones (éventuellement dans une autre instance ou un autre projet).	Si la zone dans laquelle se trouve votre cluster de traitement devient indisponible, restaurez la copie de sauvegarde distante dans une nouvelle table, puis redirigez les requêtes vers la nouvelle table.
Corruption de données : utilisez une sauvegarde pour récupérer certaines données d'une table, par exemple lorsqu'une partie de la table source est corrompue.	Activez la réplication et la sauvegarde automatique pour créer des sauvegardes quotidiennes dans plusieurs régions. Ainsi, si une table est corrompue sur un cluster, vous disposez d'une ou de plusieurs sauvegardes qui ne partagent pas l'espace de stockage du cluster corrompu.	Restaurez à partir de la sauvegarde dans une nouvelle table sur le nouveau cluster ou l'instance. Vous créez ensuite une application à l'aide d'une bibliothèque cliente Bigtable ou de Dataflow qui lit les données de 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.
Récupération rapide : rétablissez rapidement les niveaux de performances de production, ce qui réduit les temps d'arrêt.	Conservez toujours une sauvegarde active récente de votre table.	Restaurez dans une nouvelle table à partir de la sauvegarde active, puis redirigez les requêtes vers la nouvelle table.

Sauvegardes à chaud

Une sauvegarde à chaud est une sauvegarde prête à être mise en production, optimisée pour une récupération rapide, avec une latence plus faible lors de la lecture à partir de la nouvelle table peu de temps après la restauration. Il est plus rapide de restaurer les performances de production à partir d'une sauvegarde à chaud que d'une sauvegarde standard.

Vous pouvez convertir une sauvegarde en mode "hot" en sauvegarde standard, mais pas une sauvegarde standard en sauvegarde en mode "hot".

Vous ne pouvez pas créer de sauvegardes à chaud à l'aide de la sauvegarde automatique, ni de sauvegarde à chaud sur un cluster de disques durs.

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.

Action	Options de destination
Vous ne pouvez pas créer de copie d'une copie de sauvegarde. Une copie d'une sauvegarde est toujours une sauvegarde standard, même si la source est une sauvegarde à chaud.
Créer une sauvegarde standard	Tout cluster de la même instance que la table source
Créer une sauvegarde à chaud	Tout cluster de la même instance que la table source. L'instance doit utiliser le stockage SSD.
Restaurer à partir d'une sauvegarde standard ou à chaud dans une nouvelle table	Toute instance N'importe quelle région Bigtable Tout projet
Copier une sauvegarde^{1, 2}	Toute 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 de sauvegardes.

Stockage des sauvegardes

Une sauvegarde de table que vous créez à la demande est stockée sur un seul cluster que vous spécifiez. Lorsque la sauvegarde automatique est activée, une sauvegarde est créée et 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 standards sont incrémentielles. La quantité d'espace de stockage qu'une sauvegarde standard consomme dépend de la taille de la table et de la mesure dans laquelle elle peut partager le stockage des données inchangées avec la table d'origine ou d'autres sauvegardes de la même table. C'est pourquoi la taille d'une sauvegarde dépend de la quantité de données divergentes par rapport à la sauvegarde précédente.

En revanche, une sauvegarde à chaud est une copie complète qui consomme la même quantité d'espace de stockage au moment de la sauvegarde, quel que soit le nombre de modifications apportées à la table source. La sauvegarde est considérée comme active en raison de son stockage optimisé, qui vous permet de restaurer efficacement les niveaux de performances de production.

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

Fidélisation

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 de la copie est de 30 jours à compter de sa création.

Pour les tables dont la sauvegarde automatique est activée, la période de conservation par défaut est de trois jours. Vous pouvez modifier la durée de conservation d'une sauvegarde pour la conserver jusqu'à 90 jours après sa création.

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 des règles de récupération des déchets de la table source. Configurez les stratégies de récupération de mémoire dans la nouvelle table avant de commencer à y écrire de nouvelles données. Pour en savoir plus, consultez la section Configurer le garbage collection.

Coûts

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

Coûts de stockage

Les coûts de stockage sont différents pour les sauvegardes standards et les sauvegardes à chaud.

Coûts de stockage des sauvegardes standards

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

Une sauvegarde standard est une copie logique complète d'une table. En arrière-plan, Bigtable optimise l'utilisation du stockage des sauvegardes standards. Cette optimisation signifie qu'une sauvegarde standard est incrémentielle : elle 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 stockage d'une sauvegarde standard 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 une sauvegarde est créée quotidiennement sur chaque cluster.

Coûts de stockage des sauvegardes à chaud

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

Étant donné qu'une sauvegarde à chaud est stockée dans un état prêt, optimisé pour une restauration rapide, vous êtes facturé pour le stockage de l'intégralité de la copie logique de la table, et non pour des portions incrémentielles, comme c'est le cas avec une sauvegarde standard.

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 réseau standards vous sont facturés pour le coût de la copie des données sur le cluster de destination. 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.

Coûts 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 effectuez une restauration sur une autre instance que celle à partir de laquelle la sauvegarde a été créée, et que l'instance de la sauvegarde et l'instance de destination ne comportent pas au moins un cluster dans la même région, un montant unique vous est facturé pour la copie initiale des données dans le cluster de destination aux 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 dupliquée, vous choisissez le cluster dans lequel vous souhaitez créer et stocker la sauvegarde. Pour les tables dont la sauvegarde automatique est activée, une sauvegarde est créée quotidiennement sur chaque cluster de l'instance.

Vous n'avez pas besoin d'arrêter d'écrire dans le cluster contenant la sauvegarde, mais vous devez comprendre comment Bigtable gère 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 cette incohérence n'est pas acceptable pour vos exigences métier, 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.

Les sauvegardes des tables répliquées créées dans le cadre d'une sauvegarde automatique ne sont pas des copies exactes les unes des autres, car les délais de sauvegarde peuvent varier d'un cluster à l'autre.

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

Lorsque vous créez des sauvegardes, suivez les bonnes pratiques suivantes pour 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 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.

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 à créer une sauvegarde 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 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 exploite 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 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 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.

Copier

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 CMEK, le cluster de destination doit également être protégé par CMEK.