Using InstaMount to Speed up SharePoint Recovery (Part 1/3)

​Welcome to the first of a three part series discussing InstaMount™, a database virtualization technology made available by AvePoint, the makers of DocAve. I have been playing with InstaMount for the newly-released DocAve v5.7, and I gotta tell you, I like what I see. The first reason is because this is absolutely free and part of the Recovery Manager for SharePoint which has always been free.

Here’s the other reason I’m excited:

Content databases in SharePoint can get very large especially since documents (what we often call BLOBs or Binary Large Objects) are stored inside the content database by default. And with the very latest guidance from Microsoft, there is now support for content databases scaling up to 4TB. (For more information on this, see Data Storage Changes for SharePoint 2010 at http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988). With the accelerating growth of SharePoint and with average file sizes increasing by incorporating video, hi-res images, etc., you can see why content databases are growing larger and larger.

One big issue with swelling databases is how to meet the ever-tightening Recovery Time Objectives (RTOs). As a refresher, an RTO is a time-based service level agreement (SLA) and dictates how long the business can wait for a restore operation. For example, you may have a SharePoint RTO of 60 minutes to restore deleted web sites.

Regardless of what SharePoint backup/recovery solution you use, you often begin a recovery job by restoring the content database. So, even if you want to recover a single document from a library, you usually start with a database restore from the relevant backup. (I am making the assumption that the file is not available in one of your recycle bins.) While restoring a database is easy to do, the problem is how long it takes. For example, a 1 TB database restore could easily take several hours.

Do you see the problem yet? If your RTO is set at 60 minutes, and it takes 3 hours to restore your content database, you can’t meet your SLA. Plus, once the database restore is done, it takes even more time to extract the recovered content and restore it to the correct location. This is one big reason why best practices have advocated a 200GB content database limit. Smaller content databases translate to quicker recoveries.

This is where InstaMount comes into the picture. With this, you do not need to restore the content database. Instead, you simply point to the database backup file and one of your SQL Servers can mount it like an actual database, complete with a database (MDF) and log (LDF) files. The restore that used to take hours now just takes a few minutes. Powerful stuff, I think.

Again, this is free and part of the very popular Recovery Manager for SharePoint. With Recovery Manager, you can restore directly from live SQL databases (for example, from a staging or test environment), directly from SQL backups (using InstaMount) or directly from site collection backups (e.g. from Backup-SPSite).

In the second post, I’ll walk you through step by step how easy it is to use InstaMount technology within DocAve. In the third article, I’ll share some guidance on when using this technology works best.