"All we can afford is tape."
"We're small - so we can't afford enterprise stuff."
"We only have 40 people. If we have to recreate something, it isn't too bad."
Respectfully, none of these are reasons -- they are all excuses -- and they are mostly inaccurate.
The US Dept. of Labor once surveyed what happened to small businesses who experienced a significant crisis, including fires, hurricanes, tornadoes, etc. What they found is that not all businesses were able to re-open at all. Some that did eventually re-open later closed for good because they weren't able to re-capture their clientele. Overall, the survey found that 2/3 of those SMBs failed because of a major crisis. I would suggest that the primary cause was a lack of preparedness, likely because of one of the reasons above -- so let's revisit them.
"All we can afford is tape."
WRONG -- no one, of any size, can only afford tape. For most crises, ranging from regional weather catastrophes to single hard-drive failures, you don't need last month's or last year's data from tape. What you need is yesterday. You need it online, now! By definition, that is not tape -- that is disk. The reality is that what you cannot afford is "just" tape. Whether you start with an external disk drive or engage with a cloud-backup provider, you can afford something (anything) better than tape.
"We're small -- so we can't afford enterprise stuff."
PARTIALLY TRUE - you can't afford "enterprise stuff." But hey, you don't need enterprise stuff since you aren't an enterprise. If you did run an enterprise infrastructure, with all of its scale and complexity, then you could afford enterprise stuff. But you don't, because you are an SMB. As an SMB, you'll likely have a more straightforward collection of IT assets, such as file serving devices, some applications which are likely based on some SQL platform, perhaps a mail platform or two (unless you run from a cloud-provider) and perhaps a custom application platform. The great news is that these kinds of platforms are very cost-effectively protected. File serving can replicate, either within the file system (e.g., Windows Server DFS) or the storage layer, applications like databases and email can often replicate between multiple instances -- often yielding not only resiliency but higher performance due to load balancing. Any server platform that isn't natively resilient can usually be encapsulated into a virtual machine and then replicated and re-booted from a mirrored virtualization host.
The punchline: you don't need "enterprise stuff" to protect your SMB IT infrastructure. In fact, in many cases, resiliency features are already built into what you already own.
"If we have to recreate something, it wouldn't be too bad."
Almost definitely WRONG, because most SMB data is unique. This means that if something took you 60 minutes to do the first time, it will likely take you 45-50 minutes to recreate something that was done recently and potentially 90 minutes to recreate older content that you still need. You'll potentially gain some efficiency because you already have the intended outcome in your head -- but it still will take the majority of time to repeat. But if you lose several days of data, can your SMB workforce tolerate the several days of recreating work that you've already done and likely already gotten paid for?
Since I've tried to dispel some presumptions, here are some factual SMB IT realities:
One of the key differences between how enterprises and SMBs tolerate crises is cash flow. Based on the kinds of business that has recurring and/or pipelined revenue or just because their bank accounts are bigger, they are often able to suffer cash flow issues while they reconstruct. SMBs typically lack those deep coffers or assured income, so it is even more important that SMBs proactively deal with business continuity since they won't be able to roll up their sleeves and bear through their recovery efforts
Another reality is that most SMBs don't have deep IT veterans on-staff and waiting to throw on their superhero capes and jump into action during a crisis. This isn't meant as a disparagement, as I know several IT Pros that work in SMBs who have built near-enterprise quality and services into their smaller IT infrastructures. But as is much more common, I have met many brilliant IT implementers working for systems integrators and consultants, who provide their services to SMBs. In this way, SMBs get deep IT expertise when they need it (billable), but don't have to pay for it when they don't -- often as a project-level supplement to their in-house part-time IT person. And like most things in IT, that works great when everything is working ... and is painful when something breaks. First, because when an SMB has an urgent outage, the right guy may not be available for immediate resolution. And secondly, while the SMB is down and likely losing revenue, they have to do the one thing that they don't want to -- pay for something expensive, a billable IT expert.
So, what is an SMB to do?
Invest pennies now ... instead of dollars later. Today, most key workloads that an SMB relies upon are natively resilient -- if you turn the features on:
- SQL Server and Exchange both offer replication with transparent failover through Database Mirroring and DAG, respectively.
- Windows infrastructure services (AD/DNS) are natively resilient and easily solvable with a simple secondary instance (running in a VM).
- Windows Server (file services) has DFS to transparently replicate/load-balance and resume service between servers and sites.
- Even virtualization platforms can be made resilient for far less money than you might think.
The reality is that SMBs arguably need resiliency as much, if not more than, some enterprises -- and the tools that they need are more often than not already owned by them. I am so passionate about this (using the built-in HA/DR technologies that you've already paid for) ... that I wrote a whole book on it = Data Protection for Virtual Data Centers ... also viewable at DataProtectionBible.com.
Whether you read the book or not, if you are an SMB, look at the core workloads that you are running in your shops - and then look in their product documentation for "availability" or "replication." You may be happily surprised with what you find - and already own.