Deleting Data: We Can Do This the Easy Way or the Hard Way

The easy way or the hard way? Sounds daunting, the reality is it doesn't have to be. I talk to a lot of organizations who never delete data, and I love to understand why this is the case. It is not hard to delete data; its just the consequences that may become a resume-generating event.

Let's start with the hard way. It will make the easy way sound much more attractive. Unplanned data loss, in general, is never a good thing and seems to have some sort of root cause that becomes a lesson learned. In some cases, there is a gap in a fundamental data policy. A data policy can be the gateway to the easy way.

Let's focus on the good news. A data policy can enable data to be deleted, but it has a much clearer benefit: the data you don't want to delete is tended to better in every regard. One thing I talk to a lot of organizations about is deciding how to remove data (systems, storage, etc.) from a data management and administration strategy. The good news is that there are many ways to address this with stakeholders, and if IT staff can get that agreement on how data is to be removed, we can reduce occurrences of the hard way of deleting data.

This policy can be done in several ways; a hierarchical approach to the data is one common approach. Additionally, a data lifecycle management strategy can achieve the same goal. This is usually done as a combination of four main elements: a backup solution, a storage solution, a storage administration team, and communication with the business.

Take, for example, a simple step in deciding which systems or data to explicitly not backup or prepare for site-to-site disaster recovery (DR). Getting agreement from the business and ensuring the configuration is correct to “not” backup selected systems is an important step. This is usually aligned to test and development systems and can be an important, positive change regarding resource usage for backup infrastructure and DR resources. Organizations can implement these types of policies as systems are created, answering the question if something is or is not to be backed up.

Another scenario would be a system that is aging out of production online status. One approach to deleting this type of data would be ensuring its backup retention is in line with the requirements in place and deleting it. Keeping in mind its retention from a backup perspective should be able to meet the needs of the business in case there is a query on it. Making another copy of the data in a storage-efficient manner (compressed, deduplicated, etc.) is an option on a lower-tier of storage for additional retention, potentially longer than the production retention requirements.

What is the central theme in strategies like this? Endorsement and understanding from the business. Classification of what systems and data need to be protected, retained, made available – or not. If there is clear communication, support, and endorsement on what needs to be kept and what doesn't; IT organizations can be in a situation where they can provision the best resources for the workloads that need it and avoid needless quantities of data that are continually migrated and protected with no real business use case or need.

This will become more and more important as explosive data growth continues in many areas. Do you have a policy to actively delete data and manage it? You may want to start now if you haven’t before it becomes a real problem.

Related Network Computing articles:  

Rewriting Disaster Recovery Plans for the Edge

Software-Defined Storage: Getting Started