Partage via


Restaurer un serveur Azure Database pour PostgreSQL supprimé

S’APPLIQUE À : Azure Database pour PostgreSQL - Serveur unique

Important

Azure Database pour PostgreSQL - Serveur unique est en voie de mise hors service. Nous vous recommandons vivement de procéder à une mise à niveau vers un serveur flexible Azure Database pour PostgreSQL. Pour plus d’informations sur la migration vers le Serveur flexible Azure Database pour PostgreSQL, consultez l’article Qu’arrive-t-il au Serveur unique Azure Database pour PostgreSQL ?.

Lorsqu’un serveur est supprimé, la sauvegarde du serveur de base de données 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 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.

Prérequis

Pour restaurer un serveur Azure Database pour PostgreSQL supprimé :

  • Nom de l’abonnement Azure hébergeant le serveur d’origine
  • Emplacement où le serveur a été créé

Étapes de restauration

  1. Accédez au portail Azure. Sélectionnez le service Azure Monitor, 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é
    • Type de ressource = Serveurs Azure Database pour PostgreSQL (Microsoft.DBforPostgreSQL/servers).
    • Opération = Supprimer le serveur PostgreSQL (Microsoft.DBforPostgreSQL/servers/delete).

    Capture d’écran montrant le 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/TargetResourceGroup/providers/Microsoft.DBforPostgreSQL/servers/deletedserver.

  4. Accédez à la page PostgreSQL API REST Créer un serveur et sélectionnez l’onglet Essayer mis en surbrillance en vert. Connectez-vous à votre compte Azure.

  5. Indiquez les propriétés resourceGroupName, serverName (nom du serveur supprimé), 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.

  6. Faites défiler la page jusqu’à 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 moins 15 minutes pour vous assurer que la commande ne génère pas d’erreur.

    {
      "location": "Dropped Server Location",
      "properties":
      {
        "restorePointInTime": "submissionTimestamp - 15 minutes",
        "createMode": "PointInTimeRestore",
        "sourceServerId": "resourceId"
      }
    }
    

    Par exemple, si la date et l’heure actuelles sont 2020-11-02T23:59:59.0000000Z, nous recommandons un point de restauration dans le temps antérieur de 15 minutes 2020-11-02T23:44:59.0000000Z. Consultez l’exemple ci-dessous et assurez-vous que vous modifiez les trois paramètres (location, restorePointInTime, sourceServerId) conformément à vos besoins de restauration.

    {
      "location": "EastUS",
      "properties":
      {
        "restorePointInTime": "2020-11-02T23:44:59.0000000Z",
        "createMode": "PointInTimeRestore",
        "sourceServerId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup/providers/Microsoft.DBforPostgreSQL/servers/sourceserver"
      }
    }
    
  7. 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 = Serveurs Azure Database pour PostgreSQL (Microsoft.DBforPostgreSQL/servers).
    • Opération = Mettre à jour la création de serveur PostgreSQL

Dépannage

Si vous rencontrez des problèmes au cours du processus de restauration, vérifiez que les valeurs resourceId et submissionTimestamp sont correctes et que la sauvegarde est toujours disponible pendant la période de rétention de cinq jours.

Étape suivante