The initial interest in our StoreGrid Cloud AMI solution for Amazon Web Services has been extremely encouraging. As we have more and more partners & customers testing it and discussing their ‘use cases’, we have been getting fantastic insights into the myriad possibilities the cloud throws up for all types of users. This includes MSPs and VARs offering online backup services and businesses running custom applications in the Amazon Cloud.
Backup to the cloud:
The typical use case and the premise on which we started our Cloud AMI, this deployment has service providers running the StoreGrid Cloud AMI as a backup server in Amazon EC2 by provisioning their own Amazon EBS storage. Thereafter, they install the StoreGrid Client in their customer PCs & Servers and configure it to backup to the StoreGrid Cloud AMI. This deployment is very compelling for service providers who do not want to host their customers’ backup data in their own data center. Compelling as it is, it is worth mentioning a few disadvantages with this approach.
One of the advantages a local service provider enjoys is her proximity to the customer. This is especially important when a customer has large amount of data, say 100 GB or more, to be backed up. The initial seed backup for that kind of data over the internet is going to take a long time. To circumvent this problem, StoreGrid supports a feature called “Local to Remote Server Migration (L2R)” which allows the service provider to go on-premise and do a local backup of the first full backup to an external drive. The service provider then manually copies the data from the external drive to the StoreGrid backup server deployed in her data center and then runs the “L2R” module in StoreGrid. This will ensure that the subsequent backups are done incrementally, i.e. only changed blocks are sent over the wire on subsequent backups. With an Amazon deployment, using this L2R feature would not be possible simply because one does not have physical access to the Amazon cloud. Hence, the first full backup has to be done over the internet, regardless of however long that will take. The same is the case when you have to do large restores. A StoreGrid online backup Service Provider with her own data center can do a quick server side restore to an external disk and deliver it to her customer. With the Amazon deployment, the restores have to be done only over the internet even if it is 100 GB of data.
By no means am I trying to discourage service providers from using the Amazon cloud as the data center for their online backup service business. But it is best to take decisions after analyzing all pros and cons along with what exactly the customers’ needs are. It is also best to set the expectations of the end customer upfront so that the customer is fully aware of, and educated on what she is signing up to. That way you won’t have a “but I thought you’d ship me my data in 1 hour” kind of situation.
A hybrid approach – backup locally and to the cloud:
In light of the above discussion, service providers who want to leverage the Amazon Cloud but have the benefit of quick on-site restores could explore a hybrid option wherein the StoreGrid backup server is deployed locally in a customer site and the StoreGrid Cloud AMI is run as a replication server in Amazon EC2. In this deployment model, the on-premise backup servers would be replicating the backup data to the replication server in the Amazon Cloud. A single replication server can receive data from multiple backup servers running across multiple customer sites. We have many service provider partners using the hybrid approach already with the StoreGrid replication server deployed in their own data center.
Backup within the cloud – backing up data from custom applications running in Amazon EC2:
Very interestingly, there are also a few service providers and some end users who are deploying the StoreGrid Client in Amazon EC2 along with their custom applications (which are already running in EC2). We did not think about this use case initially but in retrospect its a fairly obvious opportunity…
Considering that many businesses are looking at running their custom applications in Amazon EC2, backing up application data (which is typically stored in the Amazon EBS volumes) from these custom applications are extremely important too! Even though Amazon supports backing up the EBS storage to Amazon S3 as a snapshot, this is not always sufficient. The reason being the snapshot backup of a whole EBS volume does not provide the granularity required for a partial data restore. With snapshot backup, you can only restore the whole volume data into a new EBS volume. However, with a StoreGrid client deployed in an Amazon EC2instance running a custom application, businesses and IT solution providers, now have the option of configuring file level backups of the EBS volumes. This also applies to backing up data from any application which uses a relational database back end like MySQL or Microsoft SQL Server – since these database backups are supported by StoreGrid!
Where would these clients backup to? Typically, to a StoreGrid Cloud AMI deployed as a backup server – ideally, running in a different availability zone in the Amazon Cloud. The backing up of EBS volume at a granular file level would give enormous flexibility while trying to restore data partially. No wonder we are already generating some interest with this deployment option.
A reversal of roles – backup from the cloud to on-premise storage:
Honestly, we didn’t see this coming…
An end user mentioned that they wanted to backup all their data in Amazon EBS to their on-premise storage. Read that again – from Amazon to their office!!! I was initially not convinced and wondered why someone would want to do that? Here’s why! Though he (the customer) liked running his applications in Amazon EC2 because of the benefits it offered, he was not wholly comfortable with all his customer data present only in the Amazon Cloud.
“What if the Amazon Cloud goes down or what if Amazon itself loses my application data because of some bug or an issue?”, he said. He asked me if he could deploy StoreGrid Client along with his application in Amazon EC2, have a StoreGrid backup server on-premise in his office, and simply backup the application data (stored in Amazon EBS) to the on-premise StoreGrid backup server. “Why Not?”, I thought to myself, and asked him to try it out – there’s no reason StoreGrid shouldn’t work for this kind of a deployment!
On top of this he also told me he would backup the backed up data to tape periodically and ship it for off-site storage. While I personally believe (and have told him so) him to have ‘data paranoia’, I fully understand that this is the nature of the beast! It all depends on the value you attribute to your data!
Needless to say, we are excited about all these possibilities. We are especially excited with the challenge of enhancing StoreGrid to seamlessly support such possibilities. We are gearing ourselves to explore these new frontiers!
I’d love to hear from our (current and prospective) partners and customers about their views and experiences. Got an Amazon story of your own? Do let us know.
