Restore a dropped Azure Database for PostgreSQL - Flexible Server instance

Article
04/27/2024

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 is not 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 2023-03-01-preview api-version version

Steps to restore

Browse to the Azure portal. Select the Monitor service, then select Activity Log.
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)
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.
Browse to the Azure Database for PostgreSQL flexible server Create Server REST API Page and select the Try It tab highlighted in green. Sign in with your Azure account.

Important

Use this api-version 2023-03-01-preview rather than the default before running to enable this API function as expected as detailed in the following step.
Provide the resourceGroupName, serverName (Target server name), subscriptionId properties, based on the resourceId attribute JSON value captured in the preceding step 3. The api-version property is prepopulated and can be left as-is, as shown in the following image.
Go to Request Body section and paste the following replacing the "Dropped server Location"(e.g. CentralUS, EastUS 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 + 05 minutes",
    "createMode": "ReviveDropped",
    "sourceServerResourceId": "resourceId"
  }
}
```
For example, if the submission timestamp is 2023-06-15T15:58:02Z, we recommend adding a minimum of 5 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": "EastUS",  
  "properties": 
  {
    "pointInTimeUTC": "2023-06-15T16:05: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.
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 VNET enabled Server

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

Common Errors

If you utilize the incorrect API version, you may experience restore failures or timeouts. Please use 2023-03-01-preview API to avoid such issues.
To avoid potential DNS errors, it is recommended to use a different name when initiating the restore process, as some restore operations may fail with the same name.

Next steps

If you're trying to restore a server within five days, and still receive an error after accurately following the steps discussed earlier, open a support incident for assistance. If you're trying to restore a dropped server after five days, an error is expected since the backup file can't be found. Don't open a support ticket in this scenario. The support team can't provide any assistance if the backup is deleted from the system.
To prevent accidental deletion of servers, we highly recommend using Resource Locks.