Using InstaMount to Speed Up SharePoint Recovery (Part 3/3)
By Randy W.
Welcome to Part 3 of our series! In Part 1, I discuss the business value of our InstaMount virtual database technology. In Part 2, I introduce a common recovery scenario and walk through how to use AvePoint’s free Recovery Manager for SharePoint to quickly restore items within a document library.
In part 3, I will review the challenges with built-in recovery tools, provide performance benchmarks that measure the speed of InstaMount, discuss how InstaMount can be used within other DocAve products, and conclude with some guidance on when InstaMount works best for your recovery operations. Challenges with Built-in Recovery Features While I really like some of the improvements that Microsoft incorporated into SharePoint Server 2010 (see my Backing Up and Restoring chapter in the Real World SharePoint 2010 book for details), recovering site content still leaves a lot to be desired. For example, let’s take two scenarios that I cover in one of my Disaster Recovery presentations. 1. Item level recovery. If you read through Part 2 of this series, you saw how fast and easy it can be to restore one or more items using Recovery Manager for SharePoint. It’s a different story with built-in SharePoint recovery tools. And whether it’s one item or hundreds, the effort is pretty much the same. Here are the basic steps:Restore the content databaseUse unattached content database recovery to export the web site or libraryUse Import-SPWeb PowerShell cmdlet to import into your destinationThe challenge here isn’t just the amount of work to do this (even if you’re a PowerShell wiz), but the time it takes. And, depending on the size of your web site or library, it may not even work! In general, the recommended content limit for using import and export operations is about 1GB. Yes, you can go larger and I have, but performance gets increasingly worse and the operations become unstable. So, if you have a Document Center and in the Docs library you’ve got a million files that total 100GB, this form of recovery isn’t an option.
Another drawback is the extra space consumed. You need to have available space to store a temporary copy of the content database until your restore completes. 2. Site Collection recovery. Using built-in tools, site collection recovery is similar to item level recovery. Here are the steps:Restore the content databaseUse unattached content database recovery to backup the site collectionUse Import-SPSite to import into your destination web application.Site collection backups and restores are faster and more scalable than exports and imports, but the recommended limit is only around 15GB. I’ve got lots of customers whose site collections are much larger than that. So, what are the steps to restore a 100GB document center using built-in tools?Restore the content database into a recovery farmMount the content database in the recovery farmManually copy the content overKeep in mind when you manually copy over content, you’ll lose precious metadata. My point is that this is not an option and using third-party tools is a necessity when you reach these sizes. What about Performance? Leading up to the release of v5.7, we did a lot of performance analysis around different recovery scenarios using different content database compositions and sizes. With tightening recovery time objectives (RTO), we understand these are key requirements, especially as your content databases grow. Here is one of the performance tests we did. Performance Test: Restoring a libraryWe start with one Document Center site collection. In the top-level web site, we create 5 libraries. We populate the libraries with files ranging from 10KB to 1MB in size with an average file size of 250KB as shown here:
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.
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.
Share this blog