I’ve been using the backup to azure feature for a short while now and I really like it. Shows I think as this is my 4th blog post on the subject this year! This feature has reduced my stress levels with regard to secure offsite backups. However, so far I have two gripes with it.
Firstly, if there is an issue during the backup i.e. network connectivity for example, the lease on blob gets orphaned and there is no native way to release it. I recently blogged about it and how I have gone about fixing it when it happens. It isn’t ideal, but because it is still a relatively new feature which needs time to bed in and the benefits that it gives me by pushing my backups out to the cloud, I’m happy to roll with the occasional orphaned lease. But, good news!.. the latest CU has taken steps to try and address this problem. This article has a little further information on this update and also the other improvements in CU4 that relate to backup/restore to Azure. By the sounds of things, if there is an issue with the backup to Azure, the process will try and recover gracefully and not leave locked blobs with orphaned leases.. very welcome!..
My other gripe is that there is still no native way to remove blobs as part of a clean-up process. I have devised a backup plan that overwrites files to ensure that I don’t store an unnecessary amount of redundant backup files because the more files I store, the more it is going to cost me each month to do so.. Unfortunately CU4 hasn’t addressed this, but I’m hopeful that one day I’ll be able to have a maintenance plan that removes old backup files from my Azure storage… To be honest though, this is a minor gripe compared to the lease issue which seems to be sorted now.
So, it looks like my first job next week is to kick off the project to get my instances upgraded to CU4.. one that I’m actually looking forward to!..
Enjoy!