Sometimes you have to cut through all the hundreds of things you do for clients and get to the absolute basics. The most time consuming "basic thing" we do is to maintain computers and networks. That maintenance is probably the second most important thing we do. The most important thing we do is to prepare for something that almost never happens: Building and testing backups.
Clients rarely understand the importance of backups. If they did, the number of new clients with working backups would be much higher. Until a client has experienced a truly catostrophic data loss, they just don't put much emphasis on backups. And of course backups are completely useless without a good restore from backup!
As with most modern technology, backups have what I call the Paradox of Simplicity: It's easy ENOUGH that anyone can create a bad backup system that appears to be good enough. When a client (or an incompetent technician) creates a half-baked, "good enough" network, it will be a slow network that has more equipment failures than a professional network. Maybe that's good enough.
But a "good enough" backup is not good enough. If you can't recover data, or can't recover all data, the client is likely to go out of business! If you need scary stats on this, read the excellent report by HP and SCORE entitled "Impact on U.S. Small Business of Natural & Man-Made Disasters." This is a great report to hand out to clients as it does not push any solutions, but merely raises awareness of the potential consequences of data loss.
We have always made backups an extremely important part of the service we offer. In earlier discussions of priorities within the service department, you saw that failed backups are the task guaranteed to raise the assigned priority of a service request. And testing backups are part of every monthly maintenance for every client.
Given the importance of backups, we're going to do a little 4-part series on backups. This is the first article - Defining Your Client Backup. The other articles will be:
- Backups Part 2 - Backup Philosophies and Client Communication
- Backups Part 3 - Backup Monitoring Testing and Management
- Backups Part 4 - Changing Technologies
- - - - -
(Note the earlier SOP on Documenting Backups.)
There was a time when a backup was very simple to define: Backup everything every day. That might have been a challenge when you were using 8 GB tapes and wondering whether you were going to have to go to a larger-capacity tape drive.
Now we have gargantuan databases and monster hard drives that seem to just show up. It's not unusual for clients to have multiple terrabyte drives. And we all know that data expands to fill the space available. Whether it's log files, streaming media files, on-the-fly backups, vacation photos, or serious business data. It gets bigger and more diverse every year.
Inventory the Data
As you can see, you need to define the data your client has. In a perfect world, nothing important is kept on the desktop. But you need to find out for sure. After that you can turn to the server(s) and catalog all the resources that need to be backed up. Databases, directories, system state, etc. List out everything that's on the server and the format it's in (SQL, EDB, flat file, etc.).
Consolidate the Data
I know this is easier said than done. Basically, you need to get that data off the desktops, stray USB drives, etc. and onto the server where you can back it all up as part of the backup job.
Define the Backup Job(s)
Defining a backup means exactly that: What will you backup? When will you back it up? Onto what medium will you back it up? For example, let's look at three fictional clients.
1.
Client: Able Baker Charlie
Backup: Full backup of server "Obiwan"
When: Every workday (M-F) at 11:00 PM
Medium: DAT 160 tape with Symantec Backup Exec Software
2.
Client: Cousin Larry's
Backup One: "Public" data on server SBS2008
When: Mon-Wed-Fri at 11:00 PM
Medium: Disc-to-Disc to SAN - then SAN to cloud
Backup Two: System and user data on server SBS2008
When: Tue-Thu at 11:00 PM
Medium: Disc-to-Disc to SAN - then SAN to cloud
3.
Client: KPEnterprises
Backup One: Full backup of server "Tommy"
When: Every workday (M-F) at 9:00 PM
Medium: Disc-to-Disc to Elvis
Backup Two: Full image backup of server "Tommy"
When: Every workday (M-F) at 10:00 PM
Medium: Acronis
Backup Three: Full backup of server "Elvis"
When: Every workday (M-F) at 10:00 PM
Medium: DAT 160 tape with Symantec Backup Exec Software
Backup Four: Full image backup of server "Elvis"
When: Every workday (M-F) at 11:30 PM
Medium: Acronis
Why don't we simply backup everything every night for every client? Well, some clients don't need it. But more likely than that, you may be working with two limited resources: Time and capacity. Depending on the hardware and network involved, you may not be able to move all of the data to the backup device in a reasonable amount of time. Or the medium (whether disc or tape) may not be large enough to hold all of the data.
In either case, you have to decide what to backup and when. The system state probably doesn't change much. Line of business databases, Exchange, and core data files change every day. You have to calculate what goes where, how long each job will take, and how much will fit on a given medium.
Why Document This Way?
There are many reasons to document what you do. They pretty much all apply here. You need to be able to assure the client that everything is being backed up, and that it's on a schedule consistent with their restore requirements in case of a disaster. You need to be able to send various technicians to the job site and know that they will be able to figure it out when they need to restore a file. And if you get hit by a bus, this stuff needs to be written down so it can be carried out while you're recovering in the hospital.
One of my rules for life is Slow Down, Get More Done. Restoring a server from backup is a perfect example of that. Think about how you will restore a server. The first medium you'll need is the O.S. and system state. Ideally, that will have everything you need to boot onto that server and finish the restore. So what's the next medium you need? And the next? If you have separate media for the system state and data, which is the most recent of each?
Think slowly. If you get this wrong, you'll double the time for your restore, or worse.
How exactly will you restore this server?
Once you can precisely define the restore process, then you'll be able to verify that you have a good backup process, and that it's properly documented. Now take yourself out of the picture. Can a qualified technician look at your process and properly restore this server? If the answer is "no" or "I don't know" then you need to keep working on it.
Implementation Notes
As I mentioned in the earlier SOP on Documenting Backups, your backup documentation is primarily a narrative. It's easy, but technically precise. If you get it wrong, you'll end up over-writing a backup you need. If that happens, the restore will be troublesome.
Precision matters - a lot.
The main thing you need to do is to educate your team about your company's approach to backups (and restores), and then make sure everyone who might be involved in a restore has an opportunity to put their hands on a backup. They need to be comfortable with this so they can be successful after a disaster.
You may have only one or two people on your team that would ever be involved in an emergency restore. But every technician should be involved with monthly tests and setting up backup jobs. That ensures a high level of knowledge across your team. This is literally insurance for you. If one of your technicians ever needs to make a decision about a medium to use, you want to do everything you can to make sure they make good decisions.
This kind of policy requires that everyone on the team
1) Be aware of the process
2) Practice the process
3) Correct one another's errors
4) Support one another with reminders
Your Comments Welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at http://www.smallbizthoughts.com/events/SOPFriday.html.
- - - - -
Next week's topic: Backups 2: Backup Philosophies and Client Communication
:-)
Clients rarely understand the importance of backups. If they did, the number of new clients with working backups would be much higher. Until a client has experienced a truly catostrophic data loss, they just don't put much emphasis on backups. And of course backups are completely useless without a good restore from backup!
As with most modern technology, backups have what I call the Paradox of Simplicity: It's easy ENOUGH that anyone can create a bad backup system that appears to be good enough. When a client (or an incompetent technician) creates a half-baked, "good enough" network, it will be a slow network that has more equipment failures than a professional network. Maybe that's good enough.
But a "good enough" backup is not good enough. If you can't recover data, or can't recover all data, the client is likely to go out of business! If you need scary stats on this, read the excellent report by HP and SCORE entitled "Impact on U.S. Small Business of Natural & Man-Made Disasters." This is a great report to hand out to clients as it does not push any solutions, but merely raises awareness of the potential consequences of data loss.
We have always made backups an extremely important part of the service we offer. In earlier discussions of priorities within the service department, you saw that failed backups are the task guaranteed to raise the assigned priority of a service request. And testing backups are part of every monthly maintenance for every client.
Given the importance of backups, we're going to do a little 4-part series on backups. This is the first article - Defining Your Client Backup. The other articles will be:
- Backups Part 2 - Backup Philosophies and Client Communication
- Backups Part 3 - Backup Monitoring Testing and Management
- Backups Part 4 - Changing Technologies
- - - - -
Defining Your Client Backup
(Note the earlier SOP on Documenting Backups.)
There was a time when a backup was very simple to define: Backup everything every day. That might have been a challenge when you were using 8 GB tapes and wondering whether you were going to have to go to a larger-capacity tape drive.
Now we have gargantuan databases and monster hard drives that seem to just show up. It's not unusual for clients to have multiple terrabyte drives. And we all know that data expands to fill the space available. Whether it's log files, streaming media files, on-the-fly backups, vacation photos, or serious business data. It gets bigger and more diverse every year.
Inventory the Data
As you can see, you need to define the data your client has. In a perfect world, nothing important is kept on the desktop. But you need to find out for sure. After that you can turn to the server(s) and catalog all the resources that need to be backed up. Databases, directories, system state, etc. List out everything that's on the server and the format it's in (SQL, EDB, flat file, etc.).
Consolidate the Data
I know this is easier said than done. Basically, you need to get that data off the desktops, stray USB drives, etc. and onto the server where you can back it all up as part of the backup job.
Define the Backup Job(s)
Defining a backup means exactly that: What will you backup? When will you back it up? Onto what medium will you back it up? For example, let's look at three fictional clients.
1.Client: Able Baker Charlie
Backup: Full backup of server "Obiwan"
When: Every workday (M-F) at 11:00 PM
Medium: DAT 160 tape with Symantec Backup Exec Software
2.
Client: Cousin Larry's
Backup One: "Public" data on server SBS2008
When: Mon-Wed-Fri at 11:00 PM
Medium: Disc-to-Disc to SAN - then SAN to cloud
Backup Two: System and user data on server SBS2008
When: Tue-Thu at 11:00 PM
Medium: Disc-to-Disc to SAN - then SAN to cloud
3.
Client: KPEnterprises
Backup One: Full backup of server "Tommy"
When: Every workday (M-F) at 9:00 PM
Medium: Disc-to-Disc to Elvis
Backup Two: Full image backup of server "Tommy"
When: Every workday (M-F) at 10:00 PM
Medium: Acronis
Backup Three: Full backup of server "Elvis"
When: Every workday (M-F) at 10:00 PM
Medium: DAT 160 tape with Symantec Backup Exec Software
Backup Four: Full image backup of server "Elvis"
When: Every workday (M-F) at 11:30 PM
Medium: Acronis
Why don't we simply backup everything every night for every client? Well, some clients don't need it. But more likely than that, you may be working with two limited resources: Time and capacity. Depending on the hardware and network involved, you may not be able to move all of the data to the backup device in a reasonable amount of time. Or the medium (whether disc or tape) may not be large enough to hold all of the data.
In either case, you have to decide what to backup and when. The system state probably doesn't change much. Line of business databases, Exchange, and core data files change every day. You have to calculate what goes where, how long each job will take, and how much will fit on a given medium.
Why Document This Way?
There are many reasons to document what you do. They pretty much all apply here. You need to be able to assure the client that everything is being backed up, and that it's on a schedule consistent with their restore requirements in case of a disaster. You need to be able to send various technicians to the job site and know that they will be able to figure it out when they need to restore a file. And if you get hit by a bus, this stuff needs to be written down so it can be carried out while you're recovering in the hospital.
One of my rules for life is Slow Down, Get More Done. Restoring a server from backup is a perfect example of that. Think about how you will restore a server. The first medium you'll need is the O.S. and system state. Ideally, that will have everything you need to boot onto that server and finish the restore. So what's the next medium you need? And the next? If you have separate media for the system state and data, which is the most recent of each?
Think slowly. If you get this wrong, you'll double the time for your restore, or worse.
How exactly will you restore this server?
Once you can precisely define the restore process, then you'll be able to verify that you have a good backup process, and that it's properly documented. Now take yourself out of the picture. Can a qualified technician look at your process and properly restore this server? If the answer is "no" or "I don't know" then you need to keep working on it.
Implementation Notes
As I mentioned in the earlier SOP on Documenting Backups, your backup documentation is primarily a narrative. It's easy, but technically precise. If you get it wrong, you'll end up over-writing a backup you need. If that happens, the restore will be troublesome.
Precision matters - a lot.
The main thing you need to do is to educate your team about your company's approach to backups (and restores), and then make sure everyone who might be involved in a restore has an opportunity to put their hands on a backup. They need to be comfortable with this so they can be successful after a disaster.
You may have only one or two people on your team that would ever be involved in an emergency restore. But every technician should be involved with monthly tests and setting up backup jobs. That ensures a high level of knowledge across your team. This is literally insurance for you. If one of your technicians ever needs to make a decision about a medium to use, you want to do everything you can to make sure they make good decisions.
This kind of policy requires that everyone on the team
1) Be aware of the process
2) Practice the process
3) Correct one another's errors
4) Support one another with reminders
Your Comments Welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at http://www.smallbizthoughts.com/events/SOPFriday.html.
- - - - -
Next week's topic: Backups 2: Backup Philosophies and Client Communication
:-)
SMB Books, Audio Programs, and More
100% Small Business I.T. Focused
- Technical - Business - Marketing -
- Managed Services - Cloud Computing -
- Network Migrations - Sales -
All these resources and more.
SMB Books is THE resources for the small business IT consultant who wants to move up to the next level.
|
No comments:
Post a Comment
Feedback Welcome
Please note, however, that spam will be deleted, as will abusive posts.
Disagreements welcome!