Lire en anglais

Partager via


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.

Prérequis

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

Étapes de restauration

  1. Accédez au portail Azure. Sélectionnez le Moniteur, puis sélectionnez Journal d’activité.

  2. Dans Journal d’activité, sélectionnez Ajouter un filtre comme indiqué, puis définissez les filtres comme suit

    • Abonnement = votre abonnement hébergeant le serveur supprimé

    • Opération = Supprimer le serveur PostgreSQL (Microsoft.DBforPostgreSQL/servers/delete)

      Capture d’écran du Journal d’activité filtré pour l’opération de suppression du serveur PostgreSQL.

  3. Sélectionnez l’événement Supprimer le serveur PostgreSQL, puis sélectionnez l’onglet JSON. Copiez les attributs resourceId et submissionTimestamp 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.

  4. 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.

  1. 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.

  2. 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.

  3. 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

Restaurer un serveur de réseau virtuel supprimé

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"
    }
  }
}

Erreurs courantes

  1. 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.
  2. 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.