Risk

8/27/2010
04:35 PM
Commentary
Commentary
Commentary
50%
50%

Practical Analysis: For SMB Backups, Think Hybrid Technology

Building a system to protect your data can't be a one-size-fits-all endeavor.

InformationWeek Green - Aug. 30. 2010 InformationWeek Green
Download the entire Aug. 30. 2010 issue of SMB, distributed in an all-digital format as part of our Green Initiative
(Registration required.)
We will plant a tree
for each of the first 5,000 downloads.

Michael Davis

Want to grab a small-business owner's attention? Accidentally delete a critical piece of data. Suddenly, backups are cool, and everyone's perusing shiny brochures touting old-school tape, disk-to-disk, cloud-based, and hybrid systems tailored to the needs of small and midsize businesses, while external consultants promise recovery-time objectives shorter than Justin Bieber.

But how do you know what's best for your business?

First, it's unlikely to be a single, uniform system. You have more than one type of data, so expect to remix technology, too. Start by answering some basic questions: Where's the data that needs to be backed up? What type is it? Where should it be stored to minimize the risk of a disaster wiping out the backup? Is the cloud right for your company? And what skills do you have in-house to get all this done?

A common gotcha: Your most critical data probably isn't on your file server. In most SMBs I work with, employees save a lot of important stuff on their hard drives, intending to transfer it to the file server "later." We know how that goes. So before buying any hardware, tweak your business processes to ensure the system you implement actually will back up the data you need to safeguard. The answer could be as simple as a mapped drive or offline file sync or as complex as folder redirection and a VPN.

Next, be realistic about your staff. Disk-to-disk and tape systems require actions be taken, such as shipping disks or tapes off site or changing media if the data being stored exceeds capacity. A system may have all the bells and whistles you can think of, but if it hasn't performed a valid backup in months because someone forgot to do something, you're worse off than before. And cloud-based backups have their own problems--some don't support business applications, like Microsoft Exchange and CRM software.

The last step when building a backup plan is to define the types of data you collect--sales quotes, research stats, CAD drawings--and determine how quickly you need access to each, a process called tiering. Once data is tiered, hybrid backup systems can be tailored to lower cost and risk. Hybrids use more than one type of backup technology to provide a lower overall cost to the business. For example, cloud backups are inexpensive but normally slow to retrieve since you're downloading over the Internet, compared with fast, and expensive, disk to disk. So place the files you need access to quickest during a disaster on the disk-to-disk system and the rest in the cloud.

There are many ways to construct tiers, such as by data type or age. The idea is to match the backup system's attributes--cost, access speed, and reliability--to your data, not the other way around.

Last, and most important, don't rely on IT consultants to manage your backups. They can, and possibly should, install the system for you. But spring for training, and make sure they rig alerts to tell in-house operations people or office managers about problems. Too many times I've seen backup failures fall through the cracks for weeks because the alert was sent to an outside IT consultant who hasn't been on site for months and isn't all that concerned about your data anyway.

Advances in backup technologies over the past few years have reduced costs and are providing better and faster access to data. But don't get caught up in hype--if you aren't protecting what matters, don't have the right staff to support the system, and are piling useless information on expensive storage, all the advances in the world won't help you get back an accidentally deleted file--never mind survive a disaster.

Michael A. Davis is an InformationWeek Analytics and Network Computing contributor and CEO of Savid Technologies, which was recently ranked at 611 in Inc.'s list of 5,000 fastest-growing small businesses in America. You can write to us at [email protected].

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11354
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the IEEE 1905.1a dissector could crash. This was addressed in epan/dissectors/packet-ieee1905.c by making a certain correction to string handling.
CVE-2018-11355
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the RTCP dissector could crash. This was addressed in epan/dissectors/packet-rtcp.c by avoiding a buffer overflow for packet status chunks.
CVE-2018-11356
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the DNS dissector could crash. This was addressed in epan/dissectors/packet-dns.c by avoiding a NULL pointer dereference for an empty name in an SRV record.
CVE-2018-11357
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the LTP dissector and other dissectors could consume excessive memory. This was addressed in epan/tvbuff.c by rejecting negative lengths.
CVE-2018-11358
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the Q.931 dissector could crash. This was addressed in epan/dissectors/packet-q931.c by avoiding a use-after-free after a malformed packet prevented certain cleanup.