Now we need to get to our final part \u2013 the need to archive rather than just blindly deleting.<\/p>\n
You might think that this and the previous article are at odds with one another, but in actual fact, I want to talk about the recklessness of deliberately using a backup system as a safety net to facilitate data deletion rather than incorporating archive into data lifecycle management.<\/p>\n
My first introduction to deleting with reckless abaddon was at a University that instituted filesystem quotas, but due to their interpretation of academic freedom, could not institute mail quotas. Unfortunately one academic got the crafty notion that when his home directory filled, he’d create zip files of everything in the home directory and email it to himself, then delete the contents and start afresh. Viol\u00e1! Pretty soon the notion got around, and suddenly storage exploded.<\/p>\n
Choosing to treat a backup system as a safety net\/blank cheque for data deletion is really quite a devilishly reckless thing to do. It may seem “smart” since the backup system is designed to recover lost data, but in reality it’s just plain dumb. It creates two very different and very vexing problems:<\/p>\n
- \n
- Introduces unnecessary recovery risks<\/li>\n
- Hides the real storage requirements<\/li>\n<\/ul>\n
In the first instance: if it’s fixed, don’t break it. Deliberately increasing<\/em> the level of risk in a system is, as I’ve said from the start, a reckless activity. A single backup glitch and poof! that important data you deleted because you temporarily needed more space is never, ever coming back<\/em>. Here’s an analogy: running out of space in production storage? Solution? Turn off all the mirroring and now you’ve got DOUBLE the capacity! That’s the level of recklessness that I think this process equates to.<\/p>\n
The second vexing problem it creates is that it completely hides the real storage requirements for an environment. If your users and\/or administrators are deleting required primary data willy-nilly, you don’t ever actually have a real indication of how much storage you really need. On any one day you may appear to have plenty of storage, but that could be a mirage – the heat coming off a bunch of steaming deletes that shouldn’t have been done. This leads to over-provisioning in a particularly nasty way \u2013 approving new systems or new databases, etc., thinking there’s plenty of space, when in actual fact, you’ve maybe run out multiple times.<\/p>\n
That is, over time, we can describe storage usage and deletion occurring as follows:<\/p>\n
![\"Deleting](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2011\/01\/deleting-with-reckless-abaddon.png\" "\\"Deleting")
<\/a><\/p>\n![\"Data](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2011\/01\/Data-Lifecycle.png\" "\\"Data")
<\/a><\/p>\n