SQL Server Managed Backup to Microsoft (Windows) Azure | Part-2
In the last post we discussed about the features of SQL Server Managed Backup to Windows Azure, how it is different from conventional backup schedules, how the backup and container gets named and based on what conditions SQL Server will initiate a Full\Transactional Log backup or skip it.
What are the benefits of using this technology:
1. If you want to automate backups without using this feature you need to develop a backup strategy, you may also have to write your own code and schedule the jobs etc. But by using this feature all you need to do is provide the retention period & storage location that’s it and SQL Server Managed backup to windows azure will schedule, perform and maintain the backups for you.
2. This feature can be configured at DB level or at the instance level.
a. If you enable this at the instance level this feature will be automatically applied to all DBs created thereafter that means you don’t have to worry about the newly created DBs.
b. If you enable this at the DB level and specify the retention period this will override the default settings set at the instance level; means more granular control.
3. You don’t even have to worry about the type of backup and frequency, all of these things gets determined automatically by SQL Server Managed Backup to Azure based on the retention period you specify and the workload on the database.
4. If you configure to use Encryption it gives you additional Security. Backup Encryption is new feature added in SQL 2014 and you can also use it in Native backups on disk\tape and you can take backup with Encryption using T-SQL or GUI both.
Things you must know about this feature:
1. A full backup and a transaction log backup can run concurrently, however if there are more than 1 Full DB backup jobs running for the same database it will wait for the current job to complete before initiating another backup; the same applies for transaction log backup also.
2. If more than 10 concurrent full DB backups are scheduled, it will issue a warning through debug channel of Extended Events; then maintains a priority queue for the remaining DBS that require a backup until all the backups are scheduled and completed.
3. Failures are logged as Extended Events.
Limitations of Managed Backup in SQL 2014
Don’t you think features discussed till now are too good to be true, yes just like any other technology there are some limitations for SQL Server Managed Backup to Windows Azure, these are:
1. Only Full and Transaction Log backup is possible through Managed Backup.
2. System Databases are not supported.
3. Only full & Bulk-Logged recovery models are supported so the recovery model of the DB should be one of them.
4. File backup automation is not supported as of now.
5. SQL Server Managed backup to Azure is currently supported only by T-SQL; you can monitor and troubleshoot by using Extended Events though. If you are a PowerShell & SMO freak then watch out, because PS & SMO support is limited to Configuring storage and retention period default settings for an instance of SQL Server, and monitoring the backup status and overall health based on SQL Server Policy Based Management policies.
6. Windows Azure Blog Storage service is the only supported backup storage option. Backup to disk and tape are not supported.
7. Currently the maximum file size allowed for a page blog in windows azure storage is 1 TB that means you can’t backup the DB if the backup size goes beyond 1 TB & it will fail. To avoid such scenarios you can use Compression and test the size before configuring the backup & keep a check on the backup size.
8. It also may have some limitations when it is configured with other technologies supporting backups, HA & DR.
Thanks,
Sarabpreet Singh