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.

Have you checked for Titanic in your backup storage environment?

For IT people around the globe, holiday periods can be very challenging: how does the IT organization ensure IT continuity when key staff on leave for a shorter or longer period? Can the remaining staff test or even execute recovery of mission-critical servers?

Let me draw your attention to a local incident that happened this summer. Most of you can relate to the situation, at least the scary implications following server fall-outs.

A large public organization experiences – without evident warnings – a fatal server break-down. The server plays a key role for caretaking of older people. The server holds schemas for individuals’ home care, cleaning, medicine, dispatching of care takers etc. Evidently, the unavailability of the server means the Caretaking Unit is blindfolded, for instance, how do you administer medicine?

Server break-downs happen quite often and really: nothing to be surprised of. What strikes me is the classic explanation: “We are victims of force majeure: first, the server break downs and then we discover the backup has failed for a period of time.”

An “cruiseline” analogue: “We didn’t spot the iceberg before impact, however we experienced the lifesaving equipment didn’t work”. Failure of recovery is not an option. TESTING SERVER RECOVERY FROM BACKUP IS MANDATORY.

It’s not a matter of “IF” – rather “WHEN” servers break. End of story. So please, test, test, test you can recover complete servers from backup. Not just single files restores…

Don't Conceal - Reveal faulty server backups!

Regardless of industry - our customers tell us the same thing: only a few servers are tested anually for recovery assurance as part of a Disaster Recovery scenario. By no means can the TSM admin cover complete server recovery tests of all server backups secured in Tivoli Storage Manager (TSM).
Does this mean the other 98% of servers remain untested from a recovery viewpoint? Unfortunately, this is the case in many enterprises today. Lack of resources, tools, budget cuts.

In many case we even learn “competence centres” (silos) cause serious compliance risks: To test recovery of Environment X from the TSM backup requires Mr. Backup, Mr. AppOps and Mr. AppOwner. Hence, the recovery-assurance test - too tedious and cumbersome - isn’t happening. Possibly, the snowball has begun rolling.

Why the SMARTtsm tool ?

Because that’s what SMARTtsm is – a TOOL, not a manual process. The software automates full-server recovery tests. It auto-executes every day, week, month …. SMARTtsm auto-reports compliance. Just define the recovery frequency. SMARTtsm documents recoverability – AND actual Recovery Time (RTO)!

The built-in integrity wizards even help Mr. Backup check integrity of TDP backups. With no knowledge of the application running on the server to be recovery tested.

The new hero – the SMART TSM admin
Imagine a TSM admin schedule a full Exchange recovery test from TDP backup – every week! No intervention, just checking the recovery report. Set ‘n forget recovery testing of 100s of servers onto a dissimilar test platform.
We expect this is why ‘compliance-is-a-must” institutions like finance/banks and state/public sector are testing the SMART way. No reason to conceal when SMART can reveal faulty backups before the fatal IT event, where you are required to execute a full server recovery from TSM.

Welcome to the SMART team's Blog

Welcome..
… to the SMARTtsm team’s Blog. SMARTtsm is a unique software solution from a entrepreneur-driven company called asensus. The software company was founded back in 2003 around a single mission: improve recovery assurance for mission critical server backups.

Your pains go into our veins
Our software helps customers with IBM Tivoli Storage Manager (TSM) take the word ‘disaster’ out of Disaster/Recovery (DR). Unlike the traditional recovery approach, SMARTtsm is a software solution that automates full-server recovery testing.
Most customers find the mandatory, manual server recovery test rather demanding, both from cost and competence point of view. To make things worse, costs restricts recovery testing to a few Tier1 servers.
What about the other 100, 500 or 1000 servers in TSM? Don’t you want to know if they can recovery from backup ? – and in what recovery time objective (RTO) ?

SMARTtsm – the easy painkiller
Not only does SMARTtsm provide an automated recovery process – the recovery test documents IF mission-critical servers can be recovered from backups stored in TSM.
The traditional (bi)annual, tedious and resource demanding (that is manual, right?).
DR tests are now reduced to an automated test process which executes according to your Service Level Agreement (SLA); weekly, monthly, quarterly.
Many customers experience that the existing high cost of a manual server recovery tests can be replaced with massive amounts of automated recovery tests onto the low-cost, dissimilar SMARTtsm test platform.


X-ray server backups
The recently release Recovery Manager Console, RMC, lets you filter out recovery tests that fail recovery time objectives (RTOs) and those that simply – FAIL.
With SMARTtsm RMC you spot unrecoverable server backups in TSM as well as out-the-box compliance reporting helping you to get the ‘check OK’ from the IT compliance audit.

Go to the asensus website and see the software. Read our blog to learn more - about our unique software - and how your TSM peers address the issues of cost-efficient server recovery testing.