SQLServerCentral Editorial

Zombie Data

,

Most of us that work with data are concerned about losing any of the bits we are responsible for. Many of us practice restores, complain about low disaster recovery budgets, and regularly check our systems for corruption. Even those of us that aren't extremely diligent in our daily actions are often worried about losing our jobs if any disaster causes data loss. Many of us don't even trust our users, preferring to implement logical deletes in applications rather than physically running a DELETE statement.

However there are times that we do want to remove data from our systems. We may find data quality is poor and want to erase the results of an ETL load. We may find ourselves bound by regulations that require the removal of data from our systems. We may upgrade old software and end up with copies of obsolete databases whose contents have been copied and reformatted by a new version of an application.

This article talks about the data-pocolypse, and in somewhat of a jesting way, but it has a few good points that we may want to consider when we do need to remove data permanently. We should understand that deletes are not always deletes, and if a permanent solution is needed, we should use a utility or physically destroy the hardware. However there are other places we should worry about old copies of data. Backups on remote storage that might not have cleanup jobs running anymore from decommissioned servers should be deleted. We should be wary about taking databases offline, or detaching them without physically removing the files. Development machines, laptops, etc. should have data removed if we are sure we don't need it again.

We should be especially careful about security access to servers that we are not using. Users might easily have links or pointers to old servers, so remove security when you decommission the instance. Be careful about file exports, such as reports or feeds that were generated in the past. It might not be practical to wipe backup tapes, but be sure you've changed documentation and surfaced the information to all administrators that copes of databases after xxx date are not useable in DR situations.

Of course the first thing you should do is make sure you have a good backup of the most current version of your data before you start deleting older copies. Delete this last, after you're absolutely sure that users are no longer going to request a restore. I wouldn't even ask users about this, however, because they may not be sure themselves. Instead I'd set a reminder a few months in the future to go back and delete this one, last, most current backup.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating