Cette page fournit des informations que vous devez consulter avant de restaurer une instance à partir d'une sauvegarde ou d'effectuer une récupération à un moment précis.
Que se passe-t-il lors d'une restauration ?
Lorsque vous restaurez une instance, les données suivantes de l'instance principale sont restaurées sur la nouvelle instance :
- Bases de données
- Utilisateurs
L'opération de restauration entraîne le redémarrage de l'instance.
Récupération à un moment précis (PITR)
La récupération à un moment précis (PITR) vous aide à récupérer l'état précédent d'une instance à un moment spécifique. Par exemple, en cas de perte de données due à une erreur, vous pouvez restaurer une base de données à l'état qui précède l'occurrence de l'erreur.
La récupération PITR crée toujours une nouvelle instance. Vous ne pouvez pas effectuer de récupération PITR sur une instance existante. La nouvelle instance hérite des paramètres de l'instance source, de la même manière que lors d'une création de clone.
Toutefois, pour que la nouvelle instance hérite de ces paramètres, son état doit être RUNNABLE.
Cloud SQL utilise les journaux de transactions pour la récupération à un moment précis. Si vous activez la récupération à un moment précis sur une instance, puis restaurez l'instance à partir d'une sauvegarde, Cloud SQL supprime les journaux de transactions qui vous permettent d'utiliser la récupération à un moment précis à partir de l'instance restaurée.
Pour vous assurer que les journaux de votre instance sont stockés dans Cloud Storage plutôt que sur le disque, procédez comme suit :
- Vérifiez l'architecture réseau de l'instance. Si l'instance utilise l'ancienne architecture réseau, mettez-la à niveau vers la nouvelle architecture réseau.
- Si la taille de vos journaux sur le disque entraîne des problèmes de performances pour votre instance, désactivez la récupération à un moment précis, puis réactivez-la.
Pour obtenir des instructions détaillées sur l'exécution d'une récupération PITR, consultez la page Utiliser la récupération à un moment précis (PITR).
Conseils généraux pour effectuer une restauration
Lorsque vous restaurez une instance à partir d'une sauvegarde (de la même instance ou d'une autre instance), gardez à l'esprit les éléments suivants :
- L'opération de restauration écrase toutes les données de l'instance cible.
- L'instance cible n'est pas disponible pour les connexions pendant l'opération de restauration ; les connexions existantes sont perdues.
- Si vous cherchez à restaurer une instance qui possède des instances dupliquées avec accès en lecture, vous devez supprimer toutes les instances dupliquées et les recréer une fois l'opération de restauration terminée.
- L'opération de restauration redémarre l'instance.
Pour obtenir des instructions détaillées sur l'exécution d'une restauration, consultez la page :
Conseils et prérequis pour restaurer une autre instance
Lorsque vous restaurez une sauvegarde d'une autre instance, tenez compte des restrictions et des bonnes pratiques ci-dessous :
L'instance cible doit avoir la même version de base de données que l'instance à partir de laquelle la sauvegarde a été effectuée.
Cloud SQL définit toujours la capacité de stockage de l'instance cible sur la valeur maximale de la taille du disque configuré et du disque de sauvegarde. La taille du disque de sauvegarde est égale à celle du disque au moment de la sauvegarde.
La capacité de stockage de l'instance cible doit être au moins égale à la capacité de l'instance en cours de sauvegarde. La quantité de stockage utilisée n'a pas d'importance. Vous pouvez consulter la capacité de stockage de l'instance sur la page Instances Cloud SQL de la console. Cette exigence s'applique, que vous réalisiez ou non une récupération PITR d'une base de données.
L'instance cible doit être à l'état
RUNNABLE.L'instance cible peut ne pas posséder le même nombre de cœurs ni la même quantité de mémoire que l'instance à partir de laquelle la sauvegarde a été effectuée.
L'instance cible peut se trouver dans une région différente de celle de l'instance source.
Lors d'une panne, vous pouvez toujours récupérer la liste des sauvegardes d'un projet particulier. Consultez la section Afficher les sauvegardes en cas de panne.
Limitations de la fréquence de restauration
Vous êtes autorisé à effectuer au maximum trois opérations de restauration toutes les 30 minutes par instance, par région et par projet. Si une opération de restauration échoue, elle n'est pas comptabilisée dans ce quota. Si vous atteignez la limite, l'opération échoue avec un message d'erreur vous indiquant quand vous pouvez relancer l'opération.
Examinons comment Cloud SQL limite la fréquence des restaurations.
Cloud SQL utilise les jetons d'un bucket pour déterminer combien d'opérations de restauration sont disponibles à un moment donné. Pour chaque sauvegarde, il existe un bucket pour chaque projet et région cible. Les instances cibles d'un même projet partagent un bucket si elles se trouvent dans la même région. Vous pouvez utiliser jusqu'à trois jetons par bucket pour les opérations de restauration. Toutes les 10 minutes, un nouveau jeton est ajouté au bucket. Si le bucket est plein, le jeton "déborde".
Chaque fois que vous effectuez une opération de restauration, un jeton est attribué à partir du bucket. Si l'opération réussit, le jeton est supprimé du bucket. En cas d'échec, le jeton est renvoyé au bucket. Le schéma suivant illustre ce fonctionnement :
Par exemple, dans la figure suivante, "Backup1", "Backup2" et "Backup3" sont les sauvegardes de la même instance source.
- Chaque sauvegarde (Backup1, Backup2 et Backup3) dispose de son propre bucket de jetons pour les opérations de restauration qui ciblent différentes instances du Projet 1 dans la Région A (Bucket11A, Bucket21A et Bucket31A). Comme chaque sauvegarde possède son propre bucket, vous pouvez restaurer chaque sauvegarde sur la même instance trois fois toutes les trente minutes.
- Chaque sauvegarde comporte un bucket pour un projet distinct et pour une région distincte.
Par exemple, s'il existe cinq projets dans une région, il existe cinq buckets pour cette sauvegarde dans cette région, un dans chaque projet. Dans la figure précédente, nous avons deux projets dans la région A : le Projet 1 et le Projet n.
- Backup1 comporte deux buckets de jetons pour les opérations de restauration dans la Région A. Un bucket pour le Projet 1 (Bucket11A) et un bucket pour le Projet n (Bucket1nA).
- De même, Backup3 comporte deux buckets pour les opérations de restauration dans la Région A. Un pour le Projet 1 (Bucket31A) et un pour le Projet n (Bucket3nA).
- Backup3 comporte un bucket dans la Région B, pour le Projet 1, car toutes les instances du même projet cible et de la même région cible partagent un bucket.
Étapes suivantes
- Effectuer une restauration à partir d'une sauvegarde
- Utiliser la récupération à un moment précis (PITR)