Backups - Feasibility vs. Requirements
A recent conversation regarding application protection triggered me to think about feasibility vs. business requirements. This topic applies to pretty much any enterprise technology domain, but in this case, I want to focus on backup and snapshot technologies. I'll use Datrium as an example given its high degree of flexibility.
First some key technology fundamentals.
- Datrium provides native VM-centric snapshots
- Snapshots are non-intrusive and offer zero performance impact
- Snapshots may be configured as often each minute, allowing 1 minute RPO restores.
- 1.2 Million snapshots are supported
- 2,000 snapshots per VM are supported
- Entire datastores can be snapshotted at once
- Snapshot retention can be of any desired period
- Local snapshots enable Zero RTO restores
If the fundamentals above are presented to application owners as an elective SLA, they will likely choose the SLA that minimizes their downtime exposure. Every 60 minutes seem to be the response I hear the most, but 30 and 15 minutes RPO aren't uncommon.
Compared to current backup strategies that offer backups once every 24 hours, this is already a radical change towards improving application SLAs.
The next topic relates to the snapshot retention period, or how long the application owner would like to keep point-in-time copies for – and the answer is regularly anything between one and seven years.
Next, we start having a conversation about snapshots for site recovery vs. snapshots for ransomware recovery. Yes, those have very different requirements.
As an example, you may want applications snapshotted every 10 minutes and available onsite for the purpose of recovering individual applications from a ransomware attack keeping these for 24 hours. However, you may likewise want to have another time-series snapshot that happens every hour, is kept for 1 month and at the same replicated offsite for the purpose of disaster recovery.
The application X data protection schema could look like this:
- Time-Series 1 - 10 minutes RPO - 24 hours retention
- Time-Series 2 - 1 hour RPO - 30 days retention > offsite replication
- Time-Series 3 - 24hs RPO - 7 years retention > cloud replication
In this scenario, application X can be restored back to a known-good-state every 10 minutes for the first 24 hours, every 1 hour for 30 days, and every 24hs for 7 years. It seems like a good protection plan to me, but the application SLA is what defines if the plan is good enough.
Datrium offers metadata-based snapshots with compression and deduplication, and that certainly helps with data reduction across common datasets. However, if the data being created is not really de-dupable it will generate overhead that could use a reasonable amount of storage capacity. Further, it also comes down to the application data change rate - unique data being created.
Storage Capacity
Let's look at the same scenario from a storage consumption angle using Datrium Global De-Dupe Index across all customers (4.4x), but please note that your mileage may vary according to the data. Moreover, let's use an initial 100TB dataset to make the math easier, and for change rate let's assume 0.20% for 10 min, 0,4% for 1 hour and 1% for daily.
I'm not going to get into the calculation details in this post, but the total capacity required in this case with the snapshot frequency and retention period mentioned would be ~667 TB.
So it is important to ensure you have the adequate usable capacity or have plans to add capacity in the future since 668 TB will be the total capacity required in year 7. Datrium current upper capacity is 4.4 Petabytes, but insiders are already taking in Exabyte terms.
Optionally, you may prefer to have longer retention policies in a DR or Cloud site then on-premises.
Snapshot Counting
Another layer for decision making is the total amount of snapshots. Assuming we have 100 VMs backed up according to the schedule above we would have 352,000 snapshots after 7 years. However, if we are backing up 1,000 VMs with this same schedule there would be 3.5M snapshots, a number above systems limits today.
The engineering and QA teams are always improving system limits, but for production environments, the solution should be architected with current limits in mind.
Conclusion
As you can see there is tremendous flexibility in the way Datrium enables organizations to protect applications, but with power comes responsibility and IT must work with application owners to achieve the expected SLA within the existing constraints.
Just because it is possible, doesn't mean you should do it.
A more common approach nowadays is the creation of SLA tiers, such as bronze, silver, and gold that are then offered to the business as alternatives, eliminating complexity and ensuring the platform correctly sized.
This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net