Intro

James Elliott here, your tactical CXO advisor with another in our practical series on strategic IT deployment for your organization. Do you do backups? The answer a lot of people will give is yes, we have backups. But the real question is whether you have backups that work for your business. Today we’re going to talk about a couple of simple points: practical business requirements, the types of backups, and most important, restoration.

Practical Business Requirements

When we talk about practical business requirements, we don’t want to back up just for the sake of backing up. We want meaningful backups that we can use for business. A couple of examples: we don’t want to lose time for our employees reentering data, so we want to make sure that we have backups that cover day to day work. We also want backups to cover potential loss where we have people at work but they can’t do their work because the system is down. We also want incremental backups, and that’s going to deal with things like financial closings and operational closings for your ERP system.

Another consideration is disaster recovery, so you’ll want to have your data in a location where you can recover should something like an earthquake happen here in California. Sit down and think about what realistically you would need a backup for.

Types of Backup

We’re going to talk specifically about each of the types that go with those topics.

Real-Time Backup

The first type of backup is real-time backup. Real-time backup is where the data is backed up as close to real time as possible on a drive or on a mirrored system, so that the data can typically be retrieved in something like 15 minutes. If you take the system down, you would transfer over and bring it back up.

Periodic Backup

The next type is periodic. That would be end of day and end of month, but it basically allows you to go back and select a period of time where you can restore the data and know exactly what data to put in subsequent to that.

Geographical Backup

The last type is what we call geographical backup, and that’s data located in a different geographic region, usually chosen for different kinds of risks. For earthquake risk in LA you would maybe back up in Dallas, and if you’re worried about tornadoes in Oklahoma, you may want to have your data located on the eastern seaboard.

Restore

Our most important point is the restoration of data, or what we call restore. It is very important that restoration is both planned for and tested. Restoring John Doe’s data because he lost a file last week is not what we consider a test of restoring data. We want to write out scripts for each type of data loss so that both the technical team and the employees on the floor know exactly how to resolve their work and get back to where they were prior to the event that occurred.

Simulating a Drive Failure

For this one, we have a script where we actually pull the plug on the system, for example, and then restore over to the other data. We are basically simulating a drive failure on the primary database. We’ll switch everything over to the new system, bring it back up, and then have users actually test their data. If we know the system went down at 1:10 in the afternoon, we’re going to test our last entries and make sure that we capture exactly where we left off.

Periodic Restore

Next we want to actually practice a periodic restore. At this point we’ll say we need to restore to last night’s data because we had a BitLocker virus. We’re going to restore the system and bring all the data back online. Then we’re going to instruct our employees to gather all the information and work that they did so that we can re-enter it, basically recreating the day or part of the day or whatever the important part is.

Geographical Restore

The last is usually because of some sort of natural disaster, but it could also be an internet outage or something like that. We want to test our geographical backup. The most common way geographic backups work these days is that we use a remote access solution where people that were in the building, say in LA, when an earthquake hit, are able to work on the system in Dallas, but they’ll be doing it from their home until we can restore business operations in LA. It’s important that when we do that simulation we make sure that we have already built a complete script.

We’re going to need to find a server, turn on remote access, make sure that our internet connections are all up, test all of that, make sure that we’re ready for operation, and then turn it over to the remote users. You’ll want to test that process beginning to end. Reach out to your IT department, ask a couple of these questions, and see what kind of answers you get back.