Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Zombie Data

By Steve Jones,

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.

Total article views: 149 | Views in the last 30 days: 1
 
Related Articles
FORUM

How do I delete excess transaction logs.

delete/removing transaction logs

FORUM

Deleting Older backups

Deleting Older backups

ARTICLE

Maintenance Plans - Backups and Removing Old Files

Andy has written several good articles for us on maintenance plans - including some stuff that makes...

FORUM

Maintenance Plan not deleting physical backup file

SQL 2005, Maintinace Plan not deleting physical backup file

FORUM

Delete Backup Files

delete files within a backup (.bak) file

Tags
editorial    
 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones