08/10/2011
We then back up the database using SQL Server Management Studio. To test recovery speeds, we restore each of the 5 different libraries using the unattached content database recovery steps just covered. For each library, we record the time to restore the content database, add the time to perform the export, and finally the time to do the import. The sum of these three values equals the recovery time (Restore + Export + Import). This is shown in the line chart below as the blue series. Next, we perform the same recovery using InstaMount. First, we went through the Analyze SQL backup process detailed in Part 2. We then add the time to perform the library site restore. (Analyze + Restore). This is shown in red.
In every test case except the small 500-item library, we can see that InstaMount reduces the amount of needed by at least 15%. As the size of the restore increases, the performance gap widens to almost 40%. Another benefit, but not related to performance is granularity. Recovery Manager for SharePoint give you real item-level granularity, allowing you to individually select each and every file. The built-in database recovery only allows you only work at a library level. Where else can InstaMount be used? Now that you have an idea how InstaMount can be used with the free Recovery Manager, let me also point out that you can also find it within the DocAve Backup and Restore product – AvePoint’s full-featured backup and recovery solution. Within platform backup, you have the option of generating virtual database mappings as shown here: 
These mappings, as mentioned briefly in Part 2, are used when creating a virtual database. There is a huge advantage of generating these as part of the backup, and you can probably guess what the advantage is: Yes, it significantly speeds up the recovery as we’ll soon learn. Here is how you specify to use a Virtual Database when using platform restore:
Let me show you the performance difference in another test we did.Performance Test: Restoring a web siteFor this test, we create 20 site collections within a single content database. Each site collection is exactly the same and consists of 7 team sites (the top-level web site is empty). To populate each team site, we use fixed 1 MB-sized files and store them in the Shared Documents library of each team site. Here are the counts we use and total database size when loading has completed.
We then back up the database using SQL Server Management Studio.To test recovery speeds, we only work within one of the site collections. We first restore each of the 7 different web sites using the three unattached content database recovery steps covered above. For each team site, we first restore the content database, add the time to perform the export, and finally the time to do the import. Each import is configured to overwrite the existing files using the –UpdateVersions overwrite switch on the Import-SPWeb cmdlet. The sum of these three values is the recovery time (Restore + Export + Import). This is shown in the next chart as the blue series. Using DocAve Backup and Restore, we first run a platform backup job and select the 220GB content database. During the backup, we generate the database mappings. For the restore, we also go through 7 different tests, one for each web site. The actual time for the restore job is shown here in red. Here are the results: 
As you can see, in all cases platform recovery within DocAve is much faster than out of the box. In particular, notice how much faster small web sites restore—the 25MB web site takes a little more than a minute, where as unattached content database recovery takes over 30 minutes. And as the web site grows, DocAve becomes increasingly faster compared to built-in database recovery. When to use InstaMount within DocAve As great as InstaMount is, I have to admit that it is not designed to the fastest solution for all recovery scenarios. This is true whether you are using the free Recovery Manager for SharePoint or the complete Backup and Restore product. The reason is because it takes time to generate the mapping of the database backup, and depending on how much content you expect to restore, it might be faster to restore without it. Let’s illustrate in our final performance test that I’ll share. Performance Test: Item Recovery in DocAve Backup and Restore In this test, we compare performance when doing item level recovery with and without InstaMount. Our goal is to determine in what scenarios is InstaMount is faster when performing item-level recovery within DocAve Backup and Restore. We start by creating a single site collection. Inside, we create four websites, each with two libraries. In each library, we upload 5,000 files and each file is 5 MB in size. Thus, the site collection in total has 40,000 files with a content database size of 220 GB.For the backup, we take a VDI-based platform backup of the database. For our restore tests, we are interested in the amount it takes to restore the following number of files with and without InstaMount:
Here are the results: 
The blue line is the amount of time (in minutes) it takes to restore using standard item-level recovery. The red line is the amount of time it takes to restore the number of items using InstaMount. The intersection of these two lines tells us where the restore time is about the same. As you can see, the more items you restore the slower InstaMount gets. In this case, the intersection occurs about 8,000 items or about 20% of the items in the database. Recovery Guidance When running other tests, we find this 20% to be a good indicator of the performance tipping point. Again, this is only relevant when comparing item-level restore operations within DocAve Backup and Restore. As covered earlier, InstaMount should outperform unattached content database recovery operations in most cases. ConclusionIn this series, I introduced the business and IT value of InstaMount virtual database technology to accelerate your restore operations. I have overviewed how InstaMount works and covered in depth how to use it. Lastly, I have provided guidance on how to achieve the best performance when using virtual databases for your restore operations. Here are some of the key takeaways of using InstaMount for your recovery requirements:Ease and flexibility doing item, library, website or site collection recovery.Increased performance, helping you to fit recovery jobs within your RTO window.Ability to mount database backup directly instead of creating a temporary database means less space usedGo ahead and download DocAve Version 5.7 and give it a test drive. You can use it in your environments for 30 days with no cost or obligation to buy. InstaMount is always free and available within Recovery Manager for SharePoint.