how-to

7 SQL Server Restore from Azure Blob Storage Steps

Last Updated: October 30, 2026

Table of Contents

• Which Azure Platform Supports a Native SQL Server Restore from Azure Blob Storage
  • SQL Server on-premises, Azure VM and Azure SQL Managed Instance compared
• Prerequisites and Storage Container Setup Before You Restore
• Creating a SQL Server Credential for Azure Blob Storage Access

Which Azure Platform Supports a Native SQL Server Restore from Azure Blob Storage

A native SQL Server restore from Azure Blob Storage works on SQL Server running on-premises, on an Azure virtual machine, and on Azure SQL Managed Instance. It does not work on Azure SQL Database, which has no RESTORE DATABASE command at all. That single fact decides your whole approach, so settle it before you touch a storage account.

Here is the split that matters in practice:

Platform	Native .bak restore from URL?	What you use instead
SQL Server on-premises	Yes	RESTORE DATABASE ... FROM URL
SQL Server on an Azure VM	Yes	RESTORE DATABASE ... FROM URL
Azure SQL Managed Instance	Yes	RESTORE DATABASE ... FROM URL
Azure SQL Database	No	Import/export, or its own backup features

SQL Server on-premises, Azure VM and Azure SQL Managed Instance compared

All three share the same command. The differences sit in permissions and networking.

On-premises, your server needs outbound HTTPS to the storage account. On an Azure VM, keep the traffic on the Azure backbone where you can. On Managed Instance, the restore runs inside Azure, so there is no egress bill for pulling the file.

Start Free Trial →

Watch out: teams often provision an Azure SQL Database, then spend an afternoon hunting for a restore command that was never there. Check the platform first.

Prerequisites and Storage Container Setup Before You Restore

Before you write a single command, confirm five things. Skipping any one of them is the most common reason a restore fails at the first hurdle.

• A storage account using the Blob service, not Azure Files
• A container holding your .bak file
• The .bak uploaded, with its size noted
• Outbound HTTPS access from the SQL Server host
• A login with CREATE ANY CREDENTIAL permission

Create the container in the Azure portal documentation for Blob Storage containers, then upload the backup. A private container is the right default. Public access to a database backup is a data breach waiting to happen.

Compression deserves a decision here. A compressed backup is smaller, so it uploads faster and restores faster over a slow link. The trade-off is CPU time on both ends. If your bottleneck is network throughput rather than processor, compress. Our comparison of compressed vs uncompressed SQL Server backups walks through when each wins.

Creating a SQL Server Credential for Azure Blob Storage Access

A credential is the identity SQL Server uses to reach your storage account. Without one, RESTORE DATABASE FROM URL cannot authenticate, and the error you get is unhelpfully vague.

The syntax is short:

CREATE CREDENTIAL [https://youraccount.blob.core.windows.net/backups]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2027-01-01&st=2026-01-01&spr=https&sig=...';
The credential name must match the container URL exactly, including the container path. Get one character wrong and the restore will not find it.

### Storage key versus shared access signature

Use a shared access signature. A storage account key grants full control over the entire account, and storing it in a credential means anyone who can read that credential can delete your backups. A SAS scoped to read and list on one container limits the blast radius.

Rotate the SAS before it expires. An expired signature produces an authentication failure that looks identical to a permissions problem, which sends people down the wrong path for hours.

## RESTORE DATABASE FROM URL Syntax Explained

The core command is `RESTORE DATABASE`, pointed at a blob URL instead of a disk path. Everything else is options.

```sql
RESTORE DATABASE SalesCopy
FROM URL = 'https://youraccount.blob.core.windows.net/backups/Sales.bak'
WITH MOVE 'Sales_Data' TO 'D:\Data\SalesCopy.mdf',
     MOVE 'Sales_Log'  TO 'L:\Log\SalesCopy.ldf',
     REPLACE, STATS = 10;
Four things trip people up. `MOVE` is mandatory when the target server has different file paths from the source. `REPLACE` lets you overwrite an existing database. `STATS` gives you progress, which matters on a large file. And the database name on the left must be the name you want, not the name inside the backup.

### Checking the backup set with RESTORE HEADERONLY

Run `RESTORE HEADERONLY` before the restore, not after it fails. It reads the backup header without touching any data.

```sql
RESTORE HEADERONLY
FROM URL = 'https://youraccount.blob.core.windows.net/backups/Sales.bak';
The output tells you the SQL Server version that wrote the file, the database name, and how many backup sets it contains. Version matters: you cannot restore a backup from a newer SQL Server build onto an older one ([SQL Server backup and restore operation issues - SQL Server](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/backup-restore/backup-restore-operations)). If the header shows a higher version than your target, stop there.

In SQL Server Management Studio, the restore wizard under the Tasks menu handles the same steps through a dialogue. It is fine for a one-off. For anything repeatable, script it.

## Restore SQL Server Backup to Azure SQL Managed Instance

Managed Instance accepts native `.bak` restores, which makes it the closest Azure equivalent to an on-premises server. The mechanics differ in two ways: you reference a storage account by its URL and credential as above, and the instance must be able to reach that account.

A practical sequence:

1. Upload the `.bak` to a container in a storage account the instance can reach.
2. Create the credential on the instance using a SAS.
3. Run `RESTORE HEADERONLY` to confirm the file and version.
4. Run `RESTORE DATABASE` with `MOVE` clauses for the instance file layout.
5. Check the restore completed and the database is online.

One caveat worth knowing: very large databases take time proportional to file size and network throughput, so plan the window rather than assuming it will be quick.

## SQL Server Restore from URL Performance Planning

Restore duration is driven by three things: file size, network throughput between SQL Server and storage, and the speed of the disks you are writing to. Fix the slowest one first.

- **Network:** a compressed backup moves less data. On a constrained link this is your biggest lever.
- **Storage:** premium or locally attached disks beat standard tiers for the write phase.
- **Parallelism:** multiple backup files striped across the restore can use more bandwidth than a single stream.

A common mistake is optimising the database server while the real bottleneck is the link to Azure. Measure throughput before you change anything.

Trace Flag 3051 is worth knowing about. It writes a detailed restore log, useful when a restore stalls and the standard messages tell you nothing. Turn it on for diagnosis, not permanently.

If restores are slow and you want to understand why before tuning, our article on [why SQL Server database restore is so slow](/blog/slow-restore-why-sql-server-database-restore-so-slow) covers the causes in detail.



## Troubleshooting a Failed Restore from Blob Storage

Most failures fall into four buckets. Match the error to the bucket before changing anything.

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| Cannot open backup device | Credential missing or name mismatch | Recreate credential with exact container URL |
| Access denied | SAS expired or lacks read permission | Regenerate SAS with read and list |
| Version error | Backup from newer SQL Server build | Restore to an equal or newer build |
| Logical file not found | Missing or wrong `MOVE` clause | Run `RESTORE FILELISTONLY` and match names |

Two more worth checking. A firewall blocking outbound HTTPS from the SQL Server host produces a timeout rather than a permission error. And a container name typo in the URL gives you a 404 that reads like a missing file.

Watch out: an expired SAS and a wrong permission look identical in the error text. Check the signature expiry first, because it takes ten seconds and saves an hour.

## Start Your Free Trial and Replace Backup-Restore Cycles with Clones

Restoring from blob storage is a solid skill, but it is still a slow path to a working copy. Every restore moves the full backup, writes every page, and takes minutes to hours depending on size. Do that for a development team needing five environments and the DBA becomes a bottleneck.

At DataTamed, we built the alternative: a self-hosted, agent-based platform that provisions lightweight database clones within your own network. Automatic PII masking with three strategies helps with GDPR work, and masking results can be exported as an auditor-ready Data Masking Report.

If you want the side-by-side view, our comparison of [DataTamed versus traditional backup-restore](/compare/datatamed-vs-traditional-backup-restore) covers speed, storage, masking and audit trail. Ready to trial? [Start your free trial](/Pricing) and see current pricing on the DataTamed pricing page. And if you want the concrete workflow, [SQL Server backup to clone done right](/blog/sql-server-backup-to-clone) walks through it end to end.


<section style="margin:3rem 0 2rem 0;" itemscope itemtype="https://schema.org/FAQPage"><h2 style="font-weight:700; margin:0 0 4px 0;">Frequently Asked Questions</h2><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">How do I restore a SQL Server database from Azure Blob Storage?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">Create a storage container and upload the .bak file, then create a SQL Server credential that holds the storage key or shared access signature. Run RESTORE DATABASE with the FROM URL clause pointing at the blob URL. Use RESTORE HEADERONLY first to confirm the backup set, and WITH MOVE if the data and log file paths differ from the source. Permissions on the container and a valid credential are the two most common blockers, so verify both before you start the restore.</p></div></div><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">What credentials are needed to restore a SQL Server backup from Azure Blob Storage?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">You need a database-scoped credential created with CREATE CREDENTIAL that maps to the blob container URL and holds either the storage account key or a shared access signature. The identity running the restore also needs the ALTER ANY CREDENTIAL or CONTROL SERVER permission depending on scope. For Azure SQL Managed Instance, a SAS token or managed identity approach is typical. Rotate keys regularly, and never store the key in plain text in scripts or source control.</p></div></div><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">Why is my SQL Server restore from Azure Blob Storage failing?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">The usual causes are an expired or wrong credential, a firewall or private endpoint blocking the SQL Server host from the storage account, a blob URL with the wrong container path, or insufficient permissions on the container. Check the SQL Server error log and the storage account diagnostic logs together. Also confirm the backup was taken with the correct WITH CHECKSUM and that the SQL Server version supports the backup format. Trace Flag 3051 can add detail to the error log for credential issues.</p></div></div><div style="padding:20px 0; border-bottom:1px solid #e5e7eb;" itemscope itemprop="mainEntity" itemtype="https://schema.org/Question"><h3 style="font-weight:600; margin:0 0 8px 0;" itemprop="name">How long does it take to restore a SQL Server database from Azure Blob Storage?</h3><div style="line-height:1.7;" itemscope itemprop="acceptedAnswer" itemtype="https://schema.org/Answer"><p itemprop="text" style="margin:0;">Restore duration depends on the size of the .bak file, network throughput between SQL Server and the storage account, and the speed of the target disks. A restore from blob storage is limited by download bandwidth, so a database in the hundreds of gigabytes can take hours over a modest link. Place the SQL Server host in the same Azure region as the storage account, use premium storage for the target data files, and test restore duration before you rely on it in a recovery plan.</p></div></div></section>

---

The restore-from-URL route works, and it will keep working. But it was designed for recovery, not for provisioning environments on demand. If your team is waiting on restores to get test data, that is the real problem to solve.

Get started with DataTamed and give every developer a production-quality clone in seconds, with PII masked and the audit trail already written.

---