Data Protection in Storage and Hyperconverged Infrastructure:

Demystifying Fact from Marketing Hype

Part One

Today’s topic is on data protection in storage and hyperconverged infrastructure. Specifically, “backup software” and its ability to be replaced by what capabilities storage arrays (SAN) or hyperconverged infrastructure (HCI) solution vendors claim they can provide.

This is a multi-part blog series. I want to dispel some of the myths and mysteries about certain topics in the information technology field where I think IT vendors’ claims can be very misleading.  I am not affiliated with any vendor, nor am I getting paid or endorsed by any vendor to write this series. These are just my personal opinions. I am doing my best to leave product names or vendors out of this series.  If I do mention a product or vendor, then it’s just as a frame of reference.  I hope that readers find useful information that can help make informed decisions.

What is Backup Software?

Let’s start out by explaining what I mean by “backup software” so we are all clear on this.  “Backup software” and the process of backing up data has been around since the inception of computers.  There has always been a need to take a copy of what is in the primary memory or storage and create a secondary copy.  This was done for obvious reasons.  If you lose your primary system copy, then you want to ensure you have a second copy (at least) of that data. This is known as “disaster recovery.” 

This was originally done on tape where that copy was kept locally so you had the ability to restore that data.  Also, another copy was made and sent off-site and so three copies are now considered best practice.  In the event something happened, like let’s say a fire in the main data center, then you had a copy off-site that is safe.  This was, and still is, also used for disaster recovery purposes.  I will get into that topic a little later, but let’s just look at the backup process for now.  That off-site copy also has a data retention policy that not only provides the ability to perform operational recovery, but also the ability to restore to the latest point in time and archive copies as well.  This is your traditional “grandfather, father, son” rotation.   

Today’s data backup is changing…

In IT, I think we are all familiar with the concept of dailies, weeklies, and monthlies.  So, there you have it, your basic backup procedure!  We have been doing this for ages in IT.  There are countless software companies that have created products that manage this process. We are not using tape very often and tape has been replaced with disk-to-disk-to-disk, but it’s the same concept.  Typically, these “backups” were performed on a nightly basis because they take a certain amount of time to traverse the system that needed to be backed up and copied to the secondary system. 

Introduction of Virtualization 

Now, that has changed somewhat with virtualization and the speed in which data can be backed up, but the concept is still the same.  The software reads changed data.  It then has to do something with the data to understand what that data is and how to treat it.  The software then copies that data to another target locally as well as off-site.  Today, that may be to an object store in the public cloud (AWS S3 is an example).

Along comes the SAN…

Data storage arrays are nothing new. We started to see the emergence of SANs that allowed for snapshots of data or otherwise known as “point-in-time copies” about a decade or so ago.  Companies like NetApp and Compellent are two vendors that were at the forefront of simplifying point-in-time copies of data. They also made it easy to restore that data.  These vendors did a formidable job with their technologies.  Even when other older technology vendors were building that capability into their systems, they were so hard to use. They were also very cumbersome and many people never even used them.  Hence, people relied upon traditional backups.  

Were these snapshots a backup replacement? 

Well, not really…  Snapshots allowed for the idea that you could take point-in-time copies of your data intraday (i.e. hourly snapshots as an example).  Backups that ran once daily meant that you had a recovery point of one per-day vs. now having 24 recovery points in my example above. 

Also, the restore process was very fast.  You were not restoring data across a network.  You were just going back to pointers of what that data looked like at that point in time.  The reason these snapshots were not a replacement goes back to what I said in the beginning: you need 3 copies of your data.  If you relied on your snapshots and the array or disks failed, then you would lose all primary and subsequent copies of data.  Snapshots were never intended to be a replacement for backups. 

But what if I copied my snapshot from one SAN to another SAN? 

Ah, now we are getting somewhere!  That would provide both primary and secondary in the sense I have a point-in-time prior to the current point plus a copy off-site.  On more advanced systems, I could create longer term retention policies by creating a GFS rotation of having the snapshots purged out of the system. 

So…what’s the challenge? Let’s go back to what backup software vendors did.  They not only created a product that allowed me to backup and restore data, but they more importantly allowed me to have an interface into understanding where the data was when it was backed up, who created it, what kind of data it was, etc. 

Specifically, what I’m talking about is the ability to do things like indexing files, coming up with an entire index of what files were created on which dates, and when those files were changed.  If you want to restore an individual file from 2 weeks ago in the accounting directory, then you have a way to see what that directory looked like and also search for that file. 

What are Database Backups?

A “database backup” is the process of backing up the architecture, operational state, and stored data of a database’s software. This creates a duplicate instance, or copy, of a database in case the primary database crashes, is corrupted, or is lost in a disaster. All database vendors have a process to backup a fully quiesced copy of a database where the logs have been truncated into the database or managed in some form to protect them from a transactional standpoint. 

Database vendors also provide the ability to create log backups with very low recovery point objectives on that database.  There are tons of examples, but the point is that these backup software vendors had to work with the operating system vendors plus application vendors to ensure they could back up these systems correctly. 

Problems with SAN Vendors

The SAN vendors, on the other hand, backed up entire volumes.  On those volumes you may have data, but it was your job to sort through it.  As virtualization emerged, I can now restore any VM to a crash consistent point in time. However, it was still very hard to find specific information. This requires a lot of work on the IT administrator’s part since there was no indexing.

This is an age old problem.  SAN vendors never developed an interface to allow administrators to really dive down deep into the data (there are a few exceptions to this which I will get into in a future post). There are some options when we look at the NAS vendors because they can  see the file system so they can theoretically index that data, but it’s still not a holistic approach.  This is fragmented at best.  It may have worked for some very large organizations, but not really in the mid-tier enterprise space.    

So where does that leave us now? 

Well, again with virtualization, we have seen advances.  Now we have the ability to have different backup policies on a per-VM basis with hyperconverged infrastructure solutions.  We can replicate these VMs on a per-VM basis so we do have that ability to become more granular. However, major components are lacking from calling the solution an “enterprise-grade backup product.”  SAN vendors who are doing what we consider traditional block storage also now have a very close competitor to hyperconverged infrastructure in a fully working version of VMware vSphere Virtual Volumes (vVols).  vVols gives the capacity to manage, snapshot, and replicate at the storage-level of individual VMs.  

So why can’t this be a backup replacement? 

This is simply due to poor application integration. Hyperconverged infrastructure/ storage vendors still cannot go far enough up the application stack to get the capabilities of a true backup solution.  If you have a very simple backup policy with a short retention policy, then you might be able to get rid of your backup software. This means you have to have two systems.  This is the first major caveat.  You need that offsite copy, but even then it’s really for operational recovery purposes only.  Vendors do a great job of providing disaster recovery and business continuity.  However, if you need to find a file to restore, then good luck!  Do you want to backup your SQL databases and truncate the logs? You better call your DBA!  Do you want to backup and restore objects in Sharepoint?  Forget it! 

Also, more and more people are using Microsoft O365 and now want to back up things like Exchange Online.  Well, you’re going to need a software platform for that. In most cases that means you have access to a full backup solution anyway. 

Hyperconverged Infrastructure vs. Traditional SAN

I also want to make another point about hyperconverged infrastructure vs. traditional SAN where SAN has an advantage.  Today, most backup software vendors have the ability to index the SAN vendors snapshots directly.  This is really nice because you can now restore files, folders, databases, or entire VMs from that hourly point-in-time copy.  Hyperconverged infrastructure can’t do that because software vendors today cannot see the internal snapshots on an HCI solution.  They have not exposed the correct APIs.  Some HCI vendors have their own solutions, but then you’re back to buying software again.  

Conclusion

Therefore, I think it’s a far stretch for storage or hyperconverged infrastructure solution providers to make these kinds of marketing claims where you can ditch your backup software.  Very few, and I mean very few, companies can do that today.  So, with that said, these claims really should not be the driving factor in selecting a solution.  They’re simply not the truth. 

The point of this post is to affirm that technology has come a long way. I think we are still a ways away from doing away with “backup software.”  

‘Till next time…

Dave Kluger, CTO of Storcom