Resolution 7: Tiering Data and Apps

April Fools Day was this week and I wonder how many people took a look a their data protection thanks to the efforts of World Backup Day that happened on the 31st? I also wonder how many admins are played jokes on their bosses by claiming to have lost data, or failed to protect critical information? Probably not many.

Seriously though, lets discuss something that isn’t funny. Tiering. Tiering Data and Apps is one of the 15 resolutions for 2015. Cataloging your data and your applications into tiers based on importance and criticality specifically. Why would you do this? So you can start building appropriate policies which can easily be translated into offerings for your internal IT services catalog. It also helps you save money, time, effort, and hair pulling.

Each organization has a number of different applications and different collections of data. Each of them need to be treated differently, and in many cases I find the clients I speak with have 2 tiers. Prod, and Non-Prod. The problem with this overly simplified classification is that you end up protecting things that in many cases don’t need to be protected, or protecting things with a policy that is too aggressive. Let’s take a simple example data center and break down the data sets. In this example the admin has two database servers that run their core business application. One of the two servers are used by the development team, and the other is hosting the live production copy of the database along with some other databases for internal applications like HR, their CRM, their ERP, etc. Their is a web server front end that the customers use to access the application externally, a mail server that the organization uses to communicate internally and externally, and a couple utility servers that IT uses to host monitoring platforms, their virtual infrastructure management, etc. All of this data is hosted on a storage array, and is protected with a deduplicated backup appliance and software. Seems easy right? Back it all up! Wrong. Instead, consider what disaster scenarios you are protecting the environment from and create policies that will get your services back online quickly.

First thing to do in a failure scenario is ensure the company can operate. That means making sure your customers can consume your widgets or services. In this case that is the application. That is made up of a database and a web front end. What does it take to get that back online the fastest? Two paths. Build an OS, install database application, build a second OS, install web services. Restore the database server, and then restore the web services. Two days later, you finally can start making money again. Not terribly efficient. Another option would be to have a template of your VM ready to go which you can quickly clone and bring online. Then you simply need to restore the database and the webs services configuration and you can be running. Hours later the disaster is over. If you didn’t tier that application as critical and consider the required steps for recovery, you may not have the pieces in place to get it back online. What about the rest of the environment? The mail server, the utility apps, the dev server, etc. All of these play a different function and different criticality. I suggest you have a 4 tier approach with the following suggested recovery objectives.

[gtaccordion title=”Tier 1|Tier 2|Tier 3|Tier 4″ accids=”1|2|3|4″]Tier 1 – These applications can never be offline. RTO = 0/RPO = 0 | Tier 2 – These are critical applications that need be brought back online quickly. RTO = 1 hour/RPO = 15 minutes | Tier 3 – These applications have data that can’t be lost and when offline greatly hamper productivity. RTO = 12 -24 hours/RPO = 4 hours | Tier 4 = These applications have data that can’t be lost. RTO = 48+ hours/RPO = 24 hours[/gtaccordion]

By walking through the exercise of tiering your apps you get the benefit of ensuring that your data is protected correctly and efficiently. Don’t protect data that you should replicate. Don’t retain data that you don’t need after a few weeks. Don’t protect data that you can recreate/clone/copy faster than restore. And build a catalog so that you users can choose their own protection method. Be sure to associate a cost as well so that they know the impact of their choice. Bottom line, tier those apps and data!