Since SQL Azure is available on the market, one of the main workhorses has been how to implement backups of our databases. Initially the only way I had was to make a copy of the database in another SQL Azure, which meant the cost of having to pay for the additional database. Later began to appear new tools that allowed the export/import the data and schemas through SQL scripts or through the new “bacpac” format. A good summary of them was made on this Luis Panzano’s blog entry, showing the advantages and disadvantages of each of them.
All these previous solutions is in addition of a new backup solution for SQL Azure, nothing more and nothing less than from the hand of Redgate, widely recognized worldwide for its database products.
What is it?
RedGate Cloud Services is a new cloud service for backing up SQL Azure databases in an automated and scheduled way, without having to perform any task that requires complex or depth technical knowledge of the Azure platform.
The new RedGate’ service allows, using the export/import «bacpac» file format, automated backing up through a very simple user interface.
And while this simple interface simplifies the way we perform the backup, one of the most interesting options is the ability to schedule them. Scheduling options are initially not many, but the feedback from the community is doing to implement all the new scheduling needs required.
Where are backups stored?
While from my point of view is that the most recommended option is to store backups in Azure Storage since involves no data transfer costs -remember that the internal data traffic in the same Azure datacenter only is not charged-, there are another two interesting options: backup on Amazon S3 or sent to an FTP server, very interesting options to have automated copies in different storage locations for redundancy, even if we must pay the additional cost of data transfer.
What is ideal for?
Although from the Azure control panel we can manually export databases in the “bacpac” format to Azure Storage -this service is no longer CTP and is fully supported-, the main problem is that current utility on Azure control panel does not allow scheduled backups, so that to perform a daily backup we should visit daily the Azure control panel and run the process manually.
With this new Redgate’ service we can schedule different backups for the same or different databases through a simple user interface, which frees us from having to perform the backup tasks manually. Furthermore, we can access the historical backups logs, receive email notifications, etc..
How much does it cost?
Like most services in the cloud its formula is pay per use, and although the current formula adheres to a single offer of 8€/month (31 uses per month), I guess in the coming weeks will be appearing more options for price escalation as recognized by the Richard Mitchell on the home page.
It should be noted that this price is for the backup service. Does not include storage costs for Azure Storage (storage account isyour own), nor the costs of traffic in the case of using external storage like Amazon or FTP account.
On the other hand, is also offering a free trial period of 10 days without charge.
A few weeks ago, I commented that I upgraded to DotNetNuke 6.1.3 three different sites running on Azure in just 9 minutes, including backups. Now you know the method used to back up the databases. The part of details of how to do the upgrade of DNN sites on Azure I leave for another post.
While the current service could offer much more, precisely Redgate people are taking good note of each new required feature. Believe me, I had the pleasure of having applied for a feature and implemented within a reasonable time. Indeed, it seems that the service will offer many more options soon, as being able to deploy and/or eliminate Azure deployments in a scheduled way.
What I like: scheduling and to receive daily email notifications telling me that the SQL Azure backup has been successful. Although it may seem silly, reassures … a lot. Have I discussed with you my incident when I clicked the «Delete Azure SQL server» instead of «Delete Azure Database»? Well, that’s another story…
For more information, visit: