La restauration au niveau de la base de données permet de récupérer des bases de données spécifiques dans une instance ApsaraDB RDS for PostgreSQL vers un état antérieur, sans restaurer l'instance entière. Utilisez cette fonctionnalité pour annuler des modifications accidentelles, récupérer des données supprimées ou interroger un instantané historique.
Cette fonctionnalité est en aperçu public et gratuite.
Cas d'utilisation
Perte de données accidentelle : Un développeur supprime une table ou écrase des lignes par erreur. Restaurez uniquement la base de données concernée à un point antérieur à l'incident.
Analyse des données historiques : Extrayez une copie d'une base de données à un instant précis pour exécuter des analyses sans affecter l'instance de production.
Fonctionnement
Le processus de restauration lit les données soit à partir d'un jeu de sauvegarde, soit à partir d'une séquence composée d'une sauvegarde complète suivie de sauvegardes incrémentielles des journaux, puis écrit les bases de données sélectionnées dans l'instance d'origine ou dans une autre instance existante de la même région. La vitesse de restauration est d'environ 20 Mbit/s et varie selon le volume de données.
Convention de nommage : Avant le début de la restauration, le système renomme chaque base de données restaurée en ajoutant _backup à son nom (par exemple, orders devient orders_backup). Vous pouvez modifier ce nom avant de confirmer.
La plage de restauration dépend de la période de rétention des sauvegardes de données, de la période de rétention des sauvegardes des journaux et du moment où vous avez activé la fonctionnalité de restauration au niveau de la base de données sur votre instance RDS.
Prérequis
Avant de commencer, assurez-vous que :
-
L'instance RDS répond à toutes les exigences suivantes :
Version majeure du moteur : PostgreSQL 10 à PostgreSQL 17
Édition : RDS Basic Edition, RDS High-availability Edition ou RDS Cluster Edition
Type de stockage : Enhanced SSD (ESSD) ou Premium ESSD
Type de facturation : paiement à l'utilisation ou abonnement (les instances Serverless ne sont pas prises en charge)
Si l'instance a été créée avant le 10 octobre 2022 et utilise l'architecture d'origine, autorisez le rôle lié au service (SLR) et mettez à jour la version mineure du moteur vers la dernière version avant de poursuivre.
La fonctionnalité de restauration au niveau de la base de données est activée sur l'instance. Consultez la section Activer la restauration au niveau de la base de données.
Conseil : Pour vérifier l'édition de l'instance, le type de stockage et le type de facturation, accédez à la page Basic Information de l'instance.
Limitations
| Limitation | Détails |
|---|---|
| Cible de restauration | Uniquement l'instance d'origine ou une instance existante dans la même région avec la même version majeure du moteur. La restauration vers une nouvelle instance n'est pas prise en charge. |
| Granularité de la restauration | Bases de données uniquement. Les tables et vues individuelles ne peuvent pas être restaurées. |
| Taille des tables | Les tables de plus de 100 Go ne peuvent pas être restaurées. |
| Noms de base de données réservés | Les bases de données dont le nom commence par postgres, rdsadmin ou template ne peuvent pas être restaurées. |
Activer la restauration au niveau de la base de données
L'activation de cette fonctionnalité n'affecte pas les charges de travail en cours d'exécution.
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve l'instance. Recherchez l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, cliquez sur Backup and Restoration.
Cliquez sur l'onglet Backup Strategy.
Cliquez sur Edit à côté de Data Backup Settings. Dans la boîte de dialogue, activez l'option Restore Individual Database/Table.
Cliquez sur Save.
Restaurer des bases de données
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve l'instance. Recherchez l'instance et cliquez sur son ID.
-
Dans le volet de navigation de gauche, cliquez sur Backup and Restoration. Sur la page qui s'affiche, cliquez sur Restore Individual Database/Table.
Si le bouton Restore Individual Database/Table n'est pas visible, vérifiez que tous les prérequis sont remplis.
-
Configurez les paramètres de restauration.
La période de rétention maximale pour les fichiers de sauvegarde de données et les fichiers de sauvegarde des journaux est de 730 jours. Pour vérifier la plage de temps restaurable pour votre instance, appelez l'opération API DescribeLocalAvailableRecoveryTime .
Paramètre Description Restore To L'instance de destination : l'instance d'origine ou une autre instance dans la même région avec la même version majeure du moteur. Restore Speed Fixé sur Standard. Restore Method By Backup Set : restaurez à partir d'un jeu de sauvegarde spécifique. By Time : disponible uniquement lorsque la sauvegarde des journaux est activée. Le système rejoue les données de la sauvegarde complète suivies des données de sauvegarde incrémentielle des journaux, ce qui vous permet de restaurer à n'importe quel point dans la période de rétention des sauvegardes des journaux. Par exemple, si la période de rétention des sauvegardes de données et celle des sauvegardes des journaux sont toutes deux de 7 jours, vous pouvez restaurer à n'importe quel point au cours des 7 derniers jours. -
Sélectionnez les bases de données à restaurer, puis cliquez sur OK.
Sélectionnez jusqu'à 50 bases de données à la fois.
Le système ajoute
_backupau nom de chaque base de données restaurée (par exemple,mydbdevientmydb_backup). Vous pouvez modifier le nom avant de confirmer.Assurez-vous que l'instance de destination dispose de suffisamment d'espace de stockage disponible pour contenir toutes les bases de données sélectionnées.
Vérifier la restauration
Une fois la tâche de restauration terminée, accédez à la page Databases de l'instance de destination pour confirmer la présence des bases de données restaurées. Vérifiez que :
Les bases de données restaurées sont accessibles et les données semblent correctes.
Les chaînes de connexion pointant vers les données restaurées utilisent le nom de base de données correct (la version
_backup, sauf si vous l'avez renommée lors de la restauration).
FAQ
La console affiche « The operation failed. The RDS instance is not in a ready state. ». Que dois-je faire ?
Les tâches de restauration s'exécutent séquentiellement. Cette erreur signifie qu'une autre tâche de restauration est toujours en cours ou incomplète. Attendez que la tâche actuelle se termine, puis réessayez.
La base de données restaurée est vide. Pourquoi ?
La base de données d'origine ne contenait aucune donnée au moment que vous avez sélectionné. Choisissez un moment où la base de données contenait des données.
Existe-t-il d'autres moyens de restaurer des bases de données individuelles ?
Vous pouvez utiliser Data Disaster Recovery pour sauvegarder et restaurer des instances RDS et des bases de données gérées par l'utilisateur sur des instances Elastic Compute Service (ECS), ainsi que pour télécharger des jeux de sauvegarde localement. Consultez la Présentation et la section Restaurer des données par base de données ou par table.
Étapes suivantes
Restaurer toutes les données d'une instance ApsaraDB RDS for PostgreSQL — restaurez l'instance entière au lieu de bases de données individuelles.
Utiliser pg_restore pour restaurer des données à partir d'un fichier de sauvegarde logique — restaurez des tables spécifiques à partir d'une sauvegarde logique à l'aide de pg_restore.
Restaurer des données vers une instance PostgreSQL gérée par l'utilisateur — exportez les données de sauvegarde vers une instance PostgreSQL gérée par l'utilisateur à l'aide d'un fichier CSV ou d'un fichier SQL.