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

Sauvegarde et restauration

Présentation

L'outil Sauvegarde et restauration de Cloud Spanner vous permet de créer à la demande des sauvegardes des bases de données Cloud Spanner, et de les restaurer afin d'assurer une protection contre les erreurs d'opérateur ou d'application susceptibles d'occasionner une corruption des données logiques. 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 les conserver plus longtemps, nous vous recommandons d'exporter votre base de données.

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

Pour la corruption de données logiques, Cloud Spanner propose également une récupération à un moment précis.

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

Les fonctionnalités Importation et Exportation de Cloud Spanner couvrent des cas d'utilisation semblables à Sauvegarde et restauration. Le tableau suivant décrit les similitudes et les différences entre elles pour vous aider à choisir celle qui convient.

Sauvegarde et restaurationImportation et exportation
Cohérence des données Les sauvegardes et les bases de données exportées sont cohérentes à la fois sur le plan transactionnel et externe.
Impact sur la performance Elles ne s'exécutent pas au même niveau de priorité afin de minimiser l'impact sur les performances de la base de données. L'exportation s'exécute au niveau de priorité moyen et l'exécution de la sauvegarde à faible priorité. Pour plus d'informations, consultez la section Priorité des tâches.
Format de stockage Utilise un format propriétaire chiffré et conçu pour permettre une restauration rapide. Compatible avec les formats de fichier CSV et Avro.
Portabilité Les sauvegardes sont stockées sur 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 ayant la même configuration d'instance que la sauvegarde.
Les bases de données exportées sont stockées dans Google Cloud Storage. Les données peuvent donc être transférées vers tout 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.
Facturation Les sauvegardes sont facturées sur 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 que ces opérations utilisent Google Cloud Storage et Dataflow. Pour en savoir plus, consultez la section Tarifs d'exportation et d'importation de bases de données.
Délai de restauration La restauration s'effectue en deux opérations : la restauration et l'optimisation. L'opération de restauration permet d'atteindre un temps de latence du premier octet très rapide, 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. Toutefois, la latence de lecture peut être légèrement supérieure lors de l'optimisation. Pour en savoir plus, consultez la section 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 terminées, dans la mesure où elles contiennent toutes les données de la base de données (y compris le schéma et les index secondaires) dans l'objet version_time de la sauvegarde. Toutes les modifications apportées aux données ou au schéma après le version_time ne seront pas incluses dans la sauvegarde. Les sauvegardes n'incluent pas les métadonnées de base de données, telles que les stratégies IAM (gestion de l'authentification et des accès).

Chiffrement

Les sauvegardes Cloud Spanner, comme les bases de données, peuvent être protégées par CMEK ou par un chiffrement géré par Google. Par défaut, une sauvegarde utilise la même configuration de chiffrement que sa base de données, mais vous pouvez ignorer ce comportement en spécifiant une autre configuration de chiffrement lors de la création de la sauvegarde. Si la sauvegarde est activée pour CMEK, elle est chiffrée à l'aide de la version principale de la clé KMS au moment de la création de la sauvegarde. Une fois la sauvegarde créée, sa clé et sa version de clé ne peuvent plus être modifiées, même si la clé KMS est alternée. Pour en savoir plus, consultez la section Créer une sauvegarde compatible avec CMEK.

Processus de création

Lorsque vous créez une sauvegarde, vous devez spécifier une base de données source, le nom de la ressource de sauvegarde et une date d'expiration (jusqu'à un an à partir de l'heure de création de la sauvegarde). Vous pouvez également spécifier un version_time, qui vous permet de sauvegarder une base de données à un moment antérieur. Le champ version_time est généralement utilisé pour synchroniser les sauvegardes de plusieurs bases de données ou récupérer des données à l'aide de la récupération à un moment précis. Si l'option version_time n'est pas spécifiée, elle est définie sur le paramètre create_time 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 pendant 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 ne se termine qu'une fois la zone de nouveau en ligne et ayant fini sa copie. Les sauvegardes peuvent être restaurées 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 fait partie de la même instance que sa base de données source, où elle est organisée dans la hiérarchie des ressources et possède un chemin d'accès à la ressource au format projects/<project>/instances/<instance>/backups/<backup>. Une sauvegarde continue d'exister 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 inclut des sauvegardes. Si vous souhaitez 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.

Délai de la sauvegarde et performances

Le temps nécessaire à la création d'une sauvegarde dépend de différents facteurs, mais il est principalement déterminé par la taille de la base de données et le nombre de nœuds. Si vous avez besoin de réduire le délai de création des sauvegardes, vous pouvez augmenter le nombre de nœuds, mais gardez à l'esprit que cette modification s'applique aux 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 sur l'instance. Créer simultanément des sauvegardes pour différentes bases de données sur la même instance peut entraîner des délais de sauvegarde très longs.

Fonctionnement de la restauration

Lors d'une restauration, vous devez spécifier une sauvegarde source et une nouvelle base de données cible. Vous ne pouvez pas restaurer une sauvegarde vers une base de données existante. La nouvelle base de données doit se trouver dans le même projet que la sauvegarde, sur une instance ayant la même configuration d'instance que la sauvegarde. Par exemple, si une sauvegarde se trouve sur une instance configurée dans la région us-west3, elle peut être restaurée sur toute instance du projet qui est également configurée dans la région 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 ainsi que le schéma de la base de données d'origine, à l'instant create_time de création de la sauvegarde. Elle ne comprend pas les autorisations IAM (à l'exception de celles héritées de l'instance hébergeant la base de données restaurée), et les utilisateurs doivent donc 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.

Pour restaurer une sauvegarde associée à CMEK, la clé et la version de clé doivent être disponibles pour Cloud Spanner. Par défaut, la base de données restaurée utilise la même configuration de chiffrement que la sauvegarde. Vous pouvez ignorer ce comportement en spécifiant une autre configuration de chiffrement lors de la restauration de la base de données. Pour en savoir plus, consultez la section Restaurer à partir d'une sauvegarde activée par CMEK.

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 un élément OptimizeRestoredDatabaseMetadata permettant de suivre la progression de l'optimisation. L'opération d'optimisation copie les données de la sauvegarde vers la base de données. Si vous souhaitez accélérer le processus d'optimisation, vous pouvez ajouter davantage de nœuds à l'instance.

  • État READY : une fois l'opération d'optimisation terminée, la base de données passe à l'état READY. À ce stade, la base de données restaurée est totalement opérationnelle et ne fait plus référence à la sauvegarde.

Une instance ne peut pas avoir plus d'une base de données associée à l'état de restauration CREATING. Vous ne pouvez pas restaurer une autre sauvegarde sur l'instance tant que la base de données restaurée n'est pas passée à l'état READY_OPTIMIZING ou READY.

Billing

Vous êtes facturé en fonction de la quantité d'espace de stockage utilisée par vos sauvegardes par unité de temps. La facturation commence dès que l'opération de sauvegarde est terminée et se poursuit jusqu'à la suppression de la sauvegarde. Aucuns frais ne s'appliquent pour la restauration d'une sauvegarde.

Les sauvegardes sont stockées et facturées séparément. Le stockage des sauvegardes n'a pas d'incidence sur la facturation du stockage des bases de données ni sur les limites de stockage des bases de données.

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 le coût des sauvegardes, 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, ce qui inclut les sauvegardes et les bases de données restaurées. Si vous débutez avec l'utilisation d'IAM, des rôles et des autorisations, consultez la page Présentation d'IAM pour obtenir une introduction.

Les ressources de sauvegarde sont organisées sous les instances dans la hiérarchie des ressources Cloud Spanner. Nous vous recommandons d'appliquer des 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 n'incluent pas les métadonnées de base de données telles que les 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 en savoir plus, consultez la page Contrôle des accès pour Cloud Spanner.