SQL SERVER – Unable to Restore from URL – The Specified URL Points to a Block Blob. Backup and Restore Operations on Block Blobs are not Permitted

A client was moving databases from an on-premises SQL Server 2012 into SQL Server 2014 on Azure virtual machines. The restore from Azure storage failed, saying operations on block blobs are not permitted. The fix then was to copy the file as a page blob. The fix today is different, and simpler, and the reason is one point in Microsoft’s current documentation.

The Error

BackupVirtualDeviceFile::DetermineFileSize: SetPosition(0,EOF) failure on backup
device 'https://ACCOUNT.blob.core.windows.net/sqlbackup/DBName.bak'. Operating
system error The specified URL points to a Block Blob. Backup and Restore
operations on Block Blobs are not permitted.

How the File Got There

The backup was not taken with BACKUP TO URL. It was taken to a local disk and then uploaded with AzCopy. That detail is the whole story.

Azure storage holds two kinds of blob that matter here. A page blob is built for random reads and writes, like a disk. A block blob is built for files uploaded in pieces. SQL Server 2014 could only restore from a page blob.

AzCopy decides the blob type for you unless you tell it. I checked the current AzCopy reference: its –blob-type option defaults to Detect, and Detect only chooses a page blob for VHD and VHDX files. A .bak file becomes a block blob. So the upload quietly produced the one kind of file that SQL Server 2014 would not restore.

The Fix Then

Upload it again as a page blob. With the AzCopy of that time the switch was /BlobType:Page. With today’s AzCopy it is written like this:

azcopy copy "D:\Backups\DBName.bak" "https://ACCOUNT.blob.core.windows.net/sqlbackup/DBName.bak?<SAS>" --blob-type PageBlob

That still works, and it is still the answer if you are restoring onto SQL Server 2014 or earlier.

The Fix Now

From SQL Server 2016, block blobs are not only allowed, they are the preferred choice. And Microsoft’s current documentation makes one point very plainly: the kind of credential decides the kind of blob. A storage key means page blobs. A Shared Access Signature means block blobs.

So the blob type follows the credential. The old style of credential stores the storage account name and its access key, and it only works with page blobs. The newer style stores a Shared Access Signature for the container, and it works with block blobs.

That means if you see this error on SQL Server 2016 or later, the file is fine. Your credential is the old kind. Create a credential named after the container, holding a Shared Access Signature:

CREATE CREDENTIAL [https://ACCOUNT.blob.core.windows.net/sqlbackup]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
         SECRET   = '<SAS token, without the leading question mark>';

Then restore without naming a credential at all. SQL Server finds the one whose name matches the container:

RESTORE DATABASE DBName
FROM URL = 'https://ACCOUNT.blob.core.windows.net/sqlbackup/DBName.bak'
WITH STATS = 5;

If you write WITH CREDENTIAL, you are asking for the old storage key method, and that sends you straight back to page blobs. Leaving it out is the point.

Why Block Blobs Are Better Anyway

The documentation gives three reasons, and they are good ones. A Shared Access Signature can be limited to one container and given an expiry date, where a storage key opens the whole account. Block blobs are cheaper. And block blob backups can be striped across up to 64 files, which is how you get past the size limit of a single blob.

That size limit is worth knowing before you need it. One block blob tops out at about 195 GB. Stripe anything larger across several URLs in the same BACKUP statement.

What I Could and Could Not Check

I do not have an Azure storage account wired to my test machine, so I have not reproduced this error here. Everything above about blob types, credentials and AzCopy comes from the current Microsoft documentation, which I read again while writing this, not from memory. I did run the CREATE CREDENTIAL statement above on SQL Server 2025, with a made-up token, to make sure it is written correctly, and then dropped it. The error message and the upload story are my client’s.

This error is not a damaged backup, it is a credential from the page blob era meeting a block blob.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.