Restaurer une base de données Azure supprimée pour PostgreSQL

Lorsqu’un serveur est supprimé, la sauvegarde de serveur flexible Azure Database pour PostgreSQL est conservée pendant cinq jours dans le service. La sauvegarde de base de données est accessible et restaurée uniquement à partir de l’abonnement Azure où réside le serveur à l’origine. Les étapes recommandées suivantes peuvent être suivies 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 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 une instance de serveur flexible Azure Database pour PostgreSQL supprimée, vous avez besoin de

• Nom de l’abonnement Azure hébergeant le serveur d’origine
• Emplacement où le serveur a été créé
• Utiliser la version 2024-08-01 api-version

Étapes de restauration

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

2. Dans le journal d’activité, sélectionnez Ajouter un filtre , comme indiqué et définissez les filtres suivants pour les éléments suivants :

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

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

  

1. Sélectionnez l’événement Delete PostgreSQL Server, puis sélectionnez l’onglet JSON. Copiez les attributs resourceId et submissionTimestamp dans la sortie JSON. ResourceId est au format suivant : /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver.

2. Accédez à la page de l'API REST pour créer un serveur flexible Azure Database pour PostgreSQL, puis sélectionnez l’onglet Essayer en vert. Connectez-vous à votre compte Azure.

1. Fournissez resourceGroupName, serverName (nom du serveur cible), propriétés subscriptionId , en fonction de 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 telle quelle.

2. Accédez à la section Corps de la demande et collez les éléments suivants en remplaçant « Emplacement du serveur supprimé » (par exemple, CentralUS, EastUS, etc.), « submissionTimestamp » et « resourceId ». Pour « pointInTimeUTC », spécifiez la valeur « submissionTimestamp ».

  {
    "location": "Dropped Server Location",
    "properties":
    {
      "pointInTimeUTC": "submissionTimestamp",
      "createMode": "ReviveDropped",
      "sourceServerResourceId": "resourceId"
    }
  }

Vérifiez que vous modifiez trois paramètres (emplacement,pointInTimeUTC,sourceServerResourceId) en fonction de vos besoins de restauration.

{
  "location": "WestUS",
  "properties": {
    "pointInTimeUTC": "2023-06-15T06:08:02Z",
    "createMode": "ReviveDropped",
    "sourceServerResourceId": "/subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/SourceResourceGroup-Name/providers/Microsoft.DBforPostgreSQL/flexibleServers/SourceServer-Name"
  }
}

1. 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. L’état de restauration peut être surveillé à partir du journal d’activité en filtrant pour

• Abonnement = Votre abonnement
• Type de ressource = Serveurs flexibles Azure Database pour PostgreSQL (Microsoft.DBforPostgreSQL/flexibleServers)
• Opération = Mettre à jour postgreSQL Server Create

Restaurer un serveur lié à un réseau virtuel déconnecté

La restauration d’un serveur avec réseau virtuel supprimé implique la spécification de propriétés réseau supplémentaires telles que l’ID de ressource de sous-réseau délégué et l’ID de ressource Azure Resource Manager de 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 la version incorrecte de l’API, vous risquez de rencontrer des échecs de restauration ou des délais d’expiration. Utilisez l’API 2024-08-01 pour éviter ces problèmes.

2. Pour éviter les erreurs DNS potentielles, il est recommandé d’utiliser un autre nom lors du lancement du processus de restauration, car certaines opérations de restauration peuvent échouer avec le même nom.

Contenu connexe

• Verrous de ressources.