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, et d'effectuer une restauration vers une nouvelle table par la suite. Bigtable propose deux types de sauvegardes. Le type de sauvegarde que vous créez dépend de vos exigences en matière de reprise après sinistre 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 restaurez une sauvegarde standard dans un cluster SSD, l'opération de restauration nécessite une optimisation supplémentaire par Bigtable pour que la table atteigne un niveau de performances adapté à la production. Pour en savoir plus, consultez Performances lors de la restauration.
Les sauvegardes à chaud permettent une restauration plus efficace, avec des performances adaptées à la production et une livraison à faible latence. Pour en savoir plus, consultez 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 pour vous.
Créez une sauvegarde à la demande à l'aide de la console Google Cloud , de la gcloud CLI ou d'une bibliothèque cliente Bigtable.
Créez 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 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 de créer des sauvegardes quotidiennes.
Sauvegardes à chaud : planifiez la reprise après sinistre avec des sauvegardes à chaud prêtes pour la 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

Voici quelques scénarios de reprise après sinistre :

Objectif	Stratégie de sauvegarde	Stratégie de restauration
Protection contre les erreurs humaines : vous devez toujours disposer d'une sauvegarde récente de vos données en cas de suppression ou de corruption accidentelle.	Déterminez la fréquence de création des sauvegardes qui correspond aux besoins de votre entreprise (par exemple, tous les jours). Vous pouvez également créer des copies périodiques des sauvegardes et les stocker dans un autre projet ou une autre région pour une isolation et une protection accrues. 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 réacheminez les requêtes vers la nouvelle table.
Indisponibilité d'une zone : vous devez vous assurer que vos données restent disponibles dans le cas peu probable où une zone Google Cloud devient indisponible.	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ères, 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 votre cluster de diffusion devient indisponible, restaurez la copie de sauvegarde à distance dans une nouvelle table, puis redirigez les requêtes vers la nouvelle table.
Données corrompues : utilisez une sauvegarde pour récupérer une partie des données d'une table, par exemple lorsqu'une partie de la table source a été 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 plusieurs sauvegardes qui ne partagent pas de stockage sur le cluster corrompu.	Restaurez à partir de la sauvegarde dans une nouvelle table du nouveau cluster ou de la nouvelle instance. 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.
Restauration rapide : restaurez rapidement les niveaux de performances de production complets, ce qui minimise les temps d'arrêt.	Conservez toujours une sauvegarde à chaud récente de votre table.	Restaurez la sauvegarde à chaud dans une nouvelle table, puis redirigez les requêtes vers cette nouvelle table.

Sauvegardes à chaud

Une sauvegarde à chaud est une sauvegarde prête pour la production, optimisée pour une récupération rapide et offrant une latence plus faible lors de la lecture à partir de la nouvelle table peu de temps après la restauration. La restauration des performances de production à partir d'une sauvegarde à chaud est plus rapide qu'à partir d'une sauvegarde standard.

Vous pouvez convertir une sauvegarde à chaud en sauvegarde standard, mais pas l'inverse.

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

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. La 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 N'importe quel projet
Copier une sauvegarde^{1, 2}	Toute instance N'importe quelle région Bigtable N'importe quel 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.

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

La console Google Cloud
Google Cloud CLI
Bibliothèques clientes Cloud Bigtable

Stockage des sauvegardes

Une sauvegarde de table que vous créez manuellement ou par programmation est stockée sur un seul cluster que vous spécifiez. Lorsqu'une sauvegarde automatique est activée, une sauvegarde est stockée sur chaque cluster de l'instance.

Si votre cluster dépasse les limites recommandées pour l'utilisation du processeur ou de l'espace de stockage lorsque vous créez une sauvegarde, la création de votre sauvegarde peut être retardée. Pour en savoir plus, consultez Comprendre l'utilisation du processeur et du disque.

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. La quantité d'espace de stockage qu'une sauvegarde 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.

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 la date de création de la copie.

Vous pouvez modifier la période de conservation d'une sauvegarde pour la conserver jusqu'à 90 jours après sa date de création. Pour en savoir plus, consultez Modifier une sauvegarde ou une copie de sauvegarde.

Pour les tables dont la sauvegarde automatique est activée, la période de conservation est de sept jours si vous définissez la règle à l'aide de l'indicateur --enable-automated-backup. Vous pouvez définir une période de conservation personnalisée en transmettant l'indicateur --automated-backup-retention-period, qui accepte une valeur comprise entre 3 et 90 jours. Pour en savoir plus, consultez Modifier une règle de sauvegarde automatique.

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 de mémoire de la table source. Configurez des stratégies de récupération de mémoire dans la nouvelle table avant de commencer à y écrire des données. Pour en savoir plus, consultez 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 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 de 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 de sauvegarde peut parfois être inférieur au coût engendré par une copie physique complète de la sauvegarde de table.

Dans les instances répliquées pour lesquelles 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 et optimisée pour une restauration rapide, vous êtes facturé pour le stockage de la copie logique complète de la table, et non pour les parties 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 vers le cluster de destination. Aucuns frais de trafic réseau ne vous sont facturés lorsque vous créez une copie dans la même région que la sauvegarde source.

Coûts de 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 une sauvegarde dans une instance différente de celle où elle 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 vers 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 dont la sauvegarde automatique est activée, une sauvegarde quotidienne est créé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 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 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.

Les sauvegardes de 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 heures 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.

Performances

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

Avant de créer une stratégie de sauvegarde, tenez compte des bonnes pratiques suivantes. Pour en savoir plus sur la planification de la reprise après sinistre, consultez la section Bigtable de la page Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud.

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.
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.
Pour éviter de ralentir la restauration de tables, attendez qu'une opération de restauration soit terminée avant d'en lancer une autre pour la même table source dans la même zone.
Attendez au moins une heure après la création avant de restaurer à partir d'une sauvegarde standard. Si vous devez effectuer une restauration plus rapidement, utilisez plutôt une sauvegarde à chaud.

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.
Vous ne pouvez pas créer de sauvegarde d'une vue.

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 moins de 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 être protégé par une clé CMEK.