Restaurer une instance Azure Database pour PostgreSQL – Serveur flexible supprimée
S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible
Lorsqu’un serveur est supprimé, la sauvegarde du serveur flexible Azure Database pour PostgreSQL est conservée dans le service pendant cinq jours. La sauvegarde de base de données est accessible et peut être restaurée uniquement à partir de l’abonnement Azure sur lequel le serveur a été initialement installé. Vous pouvez suivre les étapes recommandées ci-dessous pour récupérer une ressource de serveur flexible Azure Database pour PostgreSQL supprimée dans les cinq jours suivant la suppression du serveur. Les étapes recommandées ne fonctionnent que si la sauvegarde du serveur est toujours disponible et n’a pas été supprimée du système. Bien que la restauration d’un serveur supprimé réussisse souvent, elle n’est pas toujours garantie, car la restauration d’un serveur supprimé dépend de plusieurs autres facteurs.
Pour restaurer une instance de serveur flexible Azure Database pour PostgreSQL supprimée, vous avez besoin des éléments suivants :
- Nom de l’abonnement Azure hébergeant le serveur d’origine
- Emplacement où le serveur a été créé
- Utiliser la version 2024-08-01 de api-version
Accédez au portail Azure. Sélectionnez le Moniteur, puis sélectionnez Journal d’activité.
Dans Journal d’activité, sélectionnez Ajouter un filtre comme indiqué, puis définissez les filtres comme suit
Sélectionnez l’événement Supprimer le serveur PostgreSQL, puis sélectionnez l’onglet JSON. Copiez les attributs
resourceId
etsubmissionTimestamp
dans la sortie JSON. Le format de resourceId est le suivant :/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver
.Accédez à la page de l’API REST de création d’un serveur du serveur flexible Azure Database pour PostgreSQL et sélectionnez l’onglet Essayer mis en surbrillance en vert. Connectez-vous à votre compte Azure.
Important
Utilisez cette version 2024-08-01 d’API plutôt que la valeur par défaut avant d’exécuter pour activer cette fonction API comme prévu comme indiqué à l’étape suivante.
Indiquez les propriétés resourceGroupName, serverName (nom du serveur cible), subscriptionId, basées sur la valeur JSON de l’attribut resourceId capturée à l’étape 3 précédente. La propriété api-version est préremplie et peut être laissée seule.
Allez à la section Request Body et collez-y le code suivant en remplaçant « Dropped Server Location » (par exemple, CentralUS, EastUS, etc.), « submissionTimestamp » et « resourceId ». Pour «restorePointInTime», spécifiez une valeur de «submissionTimestamp» plus5 minutes pour vous assurer que la commande ne génère pas d’erreur.
{ "location": "Dropped Server Location", "properties": { "pointInTimeUTC": "submissionTimestamp + 10 minutes", "createMode": "ReviveDropped", "sourceServerResourceId": "resourceId" } }
Par exemple, si l’horodatage de la soumission est 2023-06-15T15:58:02Z, nous vous recommandons d’ajouter un minimum de 10 minutes au point de restauration dans le temps 2023-06-15T16:05:02Z et de vous assurer que vous modifiez trois paramètres (location,pointInTimeUTC,sourceServerResourceId) en fonction de vos besoins de restauration.
{ "location": "WestUS", "properties": { "pointInTimeUTC": "2023-06-15T16:08:02Z", "createMode": "ReviveDropped", "sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.DBforPostgreSQL/flexibleServers/SourceServer-Name" } }
Important
Il existe un délai limite de cinq jours après la date de suppression du serveur. Au bout de cinq jours, une erreur est attendue, car le fichier de sauvegarde est désormais introuvable.
Si vous voyez le code de réponse 201 ou 202, cela signifie que la requête de restauration a été correctement envoyée.
La création du serveur peut prendre du temps en fonction de la taille de la base de données et des ressources de calcul approvisionnées sur le serveur d’origine. L’état de la restauration peut être surveillé à partir du journal d’activité en filtrant sur
- Abonnement = votre abonnement
- Type de ressource = Azure Database pour PostgreSQL Serveurs flexibles (Microsoft.DBfoPostgreSQL/flexibleServers)
- Opération = Mettre à jour la création de serveur PostgreSQL
La restauration d’un serveur de réseau virtuel supprimé implique la spécification de propriétés réseau supplémentaires telles que l’ID de ressource du sous-réseau délégué et l’ID de ressource Azure Resource Manager de la zone DNS privée. Suivez les étapes ci-dessous pour restaurer votre serveur avec les configurations réseau nécessaires.
{
"location": "EastUS",
"properties": {
"createMode": "ReviveDropped",
"sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.DBforPostgreSQL/flexibleServers/SourceServer-Name",
"pointInTimeUTC": "2023-06-20T20:50:59.4078005+00:00",
"Network": {
"DelegatedSubnetResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.Network/virtualNetworks/VirtualNetwork-Name/subnets/Subnet-Name",
"PrivateDnsZoneArmResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.Network/privateDnsZones/privatednszonename"
}
}
}
- Si vous utilisez une version d'API incorrecte, vous risquez de rencontrer des échecs de restauration ou des délais d'attente. Utilisez l’API 2024-08-01 pour éviter ces problèmes.
- Pour éviter d'éventuelles erreurs DNS, il est recommandé d'utiliser un nom différent lors du lancement du processus de restauration, car certaines opérations de restauration peuvent échouer avec le même nom.
Partager vos suggestions et bogues avec l’équipe produit Azure Database pour PostgreSQL.