Restaurer un serveur supprimé dans Azure Database pour PostgreSQL serveur flexible

Lorsque vous supprimez un serveur, le service conserve sa Azure Database pour PostgreSQL sauvegarde de serveur flexible pendant cinq jours. Vous pouvez uniquement accéder à cette sauvegarde et la restaurer à partir de l’abonnement Azure où réside le serveur à l’origine.

Pour récupérer un serveur flexible Azure Database pour PostgreSQL supprimé dans un délai de cinq jours après sa suppression, suivez les étapes recommandées. Ces étapes fonctionnent uniquement si la sauvegarde du serveur est toujours disponible et non 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.

Prerequisites

Pour restaurer un serveur flexible Azure Database pour PostgreSQL supprimé, vous avez besoin des éléments suivants :

  • Accès à l’abonnement Azure qui a hébergé le serveur avant de le supprimer.
  • Emplacement où le serveur existait.
  • Utilisez la version 2025-08-01 des serveurs - Créer ou mettre à jour l’API REST.

Étapes de restauration d’un serveur supprimé

Utilisez le portail Azure :

  1. Recherchez le service Monitor . Dans le menu des ressources, sélectionnez Journal d’activité.

  2. Sur la page du journal d’activité, définissez Subscription sur l’abonnement qui hébergeait votre serveur, puis sélectionnez Add filter pour définir Operation sur Delete PostgreSQL server (Microsoft.DBforPostgreSQL/flexibleServers/delete).

    Capture d’écran montrant le journal d’activité filtré pour l’abonnement où le serveur supprimé existait et pour l’opération supprimer le serveur PostgreSQL.

  3. Sélectionnez l’événement Delete PostgreSQL Server, puis sélectionnez l’onglet JSON. Faites défiler jusqu’à ce que vous trouviez les attributs resourceId et submissionTimestamp dans la sortie JSON. Le resourceId est au format suivant : /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/example-resource-group/providers/Microsoft.DBforPostgreSQL/flexibleServers/example-deleted-server.

    Capture d’écran montrant le fichier JSON du journal d’activité à partir duquel les attributs nécessaires pour restaurer le serveur supprimé peuvent être récupérés.

  4. Accédez à la page de l’API REST du serveur flexible Azure Database pour PostgreSQL, puis sélectionnez le bouton Essayer. Connectez-vous avec votre compte Azure.

  5. Indiquez les valeurs de resourceGroupName (groupe de ressources précédemment créé où vous souhaitez que le serveur restauré soit créé), serverName (nom du serveur nouvellement restauré, qui n’a pas besoin de correspondre au nom du serveur supprimé à l’origine) et subscriptionId (doit correspondre à l’abonnement où le serveur supprimé existait, que vous pouvez obtenir à partir de l’attribut resourceId dans le json inspecté précédemment).

  6. Dans la section Corps du message, collez le code JSON suivant et remplacez la valeur de <original-deleted-server-location> par l’emplacement où se trouvait le serveur supprimé (par exemple, CanadaCentral, CentralUS, EastUS, et ainsi de suite), <value-copied-from-submissionTimestamp> par la valeur récupérée à partir de submissionTimestamp dans le JSON inspecté dans l’événement du journal d’activité, et <value-copied-from-resourceId> par la valeur récupérée à partir de resourceId dans ce même JSON.

  {
    "location": "<original-deleted-server-location>",
    "properties":
    {
      "createMode": "ReviveDropped",
      "pointInTimeUTC": "<value-copied-from-submissionTimestamp>",
      "sourceServerResourceId": "<value-copied-from-resourceId>"
    }
  }

Vérifiez que vous modifiez trois paramètres (location, , pointInTimeUTCsourceServerResourceId) en fonction de vos besoins en matière de restauration.

{
  "location": "CanadaCentral",
  "properties": {
    "createMode": "ReviveDropped",
    "pointInTimeUTC": "2026-06-09T06:08:02Z",
    "sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/example-restored-resource-group/providers/Microsoft.DBforPostgreSQL/flexibleServers/example-deleted-server"
  }
}

Important

Il existe une limite de temps de cinq jours après la suppression du serveur. Après cinq jours, une erreur se produit, car la sauvegarde est introuvable.

Si le code de réponse 201 ou 202 s’affiche, la demande de restauration est envoyée avec succès.

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. Vous pouvez surveiller l’état de restauration à partir du journal d’activité si vous filtrez par :

  • Abonnement : abonnement dans lequel vous restaurez le serveur supprimé.
  • Type de ressource : serveurs flexibles Azure Database pour PostgreSQL (Microsoft. DBforPostgreSQL/flexibleServers).
  • Opération : mettre à jour postgreSQL Server Create.

Restaurer un serveur de réseau virtuel supprimé

La restauration d’un serveur avec réseau virtuel supprimé nécessite la spécification d’autres propriétés réseau, telles que les identificateurs de ressources du sous-réseau délégué et de la zone DNS privée. Suivez les étapes décrites dans la section suivante pour restaurer votre serveur avec les configurations réseau nécessaires.

{
  "location": "EastUS",
  "properties": {
    "createMode": "ReviveDropped",
    "pointInTimeUTC": "2026-06-09T06:08:02Z",
    "sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/example-restored-resource-group/providers/Microsoft.DBforPostgreSQL/flexibleServers/example-deleted-server",
    "network": {
      "delegatedSubnetResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/example-restored-resource-group/providers/Microsoft.Network/virtualNetworks/example-virtual-network/subnets/example-subnet",
      "privateDnsZoneArmResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/example-restored-resource-group/providers/Microsoft.Network/privateDnsZones/example-private-dns-zone"
    }
  }
}

Erreurs courantes

Si vous utilisez une mauvaise version de l’API, des échecs de restauration ou des délais d’expiration peuvent survenir. Utilisez la version 2025-08-01 pour éviter ces problèmes.

Pour éviter les erreurs DNS potentielles, utilisez un autre nom lorsque vous lancez le processus de restauration. Certaines opérations de restauration peuvent échouer si vous utilisez le même nom.

Contenu connexe

Verrous de ressources

  • Last updated on