“Backups, Disaster Recovery and Business Continuity; the words are bandied about with regularity but, as many business owners know, the definition of the terms can vary from publication to publication”
It is true that many people tend to use these phrases in conjunction to an event, typically used in a setting where everyone asks “What happened?” In actuality the definitions of these terms don’t vary, but the parameters, scope, and process of how these words are defined for the individual customer or client changes. So when we say “Recovery” or “Continuity” we have to drill down further to specify for whom this is referring to. As much as these terms may get tossed around, they do have specific definitions.
“Backup is the act of copying files and/or programs to a location or device that is physically separate from the original files or programs”
Times have indeed changed, as this definition of a “Backup” needs to be refined. Mentioning files and/or programs is redundant. As programs are basically just combinations of files that are packaged together and reliant upon each other. Being physically separate may not be necessary for an actual backup to occur. Typically it is the sound decision to prevent a single point of failure. But in a scenario where the application and files needed “float”, making a backup could conceivably exist in the same physical area.
“The main concept to remember when considering backup is that backup solutions are about data – not systems”
This is essentially true, though I have a problem with the term “backup solutions”. A raw backup of any files would just be an exact copy of that file. But consider the fact that something this definition overlooks is the process and procedures involved in restoring from a backup. Some applications require a specific start up sequence or a process and procedure involved in order for the data or application to work. Data needs to be defined in this manner when you consider the backup. Without the proper systems, applications, operating systems, hardware, or even situational environments: data will only be valuable in the environment it is created and used. Will the backup compress data in such a way that file parameters are changed? Will the memory allocation specifications be altered? Would the data be recoverable to a point that it can be reusable?
What this post neglects to point out, however, is that in every backup solution, there is a recovery solution that has to tie into the process. Without that piece of the puzzle, backed up data that can’t be legibly visible would just take up space. Any deviation from the original source of where the data originated could be a point of contention of stability and liability. A solution (if it is financially feasible) would be to have an exact duplicate of the originating system on hand. I know of various high finance high stress corporations that swap out systems on the fly that are matched pairs. Downtime for them would be literally millions a second.
“How long can you afford to be down?” or “How much data can you afford to lose?”
I know the answers to these questions right away when I hear people ask clients. In short the answers would be “I cannot afford to be down”. and “None”. I think the right way of asking these questions would be “What is an acceptable time frame for recovery? At what time frame can we work on recovering your core network and then your server/data systems? Do you have any leased items and anything that requires remote access or third party involvement?” Also “What amount of data can rely on to stabilize your company? What are the essential roles of each device?”
One last note that I noticed in the article. Concerning that “Disaster Recovery is a subset of Business continuity”. Which I realize is pulled from Wikipedia. I actually disagree. Disaster Recovery and Business continuity do go hand in hand, but they can conceivably work independent of each other. Disaster recovery isn’t just about the post-disaster event. There are many aspects that are involved in recovery that happen before and after system restoration. Just as Business continuity may or may not be affected by a disaster (though typically it is, it’s not a constant actuality). Especially with larger and larger networks and advancements in global computing.
This article is provided by Electro-Mechanical Recertifiers, LLC. This article was written by Senior Network Engineer and IT Consultant Jonathon Wong.
Recent Comments