A backup in another location is useful only when you can restore it. Backing up to Azure Blob Storage moves SQL Server backup files off the local VM or data center. Plan credentials, blob format, size, and restore access together.
Begin Backing Up to Azure Blob Storage With Recovery Goals
Define how much data the business can lose and how long a restore can take. Backing up a full database to Azure Blob Storage does not replace a log backup schedule for a database using FULL recovery. Retention, region placement, and storage redundancy affect the plan. The endpoint must remain reachable when the source server fails.
I ask for the restore target before choosing a backup job. A job that completes every night but cannot meet the morning recovery deadline has the wrong design. Test with a database size and network path close to production.
Use the Correct Credential for Backing Up to Azure Blob Storage
BACKUP TO URL can use a SQL Server credential built from a shared access signature for Azure Blob Storage. Scope the SAS to the intended container and required permissions. Store it securely and rotate it before expiry. Never paste a real token into an article, a ticket, or a shared script.
The credential name and URL relationship matters. A wrong scope can let the backup start and then fail during a later operation. I verify the credential identity and expiration plan in a test environment. The query below lists credential metadata without exposing a secret.
SELECT name, credential_identity,
create_date, modify_date
FROM sys.credentials
WHERE credential_identity = N'Shared Access Signature'
ORDER BY name;Choose Block Blobs
Block blobs support modern BACKUP TO URL workflows and backup striping. Multiple URLs in one BACKUP statement can divide a large backup into stripes, subject to SQL Server and Azure limits. The restore needs the complete set of stripes. Keep every URL together in the backup catalog and recovery runbook.
Do not choose a stripe count from habit. Test throughput, backup size, network limits, and restore time. A faster backup that complicates recovery can lose the operational argument. I check how every stripe is named and retained so cleanup never removes one piece early.
Write a Single-URL Backup
This example uses a placeholder storage account and container. Replace them with a real approved target and configure the matching SAS credential before execution. COMPRESSION reduces bytes for many workloads, but the exact saving depends on data. CHECKSUM adds verification during backup. Monitor the command and resulting backup history.
The command is a starting shape, not proof of a valid recovery chain. Run it in a test database first and document the blob URL. A backup file with a tidy name is still just a candidate until a restore succeeds.
BACKUP DATABASE [ExampleDB]
TO URL = 'https://storageaccount.blob.core.windows.net/sqlbackups/ExampleDB_full.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;
Stripe Large Backups
For a larger database, two or more block blob URLs can share one backup set. Each target needs a unique name and all targets must be included in RESTORE. The number of URLs and maximum transfer size must follow current SQL Server backup-to-URL limits. Do not assume an older page-blob limit applies to block blobs.
This example illustrates two stripes. It still requires a matching credential and reachable container. Test the restore with both stripes before using the pattern for an important database.
BACKUP DATABASE [ExampleDB]
TO URL = 'https://storageaccount.blob.core.windows.net/sqlbackups/ExampleDB_01.bak',
URL = 'https://storageaccount.blob.core.windows.net/sqlbackups/ExampleDB_02.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;Protect the Backup Contents
A SAS token authorizes access to stored backups, so limit its permissions and lifetime. Use SQL Server backup encryption when the recovery policy requires it, and keep the certificate or key available for a restore on another server. Azure storage encryption and database backup encryption solve related but different questions.
I test a restore under the identity that will run during an outage, not only under the administrator identity used to create the backup. A secret that lives on a failed machine is a weak recovery plan. Store access instructions and keys through the organization’s approved process.
Inspect Backup History
msdb records backup sets, type, start and finish times, and sizes. It is useful for checking that the intended jobs ran. A history row does not prove the blob is still present or restorable. Compare it with storage retention and a real restore test.
The query lists recent backup history for one database. Adjust the name and observation window. I look for missing log backup intervals as well as missing full backups.
SELECT TOP (20) database_name, type,
backup_start_date, backup_finish_date,
backup_size / 1048576.0 AS backup_mb,
compressed_backup_size / 1048576.0 AS compressed_mb
FROM msdb.dbo.backupset
WHERE database_name = N'ExampleDB'
ORDER BY backup_finish_date DESC;Test the Restore Path After Backing Up to Azure Blob Storage
Restore to an isolated server using the same URL or full stripe set. Check database consistency and run a small application smoke test. Measure transfer time, restore time, and any log replay. Verify credentials, DNS, network path, and storage permissions in that destination. Those dependencies are easy to miss when only the backup job is tested.
I repeat the drill after changing stripe count, encryption, or credential rotation. RESTORE VERIFYONLY can supplement checks, but it does not replace a full restore. The goal is a usable database at the agreed recovery point.
Keep Retention and Cleanup Explicit
Blob lifecycle rules should match backup and log retention requirements. Deleting a full backup can break the planned restore chain even when newer log backups remain. Record which backup sets are required together. Review storage cost and access logs, then test that cleanup leaves a recoverable sequence.
Backing up to Azure Blob Storage provides an off-server destination and useful scale. It still demands a controlled secret, complete stripe set, and practiced restore. The cloud does not read your recovery runbook for you.
Run a restore test into a separate database and record the steps, not just the RESTORE command’s success. Confirm the credential can read every stripe, the backup chain includes the needed log backups, and the restored database passes the application’s basic checks. A backup strategy is an unfinished sentence until recovery works.
I also review who can read the Blob container and how SAS expiration is managed. An expired token can break the next backup after months of green history. A broad token can expose more data than the backup job needs. Give the job the smallest workable access, monitor expiration, and keep a rotation procedure. The backup URL is storage, but the credential is part of the recovery system.
If the storage credential expires tonight, who sees the failed backup and who can renew access before the recovery window closes?
Related reading on this blog: Backup to URL: Script to Perform Striped Backup using Shared Access Signature (SAS) and Backup to URL: Script to Generate Credential and Backup using Shared Access Signature (SAS).
A cloud backup is not a recovery plan, it is a file that a tested restore plan can use.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
