Skip to navigation

Azure SQL Database: Restore a Database

Who can use this feature

Anyone with these permissions: Restore resources

Restoring an Azure SQL database from an Eon snapshot gives you the database as it was when the snapshot was taken, on a new server. Each restore recovers one database from one snapshot.

This article explains how to restore an Azure SQL database from an Eon snapshot to a new server using the Eon console, and how to sign in to the restored database.

Restore an Azure SQL database

Before you start

Before you restore an Azure SQL database, make sure:

  • The subnet you want to restore to has the Microsoft.Sql service endpoint enabled.

  • The virtual network you choose is in a restore resource group, or in a network resource group you granted with the --network-resource-groups option when you deployed the restore permissions. Granting network resource groups requires restore permissions version 1.15.0 or later.

1

Find the snapshot to restore

  1. In your inventory, select the Azure SQL database you want to restore. The Resource details panel opens.

  2. Click the Eon snapshots tab. You see a calendar view that shows the days when snapshots were taken. There can be more than one snapshot per day.

    When you click a day, a list of Eon snapshots taken that day appears. Make sure the Eon snapshots tab is selected.

  3. When you find the snapshot you want, click Restore. The Restore Sql Database wizard opens.

2

Choose the restore account

Choose the restore account to restore to, and then click Next.

3

Configure the new server

In the Configuration step, you set the details of the new server.

  1. Enter the Sql Server Name for the new server. Eon uses this name as a prefix and creates the server as <name>-restored-<job ID>, where <job ID> is the first eight characters of the restore job’s ID. For example, my-server becomes my-server-restored-1a2b3c4d.

    The final name must meet the Azure SQL server naming rules: lowercase letters, numbers, and hyphens only, no hyphen at the start or end, and at most 63 characters. To stay within 63 characters, use a prefix of 45 characters or fewer. If the final name is invalid, the restore job fails.

  2. Choose the Region and Resource group to deploy the new server to.

  3. Enter the Admin Login for the new server. This is the username of the server’s SQL authentication admin account, which you use to sign in to the restored database. Eon generates a random password and doesn’t show it. For background, see logins and users in Azure SQL in the Azure documentation.

  4. To let a subnet reach the new server, set the network fields. Choose the Region and Resource group first. Changing the Region clears the virtual network and subnet. Changing the Resource group also clears them, unless you’ve chosen a Virtual network resource group.

    1. Choose the Virtual network resource group that holds the virtual network.

    2. Choose a Virtual network. This field is optional.

    3. Choose a Subnet in that virtual network. Choose both a virtual network and a subnet, or neither.

  5. To keep the tags the source database had when the snapshot was taken, turn Keep original tags on. To use different tags, turn Keep original tags off, and then click + Add Tag to enter each tag.

    In both cases, Eon also tags the new server and its database with eon:restore=true.

  6. Click Restore to start the asynchronous restore job.

4

Monitor the restore job

You can see your list of restore jobs on the Restore jobs tab in the Jobs page.

After the job completes, the new server is available in the region and resource group you chose. It holds one database, which has the same name as the source database. For what Eon keeps and doesn’t keep, see the Restore support notes. If the job fails, see Restore troubleshooting. To sign in to the restored database, see Connect to the restored database.

Connect to the restored database

To access the restored database, set up sign-in and network access in Azure, in the portal or with the Azure CLI.

1

Set up a way to sign in

Choose the option that matches whether your source server used Microsoft Entra-only authentication.

  • The source server didn’t use Microsoft Entra-only authentication: Reset the server admin password for the admin login you set in the wizard, for example with the az sql server update Azure CLI command. Then sign in with SQL authentication.

  • The source server used Microsoft Entra-only authentication, or an Azure Policy that enforces it created the new server without a SQL admin: Set your own Microsoft Entra admin on the new server. Then sign in with Microsoft Entra authentication.

  • The source server used Microsoft Entra-only authentication, and no such Azure Policy applies: Alternatively, turn off Microsoft Entra-only authentication on the new server, and then reset the server admin password with az sql server update.

Eon creates the new server with Microsoft Entra-only authentication turned on and Eon’s restore app as its Microsoft Entra admin. Eon doesn’t copy the source server’s Microsoft Entra admin. After loading the data, Eon turns Microsoft Entra-only authentication off only if the source server didn’t use it.

2

Allow your client to reach the server

Eon doesn’t copy the source server’s firewall rules, and it doesn’t create IP firewall rules. If you chose a subnet in the wizard, Eon adds a virtual network rule named eon-<virtual network>-<subnet>, and clients in that subnet can reach the server. Eon also adds a virtual network rule for Eon’s own subnet and doesn’t remove it.

To let clients outside that subnet reach the server, add a server firewall rule or create a private endpoint.

3

Sign in to the database

Connect to the <server name>.database.windows.net endpoint of the new server with the sign-in method you set up. The full server name is the server name you set in the wizard, plus the suffix Eon adds.

See also