Data Protection for Higher Education – Evaluating Retention Periods, RTOs and Acceptable Data Loss

Gary Parker, Sr. Product Marketing Manager

Data protection is no easy feat in the world of higher education. Recognizing retention periods for varying sets of data, determining required recovery times for each set, and mitigating data loss can be daunting tasks. Not to mention, you are often protecting a wide array of data while supporting thousands of users that range from those who are just sending personal emails to those conducting the most delicate of research projects And, when something goes wrong, it’s likely you’ll be inundated with a flood of complaints.

But instead of focusing on a reactive situation, let’s turn our attention to the objective of complaint prevention.

The very simple steps of a thorough data protection strategy are so often overlooked. Where does an IT professional supporting a higher education institution really need to start? It’s more than just understanding your data sets. Your team should really put the following in writing for each set and adhere to it:

1. Retention period
2. Recovery time objectives
3. Amount of acceptable data loss

Let’s take a quick look at retention periods for a typical academic computing environment. Thinking this through will help you get data to the correct, most cost-effective storage medium and determine your method for storing it on that medium. You will likely have at least some of the following data sets. As an example, I asked BakBone customer, Martin Frankhouse at University of Detroit Mercy, for an overview of his typical retention periods, knowing that these definitely vary from institution to institution.

1. Student Activities – 90 days
2. Student email – 90 days
3. Course content – 3 years
4. Catalogs – 10 years plus
5. Grades – Decades
6. Research Projects – Potentially decades

Recovery time objectives could actually run on the same scale as your retention periods. For example, student email may have a short retention period and likely have a short recovery time objective. It may not be important enough for long term storage, but you better be able to get it back up and running fast in the event of downtime.

Video – Experts and Insights: How to Avoid Downtime

We all know that downtime is a huge issue for everyone, especially as it affects email, databases and file servers. In this Experts & Insights video, we take a close-up look at the data protection challenges and solutions surrounding downtime. Featured experts include Stephen Wynkoop, Microsoft SQL Server MVP; Arun Taneja, Founder and Consulting Analyst with The Taneja Group; Robby Wright, Chief Technical Consultant from Abtech; Dennis Martin, President of Demartek; and Mark LeBlanc, Network Specialist at the Edmonton Public Library.

Can Your Team Meet Your Service Level Agreements (SLAs)?

Scott Hetrick, Director of Technical Services

OK, so I kind of like being the good guy. Granted, there’s nothing too heroic about showing people the problems that sit right on the surface, but that’s exactly what I do. I’ve spent the bulk of my career visiting countless data centers of all types and sizes, and it astounds me every time how many people are not aware of potentially devastating problems until systems are down, data is lost, and business is impacted. And, I don’t mean impacted in a good way.

Service Level Agreements (SLAs), when written, are an attempt to ensure that downtime and data loss are minimized to a tolerable level that will not negatively impact business processes and revenue. However, in my experience, far too often the written agreement can’t even be achieved or, worse yet, is never drafted – it’s just an “understanding,” if that.

The impact of not meeting an SLA differs from organization to organization; however, one thing runs constant, there are monetary, productivity, and morale consequences. You may be one of those organizations that has an external SLA with a client and you know the exact dollar value of your “fine,” should you underachieve, not to mention the risk of losing the client completely. On the other hand, you might have internal agreements, written or understood, which require staff to spend tremendous amounts of overtime to meet, should something bad happen. What’s the cost of overtime, lost productivity, and negative morale? Hopefully, you are one of the lucky organizations that know the answers to these questions and has the systems in place to meet a clearly defined SLA. I would like to meet you, because, unfortunately, you are a rare client.

I always ask clients if they test restores. To date, no one we’ve found has a documented procedure for testing recovery. You don’t know if software upgrades have corrupted anything. You don’t know if you’ve backed up bad data. You don’t know if tape is bad. What happens when a restore doesn’t work?

When it comes to SLAs, what is the confidence level of the typical CIO I meet? Frankly, not too confident. Even when he/she hears the department say, “Yes, we’re covered,” the story I hear too frequently is the CIO discovering SLAs cannot be met when something bad happens – discovering this AFTER something bad happens. And, what reasons are most often given by departments for missing SLAs? “Well, budgets got cut.” “We have new staff.” “We were never correctly trained on the products we have.” I hear these excuses repeatedly and have yet to find a CIO willing to accept any of them.

The unfortunate part of my customer interaction is witnessing the disconnect between business managers and the IT department. Surely there are organizations that do everything by the book, but more times than not, it’s not the case. For example, I worked with a client who had an Exchange failure. The system admin, a very capable individual, worked to fix it with the understanding that he had 24 hours to do so. Meanwhile, the CEO was calling his manager exactly every 14 minutes for a status update. Needless to say, there were unfortunate ramifications for individuals due to the miscommunication. What was the SLA with regard to their Exchange system? It was unknown, because no one was on the same page.

Duplicating Backups – Selecting between Duplication and Data Copy

Steve Adler, Technical Support & Operations Lead

We back up our data so that in case of a data loss event, we have the ability to restore that data. But how do you protect the data that you’ve backed up. You can send it offsite, but what happens if that offsite location is affected by a catastrophic event? It’s simple really. Make another copy!

NetVault: Backup provides two different ways to make additional copies of your backups. Duplication and Data Copy. What’s the difference?

The Duplication method creates an exact secondary copy which is linked to the original primary backup. During duplication, the copy is broken into segments and stored on the secondary backup device. During restore, segments from the primary copy and the secondary copy are interchangeable. This means that even if you no longer have all of the original tapes, as long as the media that contains the duplicates of that data is available, you’ll be able to restore that data. You can basically “fill in the blanks” with the duplicated data.

However, encrypting that data for added security can pose a problem. It is impossible to unencrypt the primary backup and encrypt the secondary copy because it is not possible to mix unencrypted segments with encrypted segments during restore. If the original saveset is encrypted, the Duplicate method will create an encrypted secondary copy. If you have no encryption for the primary backup, the secondary copy will also be unencrypted.

The Data Copy method is recommended when you want to create a secondary copy for offsite storage. Data Copying a backup breaks the backup into segments and copies the segments onto the targeted backup device. During restore, NetVault: Backup only restores the primary copy or the secondary copy. Backup segments from the primary and the secondary are not interchangeable. This means that if you are missing part of the original backup, you will need the entire secondary copy available to perform a restore. You can’t just “fill in the blanks.” However, this enables the ability to encrypt the Data Copy, or secondary copy, while the primary copy remains unencrypted such as with deduplicated primary backups.

By incorporating one or both of these strategies to copy your data, you can decrease the chance of losing your backups to a catastrophic event so you can recover your data when you need it.