In previous posts, we’ve set up that the world is scary, and we don’t want to rotate hard drives or tapes, and we want immutability. So, let’s talk about cloud immutability, what we get, and some possible concerns.
PART 4
The Who, What, & When Of Cloud Immutability
Cloud providers are by far the easiest way to get cloud immutability quickly and easily. Simply sign up for a Wasabi or AWS account (Azure, not following the S3 protocol for their blob – but making their own – hasn’t been supported by Veeam until V12), build a bucket, turn on versioning, add it to Veeam, and you have an immutable repository. Super simple, with a super low cost of entry. Cool. Past that point however, everything gets a bit more grim.
The costs from the hyper-scalers are extremely variable. API calls, bandwidth, storage usage – it all has its own unique expenses. If backups break and you spend a few days rerunning things and trying to sync them, you can easily double your costs for that month. So suddenly the bill each month just went up by double…or more. Even if you are reasonably static in use, it can be uncertain what your bill is going to be.
Wasabi is MUCH easier to calculate, but Wasabi also has a minimum time period of capacity purchase. If you add a bunch of data one month to do some new backups of replacement servers, for example, you have to keep it for at least three months – so you’re stuck paying for it even if you reduce the size of your backups. That’s also annoying.
The Problems
“That’s not so bad, once you get the initial data sync, it’s just differentials.”
This is normally the follow-up to that, which is completely true. However, if you start talking about a differential being… five percent? That still means you’re looking at 12 hours (again assuming a completely open 500 Mbits with no overhead) to upload the differentials. In reality, you’re probably going to throttle it during the workday, to not perform your own DoS on your environment, so it might get closer to 20 hours to upload your differentials.
Now if anything at all goes wrong, you’re going to miss your window before the next backup runs. Again, that gets each one completing before the next business day, but it means that your most recent immutable copy of data is pretty much always a day old – at best – assuming nothing goes wrong and everything gets uploaded in a timely manner.
Having that immutable backup copy on a time delay can cause some real woes when it comes time to restore from a ransomware incident, because almost everyone restores to the most recent copy of backups. However, that’s not the end of the story, it gets worse.
You also have to account for the time to pull that backup back down OUT of the cloud. So if it took 10 days to upload the first time, unless you have asymmetric internet speeds, it’s probably going to take 10 days to download it now. However, if you want the most recent copy (in the cloud) of your backup, you also need to pull down those incrementals that you’ve been sending – which is going to add a few MORE days of downloading. THEN you can start restores. Going to a plant manager and telling them you lost everything they did in ERP for the last day and a half… and they’re going to have to do everything on paper for the next two weeks is what we refer to as an RGE – Resume Generating Event.
“Wait, my data is in the cloud, why can’t I just restore it INTO the cloud?”
Well… you can… with asterisks.**
For starters, if you use Wasabi – the most reasonably priced of cloud immutability options for backups – you have to move it from Wasabi to another provider to restore. Even if you do use another provider, you have to first build some server with which to restore the backups, then spin up a tenant (with the security thereof), push your backups into that tenant, and spin everything up. It seems like it should be a quick and easy thing, but you quickly find yourself a few days of work in.
Past that, you also have to now spend cloud prices on all those servers, which for even a moderately sized environment can be tens of thousands of dollars a month. THEN you have to figure out how you’re going to back up your new production in the cloud. THEN you have to figure out how you’re going to get it back on-premises, because the business isn’t going to want to give you outage windows to move stuff back after it’s been down for days… but you’re paying tens of thousands to run it up there…
The Resolution
“Ok, so the takeaway is the cloud sucks and never use it.”
Nope, not at all.
The key thing with literally any cloud deployment is thinking through the whole cycle and usage of the data. Whether you’re doing a cloud-first migration or just using it for backups, you have to think through the whole lifecycle of how you’re going to use it, and what happens when things go wrong – because they will. The cloud and cloud immutability can still be a very important part of a properly built BC/DR plan. We’ll talk about that in one of our upcoming articles!
Interested in learning more about your immutability options? Call us at 502-240-0404 or email us at info@mirazon.com.