The fastest backup/restore strategy for Azure SQL databases?

What is the fastest way to backup/restore Azure SQL database?

The background: We have the database with size ~40 GB and restoring it from the .bacbac file (~4GB of compressed data) in the native way by Azure SQL Database Import/Export Service takes up to 6-8 hours. Creating .bacpac is also very long and takes ~2 hours.

UPD:

UPD. Creating the database (by the way transactional consistent) copy using CREATE DATABASE [DBBackup] AS COPY OF [DB] takes only 15 minutes with 40 GB database and the restore is simple database rename.

UPD. Dec, 2014. Let me share with you our experience about the fastest way of DB migration schema we ended up with.

First of all, the approach with data-tier application (.bacpac) turned out to be not viable for us after DB became slightly bigger and it also will not work for you if you have at least one non-clustered index with total size > 2 GB until you disable non-clustered indexes before export - it's due to Azure SQL transaction log limit.

We stick to Azure Migration Wizard that for data transfer just runs BCP for each table (parameters of BCP are configurable) and it's ~20% faster than approach with .bacpac.

Here are some pitfalls we encountered with the Migration Wizard:

1. We run into encoding troubles for non-Unicode strings. Make sure that BCP import and export runs with same collation. It's -C ... configuration switch, you can find parameters with which BCP calling in .config file for MW application.
2. Take into account that MW (at least the version that is actual at the moment of this writing) runs BCP with parameters that will leave the constraints in non-trusted state, so do not forget to check all non-trusted constraints after BCP import.

Solution 1:

If your database is 40GB it's long past time to consider having a redundant Database server that's ready to go as soon as the main becomes faulty.

You should have a second server running alongside the main DB server that has no actual routines except to sync with the main server on an hourly/daily basis (depending on how often your data changes, and how long it takes to run this process). You can also consider creating backups from this database server, instead of the main one.

If your main DB server goes down - for whatever reason - you can change the host address in your application to the backup database, and spend the 8 hours debugging your other server, instead of twiddling your thumbs waiting for the Azure Portal to do its thing while your clients complain.

Your database shouldn't be taking 6-8 hours to restore from backup though. If you are including upload/download time in that estimate, then you should consider storing your data in the Azure datacenter, as well as locally.

For more info see this article on Business Continuity on MSDN: http://msdn.microsoft.com/en-us/library/windowsazure/hh852669.aspx

You'll want to specifically look at the Database Copies section, but the article is worth reading in full if your DB is so large.

Solution 2:

Azure now supports Point in time restore / Geo restore and GeoDR features. You can use the combination of these to have quick backup / restore. PiTR and Geo restore comes with no additional cost while you have to pay for Geo replica

Solution 3:

There are multiple ways to do backup, restore and copy jobs on Azure.

1. Point in time restore.

Azure Service takes full backups, multiple differential backups and t-log backups every 5 minutes.

2. Geo Restore

same as Point in time restore. Only difference is that it picks up a redundant copy from a different blob storage stored in a different region.

3. Geo-Replication

Same as SQL Availability Groups. 4 Replicas Async with read capabilities. Select a region to become a hot standby.

More on Microsoft Site here. Blog here.