How to back up and restore a server in Azure Database for MariaDB using the Azure CLI

Azure Database for MariaDB servers are backed up periodically to enable Restore features. Using this feature you may restore the server and all its databases to an earlier point-in-time, on a new server.

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

Prerequisites

• You need an Azure Database for MariaDB server and database.

• Use the Bash environment in Azure Cloud Shell. For more information, see Quickstart for Bash in Azure Cloud Shell.

  

• If you prefer to run CLI reference commands locally, install the Azure CLI. If you're running on Windows or macOS, consider running Azure CLI in a Docker container. For more information, see How to run the Azure CLI in a Docker container.

  • If you're using a local installation, sign in to the Azure CLI by using the az login command. To finish the authentication process, follow the steps displayed in your terminal. For other sign-in options, see Sign in with the Azure CLI.

  • When you're prompted, install the Azure CLI extension on first use. For more information about extensions, see Use extensions with the Azure CLI.

  • Run az version to find the version and dependent libraries that are installed. To upgrade to the latest version, run az upgrade.

• This how-to guide requires version 2.0 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.

Set backup configuration

You make the choice between configuring your server for either locally redundant backups or geographically redundant backups at server creation.

While creating a server via the az mariadb server create command, the --geo-redundant-backup parameter decides your Backup Redundancy Option. If Enabled, geo redundant backups are taken. Or if Disabled locally redundant backups are taken.

The backup retention period is set by the parameter --backup-retention.

For more information about setting these values during create, see the Azure Database for MariaDB server CLI Quickstart.

The backup retention period of a server can be changed as follows:

az mariadb server update --name mydemoserver --resource-group myresourcegroup --backup-retention 10

The preceding example changes the backup retention period of mydemoserver to 10 days.

The backup retention period governs how far back in time a point-in-time restore can be retrieved, since it's based on backups available. Point-in-time restore is described further in the next section.

Server point-in-time restore

You can restore the server to a previous point in time. The restored data is copied to a new server, and the existing server is left as is. For example, if a table is accidentally dropped at noon today, you can restore to the time just before noon. Then, you can retrieve the missing table and data from the restored copy of the server.

To restore the server, use the Azure CLI az mariadb server restore command.

Run the restore command

To restore the server, at the Azure CLI command prompt, enter the following command:

az mariadb server restore --resource-group myresourcegroup --name mydemoserver-restored --restore-point-in-time 2018-03-13T13:59:00Z --source-server mydemoserver

The az mariadb server restore command requires the following parameters:

WWhen you restore a server to an earlier point in time, a new server is created. The original server and its databases from the specified point in time are copied to the new server.

The location and pricing tier values for the restored server remain the same as the original server.

After the restore process finishes, locate the new server and verify that the data is restored as expected. The new server has the same server admin login name and password that was valid for the existing server at the time the restore was initiated. The password can be changed from the new server's Overview page.

The new server created during a restore does not have the VNet service endpoints that existed on the original server. These rules need to be set up separately for this new server. Firewall rules from the original server are restored.

Geo restore

If you configured your server for geographically redundant backups, a new server can be created from the backup of that existing server. This new server can be created in any region that Azure Database for MariaDB is available.

To create a server using a geo redundant backup, use the Azure CLI az mariadb server georestore command.

To geo restore the server, at the Azure CLI command prompt, enter the following command:

az mariadb server georestore --resource-group myresourcegroup --name mydemoserver-georestored --source-server mydemoserver --location eastus --sku-name GP_Gen5_8

This command creates a new server called mydemoserver-georestored in East US that will belong to myresourcegroup. It is a General Purpose, Gen 5 server with 8 vCores. The server is created from the geo-redundant backup of mydemoserver, which is also in the resource group myresourcegroup

If you want to create the new server in a different resource group from the existing server, then in the --source-server parameter you would qualify the server name as in the following example:

az mariadb server georestore --resource-group newresourcegroup --name mydemoserver-georestored --source-server "/subscriptions/$<subscription ID>/resourceGroups/$<resource group ID>/providers/Microsoft.DBforMariaDB/servers/mydemoserver" --location eastus --sku-name GP_Gen5_8

The az mariadb server georestore command requires the following parameters:

When creating a new server by a geo restore, it inherits the same storage size and pricing tier as the source server. These values cannot be changed during creation. After the new server is created, its storage size can be scaled up.

After the restore process finishes, locate the new server and verify that the data is restored as expected. The new server has the same server admin login name and password that was valid for the existing server at the time the restore was initiated. The password can be changed from the new server's Overview page.

The new server created during a restore does not have the VNet service endpoints that existed on the original server. These rules need to be set up separately for this new server. Firewall rules from the original server are restored.

Next steps

• Learn more about the service's backups
• Learn about replicas
• Learn more about business continuity options