Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

SQL Server backup to URL: designing object-storage backups you can restore when the original server is gone

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Writing SQL Server backups directly to object storage solves a real problem. Backups on the same server, or on a share in the same room, can be lost in the same event as the database. A copy in a separate failure domain can survive that event, provided its storage, retention and access controls remain available.

What it does not solve on its own is the restore. When the original server is gone, a new one has to find the right backup files, prove it is allowed to read them, read them in a format it understands and, if they were encrypted, decrypt them. Each of those depends on something that may have lived only on the old server.

This article sets out what Microsoft documents about backup to URL for Azure Blob Storage and for S3-compatible storage, and frames each point as a design question for that restore.

Two targets, one feature

Microsoft's article on SQL Server backup to URL for Azure Blob Storage traces the feature back to SQL Server 2012 Service Pack 1 CU2 and SQL Server 2014. Its companion, SQL Server back up to URL for S3-compatible object storage, explains that SQL Server 2022 added an S3 connector that uses the S3 REST API to connect to any provider of S3-compatible storage.

The two share the same idea and similar limits, with different details. We cover each in turn.

Azure Blob Storage: block blobs, not page blobs

Azure offers two kinds of blob that SQL Server can write to. Microsoft's guidance is direct: For SQL Server 2016 and later, block blob is preferred. The page explains that the type follows from the credential: a storage account key produces a page blob, and a Shared Access Signature (SAS) produces a block blob. It adds that Shared Access Signature is a safer way to authorize blob access compared to storage key, and that block blob is cheaper.

Size limits and striping

The limits section matters for any database of meaningful size:

Microsoft warns that SQL Server can write in smaller blocks, which means it may hit the 50,000-block limit before the 195 GB figure. Its advice is to stripe backups (even if they're smaller than 200 GB) to avoid the block limit, especially with differential or uncompressed backups. The page also notes that transaction log backups to several files ignore the specified transfer size and use 64 KB instead. Its approximately 195.3 GB maximum is the aggregate of 64 files at 64 KB per block, or one file at 4 MB per block. These are the documented 4 MB-path calculations, not a blanket limit for every version or object-storage connector; check the installed version’s guidance.

In our reading, the restore consequence is that a striped backup is a set, not a file. Every stripe has to be present and named in the restore. A retention or tidy-up process that removes one blob of a set breaks the whole backup.

Other limits worth knowing

The same page lists several more limitations. The ones we consider most relevant to recovery planning are:

Failed backups leave things behind

Microsoft's best practices and troubleshooting page notes that failed backup activity can result in an invalid backup file, and recommends periodically finding failed backups and deleting their blobs. It also describes failed backups leaving blobs with active leases.

For S3-compatible storage, the S3 page describes a similar effect from the way multipart uploads work: temporary uncommitted data aren't removed if there are backup failures, and persist if the backup fails or is cancelled.

In our reading, two practical points follow. A storage container can hold objects that look like backups but are not valid ones, so a restore should rely on a record of successful backups rather than on what is in the container. And storage use can grow from failed attempts, which is worth monitoring separately from the backups themselves.

S3-compatible storage: parts, TLS and credentials

The S3 page sets out its own limits and prerequisites.

Parts and size. An object can be split into up to 10,000 parts, each between 5 MB and 20 MB, set by the transfer size. The default is 10 MB. Larger backups must be striped across up to 64 URLs. The page also states that restore from S3-compatible storage has no size limitation.

HTTPS only. TLS must be configured. The endpoint is validated by a certificate installed on the SQL Server host, and S3 connections are assumed to use HTTPS. The Azure reference explicitly says Backup to URL using HTTP is not supported. In our reading, this is a recovery dependency in its own right: a new SQL Server host must trust the storage endpoint's certificate before it can read a single backup. If the storage uses a private certificate authority, its root certificate is part of the restore kit.

Credentials. The connection needs an access key and secret created on the storage system, held in a SQL Server credential. The page lists constraints on them, such as the secret not containing a colon.

Buckets. Buckets can't be created or configured from SQL Server 2022 (16.x). They are set up on the storage side.

Immutable storage

Ransomware and accidental deletion are reasons to make backups unchangeable for a period. Azure's immutable storage overview describes time-based retention, under which objects can be created and read, but not modified or deleted, and legal holds.

For SQL Server, timing matters. Microsoft's backup to URL page states that SQL Server 2025 (17.x) introduces support for Azure immutable storage, and explains why earlier versions could not use it: a backup was normally created as a zero-filled file and then updated, which immutable storage does not allow. SQL Server 2025 instead writes the whole backup in one step. Two further limits apply:

The page also notes that using the FORMAT option against immutable storage, when a backup with the same name already exists, fails. In our reading, backup naming should guarantee unique names when immutability is on.

The pages we read do not describe S3 object lock support for SQL Server backups. We make no claim about it here; check current Microsoft documentation and the storage vendor's guidance before relying on it.

Encrypted backups need their certificate

Microsoft's backup encryption article is unusually emphatic: It's very important to back up the certificate or asymmetric key, and preferably to a different location than the backup file it was used to encrypt. Without it, you can't restore the backup, rendering the backup file unusable.

The same page adds points that catch people out:

In our reading, an encrypted backup in object storage and its certificate on the original server are, together, a single point of failure. Losing the server loses the ability to use every backup.

Restore time, region and compression

A backup that can be restored is not the same as a backup that can be restored quickly enough. Microsoft's best practices page offers two pieces of guidance that bear on this. For SQL Server running in an Azure virtual machine, it recommends a storage account in the same region as the virtual machine, both to avoid transfer costs and for performance. It also recommends compression to minimize storage costs and storage transaction costs, and to reduce backup time.

In our reading, the same reasoning applies in reverse at restore time. A database restored on premises from storage in a distant region is limited by the link between them, and a full restore of a large database may take far longer than the backup window suggests, because the backups were written over days, as full, differential and log backups, and a restore must read the whole chain in one sitting. The only reliable figure is a measured one. We recommend timing a full restore from the object storage to the kind of server that would be used after a loss, and comparing the result with the recovery time the business expects.

What a new server needs: a restore kit

Bringing the points together, these are our recommendations for what should exist outside the SQL Server, so a different server can restore:

  1. The location: storage account or endpoint, container or bucket names, and region where relevant.
  2. A way to authenticate: a current SAS token or access key held in the organisation's vault, with a known expiry and a documented way to issue a new one.
  3. TLS trust for S3 endpoints: the certificate chain the new host needs to trust the storage.
  4. Encryption certificates and keys, backed up with their passwords, separately from the backups. Microsoft also requires the restore account to have VIEW DEFINITION permission on the relevant certificate or key.
  5. A record of successful backups: which files belong to which backup set, including every stripe, so a restore does not depend on the old server's history. Our understanding is that backup history lives in the old instance's system databases, so it is not available once that server is gone unless it was copied.
  6. A compatible SQL Server target version, edition and supported upgrade path on the restore target, and any logins, jobs and other server-level objects the databases depend on.
  7. Retention rules that keep sets whole: no deleting individual stripes, and failed-backup clean-up that does not touch good backups.
  8. A test restore onto a server that has never seen the backups, using only the kit above.

Make the restore record independent of the failed instance

Record backup-set identity, database identity, backup type, time range and every media-family member together. Object names are useful labels, but they do not prove that a full backup, differential and log sequence belong together. Keep the record where the recovery team can reach it without signing into the lost server, and reconcile it with successful backup results rather than a bucket listing alone.

The recovery credentials should grant the operations required for the chosen restore path without depending on an expired token stored only in the old instance. Preserve the encryption certificate with its private key and the password protecting its export, or the required asymmetric-key provider and recovery arrangement. An accessible public certificate is not enough to decrypt a backup. Test the complete chain on a compatible target, including every stripe, and measure data transfer separately from database recovery and application checks.

Risks and limits of this article

  • Based on Microsoft documentation as read on 11 November 2026. Limits and supported options change between SQL Server versions and cumulative updates.
  • S3-compatible providers differ; Microsoft's S3 page assumes the provider follows the S3 API.
  • The statement about backup history being unavailable after server loss is our understanding, not quoted from the pages used.
  • No backups, restores or commands were run for this article. Example syntax in Microsoft's pages is deliberately not reproduced.

Sources

Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.

This article was originally published on .