UPDATE (10/13/2016): Added video
“I have a deployment architecture in Azure which requires web servers (but can be anything) communicate with a remote file share. I want to use Azure File storage. I also need to maintain a geographically redundant environment in another Azure region. I am required to demonstrate end to end execution of my disaster recovery plan. The end result must show all pieces of my deployment architecture running in the other region. “
The first question to this scenario might be: “What about Geo-redundant storage (GRS)?” The answer to that question is that since, at the time of this post, GRS doesn’t give you fine grained control to force Azure Storage to switch to using the replica in the other region, it won’t meet the customer scenario of being able to prove storage has failed over. Note that if you are ok with trusting that GRS will failover in the event of a disaster (as documented) and aren’t *required* to prove it, then you can stop reading this post. Just use GRS. “What about Read-access geo-redundant storage (RA-GRS)? Can’t I rely on RA-GRS to perform the replication for me and just use something like AzCopy to copy the read-only replica into a new storage account? The end result being a fully functioning share based on the replica?” You could if Azure File storage supported RA-GRS. It doesn’t at the time of this post.
I put together a little code sample to demonstrate one approach to address the scenario above:
Here is a video walkthrough of the sample: