Zombie Data

Most of us that work with data are concerned about losing any of the bits or bytes we are responsible for. Many of us practice restores when we can, we complain about the low disaster recovery budgets we’re allowed, and we regularly check our systems for corruption. Even those of us that aren’t extremely diligent in our daily data protection are often worried about losing our jobs if a 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 to wipe the drive or physically destroy the hardware. However there are other places we should worry about old copies of data. Backups should be deleted from remote storage that might not have cleanup jobs running anymore if the servers are decommissioned. 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, and mistakenly connect. Make sure you remove access when you decommission the instance. Be careful about keeping old 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 restored from tapes 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.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.3MB) podcast or subscribe to the feed at iTunes and Mevio . feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.