Point-in-time restore of an Azure Database for PostgreSQL - Flexible Server with Azure CLI

[! INCLUDE APPLIES TO: Azure Database for PostgreSQL - Flexible Server

This article provides step-by-step procedure to perform point-in-time recoveries in flexible server using backups.

Prerequisites

  • If you don't have an Azure subscription, create a free account before you begin.

  • Install or upgrade Azure CLI to the latest version. See Install Azure CLI.

  • Log in to Azure account using az login command. Note the id property, which refers to Subscription ID for your Azure account.

    az login
    
  • If you have multiple subscriptions, choose the appropriate subscription in which you want to create the server using the az account set command. `

    az account set --subscription <subscription id>
    
  • Create a PostgreQL Flexible Server if you haven't already created one using the az postgres flexible-server create command.

    az postgres flexible-server create --resource-group myresourcegroup --name myservername
    

Restore a server from backup to a new server

You can run the following command to restore a server to an earliest existing backup.

Usage

az postgres flexible-server restore --restore-time
                                 --source-server
                                 [--ids]
                                 [--location]
                                 [--name]
                                 [--no-wait]
                                 [--resource-group]
                                 [--subscription]

Example: Restore a server from this 2021-03-03T13:10:00Z backup snapshot.

az postgres server restore \
--name mydemoserver-restored \
--resource-group myresourcegroup \
--restore-point-in-time "2021-05-05T13:10:00Z" \
--source-server mydemoserver

Time taken to restore will depend on the size of the data stored in the server.

Perform post-restore tasks

After the restore is completed, you should perform the following tasks to get your users and applications back up and running:

  • If the new server is meant to replace the original server, redirect clients and client applications to the new server
  • Ensure appropriate VNet rules are in place for users to connect. These rules aren't copied over from the original server.
  • Ensure appropriate logins and database level permissions are in place
  • Configure alerts as appropriate for the newly restore server

Next steps