This post was written by Brandon M. Mosak, Network Manager at Task Force Tips, Inc. and Symantec Customer
As a network manager for an SMB (and an ardent moonlighter), I’ve had the unique opportunity to see systems of various shapes and sizes serving a, seemingly, infinite gamut of needs. Over the years there have been many issues which have come to my attention in the Disaster Recovery (DR) space that, given proper amount of forethought, could have been avoided. As a general observation, most solutions which I’ve had the pleasure of correcting after the fact would have been a non-issue had the proper procedures for complete and consistent backups been applied from the get-go. As a small business, your data is your direct connection to your customers, your product, and, in turn, your bottom line. Your data is, arguably, your most precious resource.
So without further ado – I present you with the 5 most common SMB disaster preparedness mistakes I have observed over the years.
Not having a plan at ALL
It’s odd to think that in this day and age businesses would be operating by throwing caution to the wind and avoiding a DR solution altogether. Unfortunately, the aforementioned is more common than one would imagine. Common excuses include: “We have paper records,” “Backup is cost prohibitive for as little data as we have,” “Backups are complicated and time consuming,” and (my personal favorite) “I’m not an IT guy – and don’t understand such things.” Hogwash! Given the abundance of relatively cheap technology and a little know-how, even the most basic of environments can be protected in a manner akin to, simply, making a copy of a file on one’s desktop. While it’s hard to estimate the costs associated with line of business systems going down and critical documents going missing (as they vary from business to business), not having even the most basic of plans in place will, without exception, serve as a recipe for disaster.
Lack of proper planning for disaster
While backing up a file system is generally a straight forward process, it stands to reason that many SMBs are dealing with a considerably larger backup burden than just files. Taking all things into consideration (including applications being recovered, overall data size, and recovery requirements) is important at the onset of a DR deployment, and should be a maintenance item throughout the life of the solution. Every properly fought battle has always had a comprehensive plan at its roots, which morphed over time to suit the combat theatre. Make no mistake – DR is a continual fight where the foe appears occasionally, and without ample warning, delivers a swift blow to the heart of your organization. Things to keep in mind when planning for DR could include: How frequently are you backing up, and will you be able to tolerate a disaster in between backups? Will you have enough space to protect everything needed down the road (be it four months or four years)? When you install new applications, can you ensure they will be properly protected with your current DR solution? Does your retention policy make sense for what you need to protect? When you need to recover items, will you be able to do so quickly and efficiently? Which brings me to my next point…
Unwillingness to test a recovery scenario
While I, for one, can appreciate the mindset of letting sleeping dogs lie – practicing recovery for your environment while it is performing optimally is probably more important than taking backups in the first place. Do your backups provide bare metal recovery? How do you perform bare metal recovery to dissimilar hardware as it applies to your production environment? Are you dealing with databases, and does your backup leave it in a consistent state? What are the steps required to deal with disaster (be it a file deletion or an all-out catastrophe)? Having a TESTED plan in place prior to an incident occurring can make worlds of difference when the rubber hits the road. The last thing one needs to be doing is learning recovery “on the fly” when it matters most. Only when a solution is tested and proven can one rest easier knowing that “all things considered, the protection is comprehensive and functional.” While I can appreciate the awkwardness of wrecking a perfectly good server – the initial awkwardness will turn to confidence when the unthinkable occurs, because you’ll know that all your ducks are in a line and that recovery will be a snap.
Not storing backups offsite (or storing them on the server that is being protected)
I always get a laugh out of the customer that calls saying their backups have gone down with the ship. Be it via an Act of God, fire, theft, or run-of-the-mill hardware failure – storing business critical backups in proximity to the operation site is a critical misstep. While most SMBs go to backups to get the occasional file that gets moved / deleted, the core ideology of a complete DR solution is to have an “out” when the worst conceivable situation arises. Taking backups offsite typically only requires an additional step or two (with a little human intervention) and will serve to complete the circle of any DR scenario. It doesn’t matter if you use tape, removable disks, or the cloud, putting some space between your business and your backed up data is a prudent practice.
Falling victim to the “set it and forget it” mentality
Over the years, I’ve come onsite to many-a-job to see that the backup server is pulling exceptions (or all out failures). Similar to the organic landscape of your business data, backup systems need to be actively monitored for changes in behavior. Be it a bad tape, a corrupted backup to disk file, or file system object(s) which aren’t properly being backed up for whatever reason, errors need to be addressed quickly and comprehensively in order to ensure continuing protection. While most businesses start out with the best of intentions and vow to monitor their backups, it never fails that after a long string of successful executions, business owners are lulled into a false sense that “everything is ok,” allowing them to pay less attention to their scheduled jobs. As a quick fix, most all modern backup packages have the ability to hook into a notification engine to provide status updates. Be it notification via email, SMS, or simply checking the console – it is imperative to keep a finger on the pulse of your DR solution.
Adhering to the aforementioned suggestions will ensure a stable base to begin building a successful DR solution for your SMB. While there are many ways to skin a cat in the way of DR, it is important to note that backup, much like a snowflake, is a unique experience for each and every SMB. Above all, choose that which makes you most comfortable and guarantees expedient, complete recovery for your environment. And while it goes without saying, Symantec produces a wonderfully comprehensive solution with their Backup Exec 2012 suite. Having monitored progress from the early beta stages to the recently released gold build, I can absolutely recommend their new product for SMBs of all shapes and sizes with the utmost confidence in its ability to comprehensively protect your organization’s lifeblood. Better Backups For ALL!