I’m very proud to introduce the latest customer inspired tool in this latest release.

Snapshot storage backup

This job will scan through an Azure container or set of containers and for every new or modified file it will create a snapshot of the file. These snapshots can also have a retention policy so that snapshots older than a certain number of days can be deleted.

The idea behind this was a much more efficient way to backup very large files without having to wait for large file transfers or copies.

Hope you get the most out of it.

Storage efficiency

I’ve continued to try and improve the efficiency of storage backups but this is going to be the last work on this for a while - I’ve spent too much time on it already. This should be a little faster for azure to azure backups.

A lot of my time was spent testing for a lockup when syncing from Azure to Amazon - this in the end I believe was a deadlock within the Amazon S3 SDK which I have now updated.

Where now?

For now we’re going to let the system settle and limit active development while we consider where we’re going with it longer term. If you have any thoughts please drop me an email richard.mitchell@red-gate.com

I wanted to put some of this into the last update but decided it was best to improve things in smaller stages and run more extensive testing before the release.

Page blobs copied as ranges

When encountering a page blob to backup from Azure to Azure it will now copy only the page ranges with data in them. Of course for large files that are only sparsely populated (such as .vhd files) this should result in a considerable improvement in performance.

SQLite instead of Azure tables for temp file list

As the followers of the service may be aware I used an Azure Table per container in a sync job to store the file list. This means that a large file list doesn’t risk running the system out of memory during a sync. I’ve now moved to a SQLite database on local storage as I’ve been having performance problems on Azure Table in my use case - bumping into the 100 rows per insert was the primary problem.

In testing this replacement has been working well even though local storage on Azure is very slow for IOPS performance - something to be aware of when you start using local storage on Azure.

FQDN no longer needed when entering SQL Azure Server

This was an oversight on my part, probably introduced when I did the redesign a few months. The system should recognise just the SQL Azure Server name without having to append the “.database.windows.net”. It’s a simple fix and thanks for a user for raising it to me yesterday as I’d simply forgotten about it.

Error - temporary copy left behind

It seems that the system left a temporary database copy behind on a customers SQL Azure Server. This seems to have been due to a timing issue when starting the copy. I’ve attempted to fix the issue but this is the first time I’ve seen the error here since starting the service.

Just bear in mind that should a backup fail it’s worth checking the logs in case the temporary database drop has failed.

Really, keep reporting problems you’re having I want this to work as well for you as I can.

Another week and I’ve managed to get some “real” work done on the system. This time mainly concentrated around the speed of transfers from Azure to Amazon and the discoverability of features on the Schedules & History page.

Speed from Azure to Amazon

Initially this started off as an investigation into why backing up databases where the .bacpac was greater than 5Gb failed. It transformed into me beating some speed out of the Amazon SDK. It seems the defaults were “please transfer this file as slowly as you can” so I’ve added a lot of complicated threading and stream splitting which I think has speeded up transfers to Amazon by a considerable amount (tests changed from 4 hours to about 40 minutes). This is only apparent on larger files though.

The reason behind the 5Gb wasn’t to do with the uploading (I discovered after several days) but rather setting metadata on the target file. So I’ve had to refactor my internal API so that I set the metadata on upload which seems to be working just fine.

The risk of this is that I may have introduced some memory leak but I have a lot unit and integration tests and live system monitoring so I hope if there is an issue I can pounce on it instantly.

Listing of files

Another area of concern is simply listing the files in the source and destination containers prior to sync. I’ve hopefully made this at least twice as fast by listing both source and destination at once and also doing a lot more asynchronous calls to try and reduce time spent blocking.

I still think there is more work needed here as I use SQL Azure tables to store the file list and that now seems to be slowing me down.

Auto snapshot of .vhd files

Before attempting to copy from a .VHD file the system will take a snapshot of the file at that point in time and sync that file. Once that is complete the snapshot is removed. This should assist customers trying to backup active virtual disks.

More work in this area is needed so I only copy parts of the page file that have been used.

History page improvements

As mentioned before I’ve been taking support requests for people finding it hard to work out how to edit schedules. In an effort to make this more discoverable I’ve modified the history page slightly. Hopefully this should make things more intuitive for new users.

Bulk pricing - you need to opt-in

Just a reminder in order to benefit from bulk pricing you need to opt-in.

This can be doing by going to Manage Subscription and click on Update. You can confirm the new payment by viewing clicking on Payment Details.

That’s all folks

That’s all for now, again keep pressuring me for more features you want I love hearing from all of you.

This has been the top requested feature for a long time now and I’m finally happy I’ve got a solution to it that should be fair to all around.

If you use less than 6 subscriptions there is no change in price it’s still simply $10, €8 or £7 per month.

If you use more than 5 subscriptions then there are some serious discounts available. It works out as

First 5 subscriptions                 $10.00

Next 5 subscriptions (6-10)       $6.00 - 40% discount

Next 5 subscriptions (11-15)     $4.00 - 60% discount

All subsequent subscriptions    $2.00 - 80% discount

There is a rather cool calculator on the pricing page which I’m very proud of, have a play with the spinnies and you’ll see the unit price drop the more subscriptions you purchase.

Invoices easily available

Also, I get a lot of requests for people wanting a way to get access to their invoices. So now when you go to the manage subscription page you should see a section which contains quick links to all of your invoices.

What next?

Well firstly I’m going to let the new pricing settle down and I’m probably going to do some more work on the Schedules & History page to improve discoverability of the features of the page as it’s not performing as well as I’d hope.

Apart from that please keep the suggestions coming.

It’s that time again, it’s update time and there are a couple of little treats for you people this time around.

Sync to single container

It’s been requested by a few users so now you can easily sync from multiple source containers into one target container (or bucket). This means it’s really easy to ensure your Azure storage is available via Amazon and all you have to do is flip a URL should the worst happen and you can carry on with files copied during your last sync operation.

Table backup file retention

Just like you’re used to for SQL Azure Backup files you can now control the retention policy for your table backups. This has proved slightly more difficult as I had to take into account the regex support in table backup.

As you can see from the screenshot I also use this for ensure my performance logs don’t get too out of hand.

Username at the top of the page

Seems a simple thing but if you have more than one account (as I do) it can be difficult to work out which one is currently logged in. No longer. As I put the username at the top of the page. This went missing during the redesign but now it’s back.

Amazon S3 EU/Other region should work

Amazon have a lovely API so that if you’re targeting S3 storage that isn’t in the US you have to use very different urls. This was spotted by users and after some rather horrible coding I’ve made it work.

If you’re interested in how to make it work in a not too terrible way drop me a line and I’ll share the code.

Slow sync operations

I’ve made some changes to try to increase the copy speed during sync operations. I’ll keep an eye on this but may have to do more work in this area. My belief is that I may have been maxing out the bandwidth for my scheduler worker role so I’ve upped the instance size and put more performance counters to track it.

That’s about it

There are a few minor changes, wording here and there that sort of thing. For now I think it’s good

The next thing on my list is to give an alternative pricing model for people with lots of small databases, if you’ve got opinions please drop me a line at: richard.mitchell@red-gate.com

As always keep your opinions flooding in. I make this software to take away your pain, so tell me your pain.

Restore Azure Table

Well a couple of weeks after the introduction of Backup Azure Table I released the first version of a Restore Azure Table.

This can read a .json.gz file as created by Red Gate Cloud Services and creates a table with the data contained. You can also choose to upsert the data into an existing table. This is done via the InsertOrMerge functionality so any rows that have been modified before the restore happens may have modified properties overwritten by those in the backup.

File format changes

I’ve also had to make a few changes to the format of the backup file as before there wasn’t enough type information stored to completely match the source information, for example if a string looks like a Guid - it would get restored as a guid type, or if value e.g. 42 was stored as a long it would get restored as an int. The new format preserves type information for all properties but please if you spot anything let me know.

Backup files taken previously should restore as best they can with the above provisos.

Cancel jobs - finally

It has taken a while but a user prompted me about cancelling jobs again. I’ve tried to do this in past and the code has ended up so nasty I’ve had to revert. This time however everything clicked and within a couple of hours we (finally) have a way of cancelling running jobs.

When you mark a job for cancellation the job running will check intermittently for that flag and finish off the job then and there. This can take a few minutes so please have patience as I didn’t want to create extra overhead for the jobs constantly checking. In fact they check for cancellation on when writing extra information to the progress log.

Speed on history page

I’ve been told about performance problems retrieving the data on the history page. I’ve attempted to make some improvements to this but I’m not sure I’ve got to the bottom of it yet. You will have to refresh your history page if you have it loading in the background as the data format returned from the server has changed.

Nasty 30Mb timeout

A couple of users were having problems with sync jobs when files were around 30Mb. This was due to a timeout within Azure that I’ve increased (with the help of the Microsoft support team tracking it down). Above this size the file is split up and the timeout wasn’t hit, smaller than this and the file would copy within the timeout.

Job timeout

Due to larger and larger jobs happening in the system I may have to introduce a 24hour duration maximum for jobs. This will mainly affect very large sync operations some of which take several days to complete currently. This is just a heads up that I’ll be doing this.

Yesterday was a big day. I put live some work that has been going on in the background for the last couple of months.

NoSQL Azure table backup

Due to a rush of demand I’ve put the first version of a tool to back up Azure table data. This will export an entire table to a JSON.gz file, it can also remove old rows during the backup process. The data format is simple enough to be read and understood although due to limitations of JSON the format is not type preserving - for example there is not a “guid” type in javascript (although they’re easy to recognise) and you’d find it difficult to tell if a small number was stored as a Int32 or Int64.

Also due to limitations of Azure tables I can’t really give a meaningful percentage of  the table backed up as there is no way to get a row count without reading all the data first (or getting the size of the Azure table as far as I’m aware).

This is a first pass at backing up Azure table data and I’d love to hear from you if you find it useful or how you’d like it to work.

Windows 8 UI (Metro)

The most obvious change is the complete redesign of the UI, inspired by the Windows 8 theme and the new Azure portal. This has involved changes to every single UI file and not a small amount of re-factoring if you spot any glitches please let me know.

The thing I’m most proud of is the new history page. This is based on JQuery data tables and allows both sorting and filtering of the last 200 jobs to be run. Hope you like it, compared to the old version it’s far more feature rich and data dense.

What’s next?

Obviously with such a large change there are going to be issues - although to be fair it seemed pretty good overnight - I’ll be keeping a close eye on it and making gradual improvements where I can.

NoSQL Azure table backup will develop as people tell me what they need from such a solution.

Beyond that we’ll see. Hope you like the new site.

I just backed up 5.7Gb of Azure Table to a 174Mb .json.gz file in about 7 hours on my local machine. Not as quick as I’d like but not bad. (No UI for it yet though)

What do you think? Please let me know.

I noticed yesterday I’ve not really put much up on the blog about a few small releases we’ve done recently. So I think it’s time to bring everybody up to speed on what we’ve done and where we’re going.

Resumable backup job

The SQL Azure job is now fully resumable, this means if the scheduler service goes down for any reason it can pick up a job that was in progress and continue it as if nothing had happened. We did this work to the Restore job a while ago and we let it settle before implementing the same logic in the Backup job. Although with other changes our scheduling stability is now excellent so we don’t see a restarting scheduling service anything like as frequently as a few months ago.

The  ” - ” separator in files returned

It looks like as part of the work to make jobs resumable we started putting spaces in backup filenames again. I released a fix yesterday for this. The problem with spaces in the backup filenames is that the Microsoft Azure Portal can’t cope with them so to make it more likely that it can work we add no spaces beyond your control. The other parts of a backup are the filename and the timestamp both of which are under your control.

12 hour default timeout for SQL Azure backup/restore

There is now a timeout to cope with stalled jobs in Microsoft’s bacpac import/export service. If a backup or restore job takes longer than this time the job would fail (even if the export may eventually complete). We had been seeing jobs that would remain “pending” for several days stopping backups from happening, this feature prevents that from happening. You can configure this via the settings upping it to at most 24 hours.

I’m also thinking about limiting the duration of file sync jobs in a similar manner, currently we have jobs spanning several days.

You can remove a running jobs schedule

Does exactly what it says on the tin. You can delete a schedule from a job even if it’s running.

Deleted files during sync no longer fail sync job

If files are deleted during a sync job (after the file list has been created) this no longer causes a problem. Previously the job would file, now it just reported the file as having been deleted and carries on.

What next?

There are currently two things on the go at the moment.

Azure table backup

The requests are coming in thick and fast so I’m looking at doing some form of Azure table backup. This is likely going to be initially just a dump of the given table to a .zip file in blob storage (or possibly a copy to another Azure table). From there it’s up to what people want from it. So far we’ve got requests for differential backups, retention policy of rows ( removing rows older than X days ), backing up to e.g. Amazon SimpleDB. I’m keen on your thoughts so please drop me a line.

Windows 8 redesign

I’ve also started work a while back on a large scale revamp of the appearance of the site. This will not only make the site look a lot better but will also incorporate massive improvements in the history page, showing many more results that are filterable and searchable (another common request).

There was a rare error that a backup job would fail to work with an error saying ”Database already exists” when using the “create temporary copy” option. This was due the retry behaviour of communicating with SQL Azure, we know check for existence of the copy rather than simply assuming the create copy call failed when no result was received from Azure.

There was also a restore bug where finding the latest backup wouldn’t include the new filenames without space separators introduced last week.

Hope that makes sense. We’re fixing smaller and smaller things in the system so our stabilisation work is really paying off, thanks so much.