If you haven’t read my previous post on this subject, you might want to. Otherwise, you’ll be starting this hopefully-not-an-epic-saga in medias res, as they say.
After a bit of digging, I discovered the probable cause of my trouble: the way SQL Azure works. Here’s the link from Stackoverflow that finally turned the light bulb on for me.
The key phrase is this one:
When an Azure SQL Server gets overloaded or goes down, it will disconnect a number of connections and when you reconnect you will get sent to another SQL Server.
Yep. That’s it. And the nasty things about that are (a) you don’t know when it might happen, and (b) since it’s internal load-balancing and redundancy behavior, you have no control.
It’s great for apps running on Azure, because it evens out response time and avoids down time.
But in the case of backing up SQL Azure locally, it throws a monkey-wrench into things. This can also beat you up if you’re writing code against Azure, but that’s the subject of another saga.