The 5 Users Who Are Killing Your Backup Storage

You've probably met Packrat Perry. He’s saved every Word doc, LOL Cat gif, chat transcript and PowerPoint presentation he's come across for the past five years. In his mind, there’s no such thing as an expiration date for digital data.

If A&E had a digital equivalent of its hit show Hoarders, the first place they’d start filming is in Packrat Perry’s messy hard drive.

Spiceworks user John773, a storage architect from Texas, came up with Packrat Perry and other backup storage archetypes in a post for a series on backup storage on the Spiceworks Community site.

Get to know some of these backup storage troublemakers:

Oblivious Olivia

This backup operator is easily spotted by her out-of-sight and out-of-mind attitude towards backups in general. She may simply ignore backup failures or not even notice she is no longer receiving backup alerts. She often is busy, but taking 5 minutes to check in on backups periodically does not cross her mind.

Forgetful Fred

Fred set up the backups some time ago and even checks the error reports. He fixes media errors, but he still has some gaps in his memory. He may even have fancy new virtual machine backups that allow for easy restore of entire servers at the push of a button. Unfortunately, Fred forgot that they added another folder or even another server and did not add it to the backup job. These small gaps in process can lead to big pains as the old database server may still be backing up but the new one hasn’t had protection for months.

Packrat Perry

Perry is not a backup operator but he is their worst enemy. He is the manager with a 20 gigabyte mailbox or 10 years of documents that must be preserved. His thirst for data retention beyond any reasonable time period inflates the cost of storage and drags backup windows into the daylight hours. With budgets exhausted and performance slowing down, corners get cut and data gets lost.

Redundant Randy

Randy is obsessed with redundancy. If we use RAID to replicate our data between disks, and DFS to replicate data between file servers and replicated SANs, why would we even need backups? Randy does not realize that systems that synchronously replicate data also replicate corruption and accidental deletions. A simple raid controller failure is something that Randy can fathom, and when someone saves over a critical file he cannot find the data in the 6 copies of it that he has.

Snapshot Sam

Sam loves snapshots. He has snapshots of files using windows volume shadow copy, he has snapshots of virtual machines, and he even has snapshots of his SAN. What Sam does not have is redundancy or replication of data, and all his snapshots sit on the same storage or in the same device. Sam is the opposite of Randy. His obsession with hourly granular recovery for six moths has him storing all his backups on the same disks as his data. Perhaps at some distant time in the future when “budget becomes available,” they will purchase a second device to replicate to offsite, but in the meantime backups seem recoverable.

For more information on the usual suspects of backup storage, read John’s post on the Spiceworks Community.