Restore a dropped Azure Database for PostgreSQL - Flexible Server instance

APPLIES TO: Azure Database for PostgreSQL - Flexible Server

When a server is dropped, the Azure Database for PostgreSQL flexible server backup is retained for five days in the service. The database backup can be accessed and restored only from the Azure subscription where the server originally resided. The following recommended steps can be followed to recover a dropped Azure Database for PostgreSQL flexible server resource within five days from the time of server deletion. The recommended steps work only if the backup for the server is still available and not deleted from the system. While restoring a deleted server often succeeds, it isn't always guaranteed, as restoring a deleted server depends on several other factors.

Prerequisites

To restore a dropped Azure Database for PostgreSQL flexible server instance, you need

• Azure Subscription name hosting the original server
• Location where the server was created
• Use the 2024-08-01 api-version version

Steps to restore

1. Browse to the Azure portal. Select the Monitor service, then select Activity Log.

2. In Activity Log, select on Add filter as shown and set following filters for the following

   • Subscription = Your Subscription hosting the deleted server

   • Operation = Delete PostgreSQL Server (Microsoft.DBforPostgreSQL/flexibleservers/delete)

     

3. Select the Delete PostgreSQL Server event, then select the JSON tab. Copy the resourceId and submissionTimestamp attributes in JSON output. The resourceId is in the following format: /subscriptions/ffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/ResourceGroup-name/providers/Microsoft.DBforPostgreSQL/flexibleServers/deletedserver.

4. Use Create Server REST API.

1. Go to Request Body section and paste the following replacing the "Dropped server Location"(for example, China North 3 etc.), "submissionTimestamp", and "resourceId". For "pointInTimeUTC", specify a value of "submissionTimestamp" plus 5 minutes to ensure the command doesn't error out.

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

   For example, if the submission timestamp is 2023-06-15T15:58:02Z, we recommend adding a minimum of 10 minutes to restore point in time 2023-06-15T16:05:02Z and ensure that you're changing three parameters (location,pointInTimeUTC,sourceServerResourceId) as per your restore requirements.

       {
       "location": "ChinaNorth3",
       "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

   There is a time limit of five days after the server was dropped. After five days, an error is expected since the backup file cannot be found.

2. If you see Response Code 201 or 202, the restore request is successfully submitted.

   The server creation can take time depending on the database size and compute resources provisioned on the original server. The restore status can be monitored from Activity log by filtering for

   • Subscription = Your Subscription
   • Resource Type = Azure Database for PostgreSQL Flexible servers (Microsoft.DBforPostgreSQL/flexibleServers)
   • Operation = Update PostgreSQL Server Create

Restore a dropped virtual network enabled Server

Restoring a dropped virtual network enabled server involves specifying additional network properties such as the delegated subnet resource ID and the private DNS zone Azure Resource Manager resource ID. Follow the steps below to restore your server with the necessary network configurations.

{
  "location": "ChinaNorth3",  
  "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"
    }
  }
}

Common Errors

1. If you utilize the incorrect API version, you might experience restore failures or timeouts. Use 2024-08-01 API to avoid such issues.
2. To avoid potential DNS errors, it's recommended to use a different name when initiating the restore process, as some restore operations might fail with the same name.

Next step