I recently came across an article called "Are application-specific backup tools worth it?" by Simon Sharwood. The article compares enterprise backup vendor approach to point application specific solutions, using SharePoint as an example. I think, in this article Simon brings up one of the most important issues that we are solving with Quest Recovery Manager for SharePoint: how to connect cross-application enterprise backup efficiency with the need for granular SharePoint-specific recovery solution. I could not find a way to submit a comment to the article at SearchStorage site, so I'll just post my thoughts here.

Backup and recovery ultimately share the same goal, but it is important to understand: each task has quite different requirements. It becomes more visible in large organizations but seems to apply everywhere. Here's what I mean:

• Backup is a periodic routine driven by administrator; typically, it is scheduled and performed off hours; major concerns are storage requirements and costs, so appropriate processes and technologies are in place are involved (e.g., tape libraries, tiered storage, etc.)
• Restore is a one-off activity, initiated or driven by the end user; it occurs as-it-happens, more often than not - during production hours; major concerns are time to recover and accuracy of the restored data.

Traditional backup vendors that are offering cross-application backup products primarily focus on the BACKUP requirements. These backup platforms often have built-in backup and storage management capabilities, tape libraries support, etc. But when it comes to application specific granular recovery task, sometimes these products (and backup operators who own them) are not as efficient as you'd like them to be. What if a SharePoint site is deleted? Document library? An administrator who owns such backup tool in a company might be responsible for backing up not only SharePoint farms, but Active Directory, Exchange Servers, SAP databases, and much more, as well as managing tape libraries and other storage media. This person might not have enough focus on SharePoint to even know what you are talking about. They know how to bring back your server, but a doc lib is often too low level.

The point vendors typically create SharePoint specific backup infrastructure with the target application in mind. Knowing different recovery scenarios exist in SharePoint, they try to address each with a specific backup type, which allows for various levels of protection. Depending on what backups you are creating with such tools, recovery is also available at different levels (item, site, or entire platform), and quite often you end up creating several different backups of your data for different recovery scenarios. With such tools in hands of a SharePoint administrator you are probably better prepared to different recovery situations, but is it really efficient to maintain separate backup infrastructures for different applications?

We here at Quest tried to bridge this gap and offer a solution that provides for SharePoint focused recovery on top of existing backup infrastructure. After all, if the backup and restore requirements are so different, why not separate roles here? Let your backup operators do what they are good at, and with the right tools that meet the backup requirements most efficiently. SharePoint operations team does not have to do the duplicate job and repeat what someone else is already doing. But when it comes to a specific recovery task for SharePoint data, you as SharePoint administrator can be much more efficient if you have a tool that allows you to search through these backups, locate the data you need and restore it. That's exactly what Quest Recovery Manager for SharePoint enables you to do. Net results? Efficient backups, quick and efficient recovery due to role separation and integration between the backup and recovery solutions.

Ilia