Sauvegarde et restauration

Aperçu

La fonctionnalité de sauvegarde et de restauration de Cloud Spanner vous permet de créer des sauvegardes de bases de données Cloud Spanner à la demande et de les restaurer pour assurer une protection contre les erreurs d'opérateur et d'application, ce qui entraîne une corruption de données logique. Les sauvegardes sont hautement disponibles, chiffrées et peuvent être conservées jusqu'à un an après leur création. Si vous avez besoin de temps de conservation plus long, nous vous recommandons d'exporter votre base de données.

Vous pouvez utiliser Sauvegarde et restauration des manières suivantes :

Principales fonctionnalités

  • Cohérence des données : les sauvegardes sont une copie transactionnelle et cohérente en externe d'une base de données Cloud Spanner au niveau du create_time de la sauvegarde.

  • Réplication : les sauvegardes se trouvent dans la même instance que leur base de données source et sont répliquées dans les mêmes emplacements géographiques. Pour les instances régionales, une copie de la sauvegarde est stockée dans chacune des trois zones en lecture/écriture. Pour les instances multirégionales, une copie est stockée dans toutes les zones contenant une instance dupliquée en lecture/écriture ou en lecture seule.

  • Expiration automatique : la date d'expiration spécifiée par l'utilisateur détermine la date de suppression automatique de toutes les sauvegardes.

Choisir entre Sauvegarde et restauration et Importation et exportation

La fonctionnalité Importation et Exportation de Cloud Spanner propose des cas d'utilisation semblables à ceux de la fonctionnalité de sauvegarde et de restauration. Le tableau suivant décrit les similitudes et les différences entre elles pour vous aider à choisir celle à utiliser.

Sauvegarde et restaurationImportation et exportation
Cohérence des données Les sauvegardes et les bases de données exportées sont cohérentes sur le plan transactionnel et externe.
Impact sur la performance Les deux s'exécutent avec une faible priorité afin de minimiser l'impact sur les performances de la base de données. L'exportation utilise un processeur utilisateur à faible priorité, tandis que la sauvegarde utilise le processeur système à faible priorité. Pour plus d'informations, consultez la section Priorité des tâches.
Format de stockage Utilise un format propriétaire et chiffré conçu pour une restauration rapide. Compatible avec les formats de fichiers CSV et Avro.
Portabilité Les sauvegardes résident dans la même instance que leur base de données source et ne peuvent pas être déplacées.

Vous pouvez restaurer une base de données vers n'importe quelle instance du projet avec la même configuration d'instance que la sauvegarde.
Les bases de données exportées résident dans Google Cloud Storage et les données peuvent être migrées vers n'importe quel système compatible avec CSV ou Avro.
Retention Les sauvegardes peuvent être conservées jusqu'à un an. Les bases de données exportées sont stockées dans Cloud Storage. Par défaut, elles sont conservées jusqu'à leur suppression. Vous pouvez personnaliser les règles de cycle de vie et de conservation.
Billing Les sauvegardes sont facturées à votre projet Cloud Spanner en fonction de l'espace de stockage utilisé par unité de temps. Pour en savoir plus, consultez la section Facturation. La facturation de l'importation et de l'exportation est plus complexe du fait de son utilisation de Google Cloud Storage et de Dataflow. Pour en savoir plus, consultez la section Tarifs d'exportation et d'importation de bases de données.
Date de restauration La restauration s'effectue en deux étapes : la restauration et l'optimisation. L'opération de restauration présente un temps de latence du premier octet faible, car la base de données installe directement la sauvegarde sans copier les données. Une fois l'opération de restauration terminée, la base de données est prête à l'emploi, même si la latence de lecture peut être légèrement supérieure lors de l'optimisation. Pour plus d'informations, consultez la page Fonctionnement de la restauration. L'importation est plus lente. Vous devez attendre que toutes les données soient écrites dans la base de données.

Fonctionnement de la sauvegarde

Contenu

Les utilisateurs peuvent créer une sauvegarde de n'importe quelle base de données Cloud Spanner. Ces sauvegardes sont complètes, car elles contiennent toutes les données de la base de données (y compris le schéma et les index secondaires) à l'heure de création (create_time) de la sauvegarde. Toute modification apportée aux données ou au schéma après la création de la sauvegarde ne sera pas incluse. Les sauvegardes ne contiennent pas de métadonnées de base de données, telles que des stratégies Identity and Access Management (IAM).

Processus de création

Lorsque vous créez une sauvegarde, vous devez spécifier une base de données source, un nom pour la ressource de sauvegarde et une date d'expiration (jusqu'à un an à partir de la date de création de la sauvegarde). Le système crée une ressource de sauvegarde et une opération de sauvegarde de longue durée pour suivre la progression de la sauvegarde.

Pour garantir la cohérence externe de la sauvegarde, Cloud Spanner épingle le contenu de la base de données au moment de la création. Cela empêche le système de récupération de mémoire de supprimer les valeurs de données pertinentes pour la durée de l'opération de sauvegarde. Ensuite, chaque zone de l'instance commence à copier les données en parallèle. Si une zone est temporairement indisponible, la sauvegarde n'est pas complète tant que la zone n'est pas de nouveau en ligne et terminée. Les sauvegardes sont récupérables dès que l'opération est terminée.

Hiérarchie des ressources

Les sauvegardes sont des ressources dans Cloud Spanner. Chaque ressource de sauvegarde est organisée sous la même instance que sa base de données source dans la hiérarchie des ressources, et elle dispose d'un chemin d'accès de ressource au format projects/<project>/instances/<instance>/backups/<backup>. Une sauvegarde existe toujours même après la suppression de sa base de données source, mais elle ne peut pas survivre à son instance parente. Pour éviter toute suppression accidentelle des sauvegardes, vous ne pouvez pas supprimer une instance Cloud Spanner si elle contient des sauvegardes. Pour les utilisateurs qui souhaitent supprimer l'instance, nous vous recommandons de restaurer la sauvegarde, puis d'exporter la base de données restaurée, avant de supprimer la sauvegarde et l'instance.

Temps de sauvegarde et performances

La durée de création d'une sauvegarde dépend de divers facteurs, mais elle est principalement déterminée par la taille de la base de données et le nombre de nœuds. Si vous avez besoin de temps de sauvegarde plus rapides, vous pouvez augmenter le nombre de nœuds. Sachez toutefois que les modifications apportées au nombre de nœuds prennent effet pour les sauvegardes suivantes.

La création de sauvegardes utilise également le processeur inactif. Assurez-vous que votre utilisation du processeur respecte les consignes recommandées. Une surcharge du processeur peut entraîner des temps de sauvegarde très longs et avoir un impact négatif sur la latence de la base de données.

Le processeur d'une instance est partagé par toutes les sauvegardes en cours de l'instance. La création simultanée de sauvegardes de différentes bases de données dans la même instance peut entraîner de longs délais de sauvegarde.

Fonctionnement de la restauration

Lors de la restauration, vous devez spécifier une sauvegarde source et une nouvelle base de données cible. Vous ne pouvez pas restaurer une base de données existante. La nouvelle base de données doit se trouver dans le même projet que la sauvegarde et se trouver dans une instance ayant la même configuration d'instance que la sauvegarde. Par exemple, si une sauvegarde se trouve dans une instance avec une configuration us-west3, elle peut être restaurée sur n'importe quelle instance du projet également avec une configuration us-west3. Le nombre de nœuds des instances n'a pas besoin d'être identique. La base de données restaurée contiendra toutes les données et le schéma de la base de données d'origine à l'emplacement create_time de la sauvegarde. Elle ne disposera d'aucune autorisation IAM (à l'exception de celles héritées de l'instance contenant la base de données restaurée) et les utilisateurs devront appliquer les autorisations IAM appropriées une fois la restauration terminée. Le processus de restauration est conçu pour la haute disponibilité, car la base de données peut être restaurée tant que le quorum majoritaire des régions et des zones de l'instance est disponible.

Il est important de comprendre qu'une base de données restaurée effectue la transition entre trois States qui sont suivis par deux opérations.

  • État CREATING : lorsque vous lancez une restauration, le système crée une base de données et une opération de base de données de longue durée avec RestoreDatabaseMetadata pour suivre la progression de la restauration. La nouvelle base de données démarre et conserve l'état CREATING, ce qui signifie qu'elle n'est pas prête à être utilisée tant que l'opération de restauration n'est pas terminée. Afin de garantir des temps de restauration rapides (généralement inférieurs à 10 minutes), l'opération de restauration consiste à installer les fichiers de la sauvegarde sans les copier dans la base de données.

  • État READY_OPTIMIZING : une fois l'opération de restauration terminée, la base de données passe à l'état READY_OPTIMIZING. Dans cet état, elle est prête à être utilisé, mais vous pouvez rencontrer des latences de lecture légèrement plus élevées lorsque la base de données lit les données de la sauvegarde. Toute tentative de suppression de la sauvegarde échouera tant que cette dernière sera utilisée pour la restauration ou l'optimisation de la base de données.

    Une fois l'opération de restauration terminée, vous obtenez une autre opération de base de données de longue durée avec OptimizeRestoredDatabaseMetadata pour suivre la progression de l'optimisation. L'opération d'optimisation copie les données de la sauvegarde dans la base de données. Si vous souhaitez accélérer le processus d'optimisation, vous pouvez ajouter d'autres nœuds à l'instance.

  • État READY : une fois l'opération d'optimisation terminée, la base de données présente l'état READY. À ce stade, la base de données restaurée est entièrement performante et ne référence plus la sauvegarde.

Billing

Vous êtes facturé en fonction du volume de stockage utilisé par vos sauvegardes par unité de temps. La facturation commence une fois l'opération de sauvegarde terminée et se poursuit jusqu'à la suppression de la sauvegarde. La restauration à partir d'une sauvegarde est gratuite.

Une sauvegarde terminée est facturée pour une durée minimale de 24 heures. Si vous créez une sauvegarde, puis la supprimez une minute après qu'elle se termine, vous êtes toujours facturé pour 24 heures.

Pour en savoir plus sur les coûts de sauvegarde, consultez la page Tarifs de Cloud Spanner.

Contrôle des accès (IAM)

IAM vous permet de contrôler l'accès aux ressources Cloud Spanner, qui incluent les sauvegardes et les bases de données restaurées. Si vous ne connaissez pas bien IAM, ainsi que ses rôles et ses autorisations, consultez la page Présentation d'IAM.

Les ressources de sauvegarde sont organisées sous les instances dans la hiérarchie des ressources Cloud Spanner. Nous vous recommandons d'appliquer les stratégies IAM au niveau du projet ou de l'instance. Si vous avez besoin d'un contrôle plus précis, vous pouvez également appliquer des stratégies IAM au niveau de la sauvegarde et de la base de données. Toutefois, cette pratique n'est pas recommandée en raison de sa complexité. N'oubliez pas que les sauvegardes ne contiennent pas de métadonnées de base de données, telles que des stratégies IAM. Par conséquent, lorsque vous restaurez une base de données, celle-ci hérite initialement des stratégies de son instance parente.

Cette section décrit les rôles prédéfinis qui ont accès à la sauvegarde et à la restauration.

Les rôles suivants sont spécifiquement conçus pour la sauvegarde et la restauration :

  • spanner.backupAdmin : peut créer, afficher, mettre à jour et supprimer des sauvegardes. Ce rôle permet également d'afficher et de gérer la stratégie IAM d'une sauvegarde. Ce rôle ne peut pas restaurer une base de données à partir d'une sauvegarde.
  • spanner.restoreAdmin : peut restaurer des bases de données à partir de sauvegardes. Si vous devez restaurer une sauvegarde sur une autre instance, appliquez ce rôle au niveau du projet ou aux deux instances. Ce rôle ne peut pas créer de sauvegardes.
  • spanner.backupWriter : peut créer des sauvegardes, mais ne peut pas les mettre à jour, ni les supprimer. Ce rôle est destiné aux scripts qui automatisent la création de sauvegardes.

Les rôles suivants ont également accès à la sauvegarde et à la restauration :

  • spanner.admin : dispose d'un accès complet à la sauvegarde et à la restauration. Ce rôle dispose d'un accès complet à toutes les ressources Cloud Spanner.
  • owner : dispose d'un accès complet à la sauvegarde et à la restauration.
  • editor : dispose d'un accès complet à la sauvegarde et à la restauration.
  • viewer : peut afficher les sauvegardes, les opérations de sauvegarde et les opérations de restauration. Ce rôle ne peut pas créer, mettre à jour, supprimer ou restaurer une sauvegarde.

Pour plus d'informations, consultez la section IAM Cloud Spanner.