In such a scenario I’d agree that with a highly locked down configuration system and fully automated rebuild, they may very well have been better suited to not do operating system backups. I think this (when properly managed) would fall into what I say in the article that operating system backups can be skipped when “from an architectural standpoint it is unnecessary”.

When it comes to OS or application area backups, I mention a “15 minute rule” in my book – if after reinstalling the operating system it takes more than 15 minutes to customise the various changes and updates required to integrate it into the environment, then backing up the non-data regions would be a Really Good Idea. If any administrator in the team without any specific training on that host however could make the requisite changes (at say, 2am in the morning) without assistance from anyone else, then yes, you could successfully argue that the environment has been sufficiently architected.

It seems to me based on your example that you were lucky enough to encounter a site that was very well focused on achieving that level of setup.

Cheers,

Preston.

However, their case was an odd one.. Their production environment was mostly Solaris 9, and all servers were built off a JumpStart server and config pushed via cfengine (the infrastructure servers were backed up in total for DR purposes). We directed the backups of their production systems by group to a specific set of directories where the user data, work files and status files lived.

The main point they made however was not about the space, but the time spent back the data up and the time it would take to restore it. They posited that their time would be better spend doing a DR on the key infrastructure systems, and them building servers from those key systems then restoring their data from the tapes.

Their point being that the less OS data on the tapes, the less seek time and the faster they could restore their systems. At this point I thought this was splitting hairs, but also not worth the fight.. At the time this was LTO2, so this wasn’t totally unreasonable..

I only mention this because it was such a memorable exception to the rules. They had everything so tightly managed there, it was very impressive.. I’ve only had one client so organized that I’ve thought they could safely bypass OS backups without a problem with DR.

On the other hand, of the client of your client happened to suddenly require a test recovery, I suspect the proverbial dark matter would hit the fan at an alarming rate.

It used to be, 10 years ago for instance, that “spending money on backup” was something we were still teaching recalcitrant businesses to do. That challenge has shifted. Now it’s no longer a case of convincing businesses to spend money on backup, but to convince them to spend money on recovery.

For instance, around 2000-2003 I was aware of a company in Australia that kept a “cold DR site” based on regulatory requirements. It was however established for name only, because the machines on site were the ex production machines, and none of them either had the physical RAM or storage required to actually enable them to run the business. Yet, it fulfilled the legal requirements.

As I say in my book, it comes down to the distinction between having “backup software” installed, and having a “backup system” installed. One doesn’t create the other, no matter how much spendthrift organisations would like.

After all, I still remember spending 3 hours in a meeting only 4 years ago, which was called by a spendthrift customer to discuss “urgent” backup problems. Those problems, it turned out, was that after having purchased 50 SDLT-320 tapes a year before, they were facing the need to purchase another ten and wanted urgent recommendations to avoid that.

Back to your original point – unrealistic SLAs result in ignored SLAs. The best way this can be rectified is to either have the SLAs tested and found lacking, or have the SLAs renegotiated and set to something more realistic. At that point, the business may treat them more seriously…