I\u2019ve been in IT for over 25 years and spend much of my time rubbing elbows with IT pros that specialize in certain parts of the industry. So, when I talk a lot (and I do) about backups, there\u2019s sort of an assumption that the IT pro I\u2019m interacting with has the basics down.<\/p>\n
But, as those of you in SMBs know, it\u2019s never that easy. You have so many hats (including backup) to wear, that you often need a little push in the right direction so that you don\u2019t need to try and reinvent the wheel as it were.<\/p>\n
So, what\u2019s the right way to plan out your backup strategy for small business?<\/p>\n
I\u2019ve written (and will reference here) a bunch of articles over the past two years about the various hows and whys of backups. But, rather than make you search for each of them, I wanted to consolidate them (alongside some articles on this blog written by other contributors) into a single, practical plan for small business disaster recovery and backup.<\/p>\n
I\u2019m going to walk through the steps by posing them as questions that you may (or may not) have considered. That way, if you are well past a given step in your thinking and\/or execution, you can jump ahead to the next one.<\/p>\n
For those of you thinking the question is ludicrous, you can skip down a few lines. But there are some businesses today that are materially larger than a SoHo that still don\u2019t have a backup in place. You need one for a number of reasons.<\/p>\n
Other articles to read:<\/p>\n
Are your clients ready for a major weather event?<\/a><\/p>\n „Where did my server go?“: How to defend against ransomware<\/a><\/p>\n I have a backup of critical files going to a cloud sync provider. But, that\u2019s a single laptop. Sure, you can sync up the important files and folders on your one file server to Google Drive\/OneDrive\/DropBox\/etc., but that sync won\u2019t address the problem of you potentially losing the entire server. Sync tools are great for simple backups of file sets, but they are not a replacement for a true backup that allows your business to recover (and not just some files).<\/p>\n Check out the following article for more on this:<\/p>\n Sync and share solutions; no substitute for Backup<\/a><\/p>\n You\u2019ve got a wide range of options here, as every vendor shouts at the top of their lungs that\u00a0their<\/i>\u00a0way of doing backups is the best.\u00a0 First off, you need to decide does your business require an\u00a0ability to restore, an ability to recover<\/a>\u00a0or an\u00a0ability to maintain availability<\/a>\u00a0of services? Since I have no idea what your specific needs are, you\u2019ll need to do some soul-searching to determine just how \u201cup and running\u201d your business needs to be.<\/p>\n Then there\u2019s the issue of where you should store your backups. You can keep them on-premises, in the cloud or use a\u00a0hybrid mix of both<\/a>. There are pros and cons for each, but the basic thinking is if you use only one (either on-prem or in the cloud) to store your backups, you\u2019re missing out on the ability to recover from a loss of location or loss of Internet connectivity. By having hybrid-cloud backups, you retain sync\u2019d backups in both locations, increasing your ability to recover from just about any disaster.<\/p>\n In a word?\u00a0\u00a0Everything<\/em>. The whole point of disaster recovery for a small business is to provide an ability to recover regardless of the loss incurred. One of the simplest ways to accomplish this is to perform image-level backups, where the entire system (whether physical or virtual) is backed up as a single data set (more on this later).<\/p>\n Given, you may be reading this because you don\u2019t have your backups in proper order, you should at very least be considering the backup of critical servers and services that you know your business can\u2019t be without for very long.<\/p>\n Backups can be created using two basic methods \u2013 file-level and image-level.\u00a0File level<\/a>\u00a0is perfect for backing up files and folders on your file server. It also can serve as the means to backup a database for a given application. Application-aware backups (those that are already aware of what needs to be backed up for a given application) can simplify file-level backups by intelligently capturing all the relevant data sets needed to recover an application.<\/p>\n Image-level backups are perfect for when you want to protect an entire system at once. They also give you access to fast recoveries both locally and remotely using a\u00a0continuous recovery model<\/a>\u00a0(where a restore of each backup is performed as the backup is created).<\/p>\n (Here\u2019s a great recovery map<\/a>\u00a0we built a while back that helps you decide.)<\/p>\n One of the challenges (from a technical execution perspective) in defining what needs to be backed up and which method to use is the fact that you can\u2019t really do it without first knowing what the disaster looks like that you\u2019re preparing for.\u00a0 It\u2019s like packing your clothes into a suitcase without first knowing where you\u2019re going on vacation. It\u2019s important to first\u00a0define the \u201cdisasters\u201d<\/a>\u00a0you\u2019ll be protecting your business against so that you can determine what needs to be backed up.\u00a0 For example, if you\u2019re only worried about files being deleted, performing image-based backups makes no sense. Likewise, if you\u2019re wanting to protect against a complete loss of location, having file-level backups of every server will equate to a MUCH longer recovery period than you\u2019d like.<\/p>\n For each data set, application or system you wish to recover, you need to establish some parameters around what the recovery of said recovery set needs to look like. There are a few industry staples to assist. The first is your\u00a0recovery time objective<\/a>\u00a0(RTO), which is the amount of time you will take to recover. Next is your\u00a0recovery point objective<\/a>\u00a0(RPO), which represents the target amount of data lost. Last is the maximum tolerable period of disruption (MTPoD), which represents, should you miss your RTO. In other words how long can you go before the business REALLY begins to suffer.<\/p>\n You need to establish these values for each backup set you wish to recover, beginning with the most critical and working your way down. The reason is that once you determine that your website needs a recovery time of, say, 10 minutes, and a recovery point of only 15 minutes, you may shift your current file-level backups to an image-level continuous recovery scenario. See how this all comes together?<\/p>\n Some other reading on this subject:<\/p>\n What’s your RTO\/RPO and how do you calculate it?<\/a><\/p>\n 3 Tips for Shrinking your RTOs and RPOs<\/a><\/p>\n The plan itself should start with outlining the various data sets and the disasters you want to protect against. Then dive into each intersection of the two. The detail here should entail first, what data set is being backed up and then the plan to recover. I\u2019ve done these where I literally spelled it out click by click, but you may not have time for that. At a minimum, I\u2019d suggest spelling out the recovery type, the data set to be recovered, dependencies to be aware of (e.g. Active Directory) and any post-restore steps that need to be taken.<\/p>\n Check out these article for even more DR insight:<\/p>\n Choosing the right disaster recovery solution, part 1: Defining the disasters<\/a><\/p>\n Choosing the right disaster recovery solution, part 2: Finding your feature set<\/a><\/p>\nWhy can\u2019t I just use a sync tool?<\/h3>\n
What kind of backup should I be using?<\/h3>\n
What needs to be backed up?<\/h3>\n
Which backup method will you use?<\/h3>\n
What are you protecting against?<\/h3>\n
What kind of recovery objectives should you set?<\/h3>\n
How do you build a small business disaster recovery plan?<\/h3>\n