A few weeks ago we made the decision to start using Microsoft Azure as our disaster recovery site. We started by looking at doing backups directly to the Azure URL but quickly realized that wouldn't work with our business practices. We would no longer have local backup or transaction logs if we went this route.
So we figured we would just copy the files from our local backup folder to Azure. Microsoft supplies a handy utility called AZCopy to handle copying file to and from the Azure cloud.
https://azure.microsoft.com/en-us/documentation/articles/storage-use-azcopy/
This started out great but there were a couple of wrinkles to iron out. The first being that if you don't use the switch
/BlobType:page you won't be able to restore your database from URL. So when writing your powershell script please make sure to use this switch. If you use the default it goes to block storage and you end up with this error:
System.Data.SqlClient.SqlError: A nonrecoverable I/O error occurred on file The specified URL points to a Block Blob. Backup and Restore operations on Block Blobs are not permitted..
The next problem we ran into was the block size problem. This isn't too big a deal as you can specify block size on the restore. Our backups are done with maintenance plans and it appears the block size default there is 4096. I didn't actually research this since it was an easy fix. All you have to do is specify blocksize = 4096 in your restore statement.
However, if you were trying to do this use SMO in powershell what they don't tell you is that even if you set the block size to 4096 on your restore object, when you pass the control to actually do the restore it leaves that parameter out. Also, couldn't find much documentation on this but I did do a trace on the server where the restore was running both with and without setting the blocksize parameter and it never showed up.
The next error was: invoke-sqlcmd : The volume on device [URL] is empty.
This was caused by leaving off the blocksize parameter on my transaction log restores. Once I added that back in everything started working.
The last error I ran into was a credential problem. I didn't realize that the New-SqlCredential was only working because I had already created it. To get it to create automatically you have to cd into the server like so: cd sqlserver:\sql\$machineName\$sqlinstancepath\Credentials
Then you can create the credential properly.
Hope this helps