Backup is always that unsung hero. It’s there in the background, and no one notices it, that is until it’s needed. And with the ever-growing volume of data, backing up becomes more and more of a challenge.
Sure, storage companies continue to push the envelope on hard drive sizes, now reaching upwards of 10+ TB per disk or more. But the challenge really comes, not in the local storage, but in the long-term retention.
Tape drives have long been the default (and only) option for long-term data storage. But there are several challenges in using this technology. For example, let’s assume that you have some legal/regulatory requirements to keep data for 10 years. In the time span of 10 years, more than likely your tape library system will either A) Be out of warranty, B) Have been replaced by a newer/different model or C) All of the above.
Now think about this scenario: Your organization suffers some catastrophic event, or have some specific reason that requires you to restore data from 10 years ago. Now you’re faced with recalling the tapes and finding a tape library system that is compatible to mount and read the tapes. For a 10-year-old library system, you would be hard pressed to find something available.
So, what is the solution? Two words: THE CLOUD.
Azure Backup is an Azure-based service that you can use to backup your data for long-term retention. It even automatically includes storage replication for redundancy.
Azure Backup has 4 differing components, depending on the scenarios and systems you want to protect. Instead of re-hashing the list here, here is the direct link to the Microsoft documentation: Which Azure Backup components should I use?
Let’s compare with a little math.
Let’s assume in a normal environment, that the following backup cycle is applied:
- 14 x Daily backups (one per day, kept for a 2 week period)
- 4 x Weekly backups (one per week, kept for a 1 month period)
- 12 x Monthly backups (one per month, kept for a 1 year period)
- 1 x Yearly backup (one per year, kept for N-number of years)
Let’s also throw in the assumption that each backup is contained on a single tape drive (This is inaccurate as data volumes can easily span multiple physical tapes). And while we’re at it, let’s pretend there is 0% data growth to account for (Again, inaccurate since data grows exponentially at a rate of approximately 50% – 60% annually).
Now, let’s compare Azure Backup to the equivalent number of tapes used in this equation. Azure Backup can store data up to 99 years! But let’s use 10 years as a more realistic scenario. So, adding up 14 Daily tapes, 4 Weekly, 12 Monthly, and 9 Yearly (to reach 10 years total); we arrive at 39 tapes.
Obviously, this is grossly inaccurate, since data volume constantly grows, but it serves the purpose of this example.
So by using Azure Backup as a replacement to your tape library, you save:
- 39+ tapes
- Backup Software License and Maintenance
- Tape library hardware costs/maintenance
- Break/Fix Maintenance Calls
- Tape Vaulting Services
Let’s look at it another way. Let’s assume that each Daily backup is 1 TB. Using the same numbers (14 Daily backups, 4 Weekly, 12 Monthly, and 9 Yearly), we arrive at 30 TB in a year. Now let’s include the estimated data growth rate of 50% annually. <Calculating>… and we arrive at 1,153 TB (or ~1.2 PB) of data.
Either way, that’s a lot of data. But with Azure Backup, there is no limit on the amount of data you can back up to a vault.
Experience From The Field
When you step through the Getting Stared guidance for Azure Backup, the first thing you need to specify is where your workloads are running. Let’s assume we’re targeting workloads running in our own on-premises datacenter.
What’s important is identifying what you want to backup. However, here’s the important thing. You should choose ALL items/scenarios from the list that you MAY want to backup.
Maybe you’re only interested in Files and Folders right now. That’s fine. To backup that content you can utilize the Recovery Services Agent, which will communicate directly from your source system to the Recovery Service Vault.
But, let’s say down the road you want to backup Virtual Machines, a specialized workload like SQL, Exchange, or Sharepoint, or maybe even Bare Metal. If you think you may need to backup any of those other types of systems, then select them now.
Why? Because the Recovery Services Agent in it’s standalone form, does not work with those. If you choose Virtual Machines, specialized workloads, or System State/Bare Metal, then the options for utilizing Azure Backup change.
Instead of deploying the Recovery Services Agent, you will instead need to deploy either System Center Data Protection Manager (DPM), or the Azure Backup Server. This will require you to setup on-premises infrastructure. Big difference than just deploying a simple Agent.
Side Note: Wondering what the difference is between DPM and MABS? Take a look at my article entitled: Microsoft Azure Backup Server (MABS) AKA DPM “Lite”.
Whether you’re backing up a few files and folders, or multiple Petabytes of data, Azure Backup can significantly help you with your backup needs. Why not get started today?