There are some products on the market that are just plain useful no matter the cost and sometimes they’re marketed in a way that they may not get the full attention of an IT organization, CTO or CIO.
One such product started life as an entirely different company with a very specific niche but has morphed into a different product line because where the product is now and who owns the code.
The product I’m referencing was “LiveState” by V2i now called “Symantec Backup Exec System Recovery” SBESR. Which has a long name and a connotation that it’s just a backup tool. Well, it’s not JUST for backups and here are several uses to consider.
NOTE: First off, I’ll mention that the product is not cheap, but it’s not out of the stratosphere. Cost or Expense justification can easily be calculated in time savings. Period. Last before I start in on putting an overview together on uses, I’ll say, I’m not affiliated in any way with Symantec nor do I get any commission on pushing or promoting their products. (Okay… disclaimer out of the way.)
Initially, the product was described as a system replication and dynamic environment backup tool. Meaning, it would encapsulate an entire “C:” drive or any drive for that matter into a single backup file to be stored anywhere. However, any drive that had the entire “Windows Server installation” could be backed up and used to for recovery in the event of a failure. This was and is it’s primary intent. As the product literature and documentation indicates, it takes a snap-shot or “live state” of a given environment and can even perform scheduled incremental file sets to be stitched back together if need be. As the product matured, it started supporting such things as storing the backup files any whwere, disk, tape, near line, off-line, over a LAN to storage, over a WAN to storage, to a DVD, to a session based CD, just about any type of storage that could handle the file size was supported.
Once Symantec purchased the entire company, V2i, I think that was the name, they incorporated it into their backup suite and added the name Backup Exec, morphed the name from LiveState to System Recovery. It is a great backup tool and can actually be used for that purpose quit successfully, but it also can be used for much more.
Uses 101
One: It can be installed and configured for it’s intended stated and documented purpose. To perform a complete backup of an entire Windows based environment be it desktop or server. It supports incremental backups, backups when changes occur and any scheduled configuration you can possibly imagine. Very much like a tape or disk based data backup and recovery. Recovery methods also vary in that they can be laid back down onto any dissimilar hardware that it was originally installed. This is the panacea of recovery options as you can put the server back onto a desktop, a laptop, another similarly configured server or a very different server class system.
Two: There in lies it’s power. While using it strictly as a “backup” strategy, it can also be configured to participate in a Disaster Recovery process, which is actually what backups are for. Disasters. Not just hurricanes and buildings exploding, but more common hardware disasters, localized departmental disasters etc… However, it can also be configured to support a much more complex higher reaching full blown disaster scenario as well. If configured, tested and implemented, it can support a wide variety of disaster plans and can support the documented system on many levels. Suffice it to say, that next to it’s primary intended purpose, this is the second most common installation type, I’d imagine.
Three: This is where the deviations begin. While it is a powerful backup tool, I believe it’s true power is in it’s functionality and flexibility. The single coolest functional aspect, besides plain working, is that it can take a complicated installed server environment and automatically recover it to a dissimilar piece of hardware. In fact, it can be installed and moved between similar hardware by different manufactures, which has lots of possibilities. Because of this flexibility and inherent nature of it’s functionality, it can be used for a variety of purposes both utilitarian and for complex deployments.
- One of it’s functions can be used to build a “golden master” for a variety of server solutions based upon type and need. There are a number of “ghosting” technologies and niche products geared for this, but they all take a different approach and in my experience have their various problems and short comings. However, with SBESR, you can take a snapshot or backup of the entire environment down to the drivers and registry, store it in a well defined and documented storage location and then use the stored “file” to build a new server in minutes. Considering how long it takes to work manually through a “check-list”, staging and/or prepping a server can take anywhere from 4 hours to several days depending on the complexity of the server software to configure. For example, a basic 10gb server partition can take just less than an hour start to finish. In some cases, it can take less than 30 minutes for the actual copy time. The other time is spent resetting the windows licensing, joining domains and other basic functions to get it fully ready to go.
- Server deployments to another location or data center. This process can be very lengthy depending on many factors, but he concept is simple. Fully stage a deployable environment, N+1 servers by starting with a golden master and configuring, data loading etc… for a given environment. This could be called staging. You could stage these servers on physical systems and/or virtual systems as they’re not dependent on scalability, just functionality and providing a test environment. Once testing has been signed off or final deployable code and configurations are prepared, you would then take a snap-shot of all of the server environments, store them on an external drive, preferably one thats portable. Now it’s prepared for shipping and/or for having the implementation technician install in a much shorter time frame than building systems on site or building systems in the development lab and shipping heavy servers to their final home.
- Development environments. Another possible use is to build up a suite of development and staging solutions that are stable and at a certain revision or version that is fully deployable. Test the upgrades process and/or new installation process. If it fails, simply revert back to the golden state and start over for tweaking and testing. Virtual server technology can also be used for this function, but if that’s not available and SBESR is, then it is a great choice for this job.
- One of the more recent uses would/could be for conversions to virtual server installations. There are a variety of tools and techniques to take a server from physical to virtual. However, SBESR now has built in tools that allow the recovery point to be applied back to either a physical server or converted to a variety of virtual formats.
Well, these are simply overview comments regarding a variety of uses. Each scenario has obvious ramifications in regards to time savings and quickly satisfy any ROI. I can say without reservation that if a technical team starts using these tools on a regular basis, they’ll abandon any old check-lists and manual server preparation processes on short order. In fact, I had one reluctant team of two prep-techs that resisted the use for several months. However, once they got indoctrinated, they are now champions of the product and resistant to upper management threatening to change or reconsider future purchases. A mutiny could ensue.
Bottom line, time savings are enormous for the various scenarios described above. This alone will help justify the high-cost barrier, especially in with regards to time sensitive deployments.