Is the Public Cloud a viable backup target?

This is not a general Public Cloud bashing article – Public Cloud absolutely has some fantastic use cases for organisations, from SME to large worldwide enterprises. What I do want to do is investigate whether ExaGrid target customers should be storing their backups in the Public Cloud. In almost every discovery call I make with prospects, the technical staff I speak with tell me that their management has instructed them to look at the Public Cloud for every project. So let us help those staff members justify whether the Public Cloud is suitable for them.

If you were to search for “should I backup to the Public Cloud” all the results are very much aligned to individuals or very small organisations. That is a telling start.

The first hurdle to overcome when considering backing up to the Public Cloud, is how will you get your first backup in to the Public Cloud? Assuming you will use some kind of forever incremental technology to overcome the problem of sending a full dataset to the Public Cloud every weekend, there is still the requirement to seed the backups. A small customer might have 20TB to send up to the Public Cloud. A larger customer approaching the enterprise space might have 200TB. These are not small numbers if you only have the amount of bandwidth required to provide internet access for your users!

I previously, more generally, looked at the economics of backup, and used AWS as my guide – in the interests of not having to do the work again, the relevant section is copied below. This exercise was for a customer with two sites, each backing up 200TB of storage, with five weeks of daily backups and twelve weekly fulls. Each dataset was cross replicated for DR purposes.

1.638PB of storage is required for the backup data from each site. This needs to be replicated, so actually it is 3.276PB to be stored at each site. That is an awful lot of data and a lot of disk (and a lot of bandwidth!). The numbers do not include any future growth.

Now let us pop that data in to the Public Cloud… As an example, Amazon offer a fantastic online calculator at https://calculator.s3.amazonaws.com/index.html. So let us place 3.3PB in to S3. That is $82,000 per month. The three year storage cost is just shy of three million dollars. There are some support costs to add, as well.

Ouch, so let us try S3 Infrequent Access – still $49,000 per month! Over three years, that is well over one and a half million dollars. Admittedly, if you trust the Public Cloud not to lose your data if it is only sent to one site, you can halve those payments.

These costs are just for the storage, there are no additional charges included in that figure for bandwidth, ingress or egress. Just the storage. Again, no growth or future price rises built in.

So what are the other costs? Data ‘transfer in’ is free – not a surprise as Amazon want you to use their service. So, data transfer out? For the full 1.638PB it would be $87757. Now let us see how quickly we need to move that data. If we take a week as the acceptable SLA to recover 1.638PB to a physical site the network required would be 22.7Gb/s – who has that kind of connectivity?

I’ve tried to find costs for such a link, but it wouldn’t surprise anyone that that kind of information is not readily available. I am suspecting a fairly hefty four figure USD sum per month. Of course, if an organization wants such a connection available instantly, it needs to pay the monthly bill, just in case. Otherwise there will be a long wait for the connectivity to be available.

Remember, that’s just getting the data back out of the Public Cloud – restores of the IT systems, through the backup application, is required as well.

There is an alternative to recovering to a physical site, after a disaster on a physical location, it would be to recover in the Public Cloud. The obvious benefit to this is not having to own an infrastructure in place for DR. So what would the downsides be?

I do not possess enough expertise to even start counting the raw cost of using the Public Cloud in terms of the compute and storage costs.

The next obvious question is does your organisation have the skills to make this transformation. Gone are the familiar virtualisation, networking and storage dashboards – everything is very different and changing incredibly quickly in the Public Cloud. In order to effectively manage this transition IT staff will need to be constantly attending training sessions and I would advise constantly using the Public Cloud functionality to remain current – costing time and money.

You could always consider using a third party Backup-as-a-Service to the Public Cloud. My personal opinion is these can be fine for SME organisations who don’t want to worry about the cost and complexity of setting up their own physical backup environment. But the moment that a company starts looking at terabytes of data, the costs spiral. I have met many organisations paying monthly five figure costs to their BaaS.

My final point is that for both backup to the Public Cloud and BaaS, you are relying on someone else. You can train your IT team to be able to recover your environment. When something goes wrong, if you have trained them and practised recovery, then you should be able to work with your team to fix problems. When you are relying on a third party, you are trusting that they are available and have the skills, knowledge and willingness to help you. On top of that, the third party has paid to create an infrastructure, and it’s their job to make enough margin on top of that to pay their staff and maybe shareholders. Is backup to the Pubic Cloud really the best deal for you?