Cloud backup –avoid it goes disruptive in its negative sense of the word…

Cloud-related offerings receive great media attention along major vendors trying to establish or rebrand themselves in the cloud space. How big is the cost to the business if core systems and transactions stored in the cloud can’t be restored successfully, let alone in due time?
Be cautious: storing server backups in the cloud requires frequent recoverability tests to ensure compliance.

As John Morency states, cloud computing was a major topic during Gartner’s recovery and continuity briefings in 2010. But the cloud should be embraced carefully.

Backup services running inside the cloud have dominated cloud offerings, since many existing technologies mainly needed rebranding to enter the cloud. Major vendors of enterprise backup software claim they (or their partner eco-system) offer cloud-based backup services since their technology already enables such market initiative.

For instance, IBM’s Tivoli Storage Manager (TSM), optimized for backup over the WAN, and supports the cloud quite naturally: policy driven backup and archive processes, optimized for server and application backup powered by the Internet puts TSM in a favorable position. For many years, IT centers have used TSM to fuel its remote backup / hosted backup offerings (predominantly SMBs looking for an outsourced offering with a cloud flavor). In Northern Europe, Internet- backup driven businesses using the TSM engine have grown at double-digits.

Embracing the cloud can provide many benefits to SMBs looking for ways of leveraging a tight budget. Rather than investing in an in-house backup platform, the cloud offers enterprise backup at a financially attractive profile. However, regardless of running backup services internally (in-hose) or externally (cloud), it’s mandatory to validate and ensure mission-critical server backups are restorable – and in due time. Even smaller changes to the primary servers can make the backup un-recoverable. The classic file restores are insufficient to prove server recoverability. Full server restores from the backup, stored locally or in the cloud, must be tested frequently.

Software tools like SMARTtsm from asensus offers automated server recovery processes. Alternatively manual processes should be considered to mitigate the business risks associated with incomplete server recovery testing.

Validating the Recovery Gap

John Morency (Gartner analyst) has posted a blog highlighting the need for Recovery Gap Analysis. (link )
John’s blog is a valuable input to the Recovery Assurance debate. It highlights the need for discussing recovery gaps, recovery expectations and requirements with the business. Also, Roberta Witty of Gartner has dedicated blog time to issues on management attention within the Recovery Assurance space.
It’s my experience that crucial bottlenecks surface when IT management shift from gap planning to execution, i.e. actually testing if servers are recoverable and within expected RTO/RPO targets.
In most of our enterprise engagements, it comes down to “How can our overworked IT staff increase test productivity on a smaller budget?”:

A) Executing recoverability tests for more applications on a higher frequency (the annual test for a few systems proves insufficient in compliance-embraced organizations).

B) Expanding recovery assurance testing to not only a limited set of Tier 1 servers, but also Tier 2 and Tier 3.

C) Continuously Track & Document gap development over the course of the year.

Again, management attention and software automation for recovery assurance is key, increasing operational efficiency, eliminating manual recovery tests while mitigating business risks associated with insufficient testing.