Welcome to Part 2 of InstaMount technology that is part of the free DocAve Recovery Manager for SharePoint. In the previous article, I discussed how this new feature can drastically cut recovery times when you need to restore from a content database backup. In this article, I’ll show you how to use it.
To use InstaMount, you must deploy the 5.7 release of DocAve which includes Recovery Manager for SharePoint. Again, as a reminder, using Recovery Manager within DocAve is 100% completely free. I won’t cover how to install DocAve since there is a great installation guide already published at https://www.avepoint.com/assets/pdf/sharepoint_user_guides/QuickStart_Installation.pdf.When using Recovery Manager to restore from a backup, there are three basic steps:1. Analyze the backup. This mounts the backup into a restorable format.2. Browse and select content to restore from the backup set.3. Choose a target destination for where the restore set will go.
We’ll cover each of these three steps in detail. Recovery ScenarioBefore I get into these specific recovery steps, let me introduce the recovery scenario that I will be demonstrating. In this case, we have one very large 140GB site collection that is stored in a content database. The site collection contains mostly team sites and is used for collaboration activities. It is the only site collection in this database. To backup, we are using SharePoint’s built in farm backup facility that is being scripted by PowerShell using the Backup-SPFarm cmdlet. A complete farm backup is running every night.
In one of the active team sites, a user accidentally uploaded a few files to the wrong library and replaced some important files. Since versioning was not enabled in this library these files are now gone. Has this happened to you? It’s a fairly common problem and the only solution is to restore from backup. By using InstaMount to mount the database backup, we can drastically cut the amount of time this recovery job will take. Here’s what the library looked like before the accidental upload occurred: 
Here’s what it looks like afterwards. Notice the loss of metadata and different file sizes:
What if we aren’t using Recovery Manager?
Just to give you an idea of the effort and time involved, let’s see how this recovery would work using out-of-the-box recovery tools. For this scenario, I would advise using the unattached content database recovery feature that is new to SharePoint 2010. For a built-in feature, this is a pretty nice tool. Here’s a summary of how this works and approximately how long it would take in this scenario:1. Restore the database from last night to a temporary location. Estimated time: around 45 minutes for a database of this size.2. From Central Administration, use unattached content database recovery to export the library where the files were overwritten. 15 minutes.3. Use PowerShell (
This takes you to an interface where you specify two primary items: what staging SQL Server you want to use and where will the index files be stored. 
From here, I have clicked on Staging SQL Server Info as we will configure that first. A Staging SQL Server is the server where you specify where backup files can be found and which SQL server will mount the backup into a virtual database. Here is how I have configured the Staging SQL Server for my scenario: 
Next, we need to specify where our index files go. These are used to index (or catalog) the backup, allowing us to easily browse and select the items to restore. If you use other DocAve products, you may already have this configured. To briefly explain, the index storage location points to a logical device, which is a collection of one or more physical devices. A physical device can be on-premises (e.g. file server, NAS) or cloud storage. For my physical device, I’m just referencing a UNC share on my SQL Server as you can see below (
Now that these preliminary items are done, I can complete the Analyze SQL Job. Returning to the previous screen, I make sure I select the Use Virtual Database checkbox – this is where InstaMount is used. Here is how I have configured it: 
Next, I click the Find SQL Backup Files button and select my backup. This shows all files that are in the location I specified. It looks like this: 
After I select the backup file, I am returned to the previous screen which I can specify the actual backup instance from the backup file. Here’s how it looks: 
I now run the job. This can either be done on a schedule, or you can do it immediately, which is what I want. As it’s running, I can monitor the status from the Job Monitor screen. For my 140GB database, it took about 20 minutes to generate mapping files and mount the virtual database (and this is on a fairly slow virtualized SQL server 🙂 ) Here’s how it looks just after completion. 
If you’re like me, you’re probably curious what just happened. Well, two things. First, using AvePoint’s mini-driver that plugs into SQL Server, the database has been mounted (complete with MDF and LDF) in SQL Server. But—and let me be clear here—this was not an actual database restore! Here is the temporary database from SQL Management Studio: 
Here are the file properties for the database. The data and log file seems to have been stored in our temporary path (D:temp). 
Upon closer inspection, here is the D:temp folder on our SQL Server. Yes, it appears that there is some type of MDF (data file) and LDF (log file), but you’ll notice they are actually 0 bytes in the Windows Explorer screen shot below. You’ll also notice two large .sparse files. If you have not read up on 
The second thing is that the job indexed (or cataloged) the contents within backup. Site collections, web sites, lists, libraries, folders, items, even item versions are indexed to give us a very flexible, very granular restore capability that’s incredibly simple to use. This index is stored within your physical devices that were specified.Now that the virtual database is mounted and indexed, the restore process is simple. Also, this analyze job only needs to be done once for the backup set. This is great if you expect to run multiple restore jobs from the same backup. As you’ll see in the next two steps, the actual restore from an indexed virtual database is blazingly fast! Step 2: Browse and select content to restore from the backup set Now that we have a virtual database that has been indexed, the actual restore begins. Here is how we access the Restore from SQL Backup menu: 
From the Restore screen, I select the Analyzed Job that just ran. Using the index, I can navigate the hierarchy of content in the content database. In this case, I have expanded down to the document library where the files were overwritten. The numbers in parentheses reflect the number of items in that list or library at the time of backup. In my case, I want to restore from the Shared Documents library, and there were 12 files in there at the time of the backup. 
I could just as easily selected the whole site collection, a web site hierarchy, or just a list/library if that’s what my restore requirement was. In this case, I will select individual items. Here are the files I need to restore. 
After clicking the OK button, I am returned to the main restore screen. Step 3: Choose a target destination for where the restore set will go The final step is to simply select where I want these files to be restored. You can restore them to any library within any farm that DocAve has agents running. In my case, I just need them to go back to the original location within Shared Documents, so I select that as shown here:
After clicking OK, I’m returned to the main screen where the restore job is summarized. The source is on the left and the destination is on the right:
Since I’m about to create another job, I can again choose to run the restore now or schedule it. The clock’s ticking and people are waiting for their files, so I’ll restore now. As with the Analyze SQL job, I am again taken to the job monitor. In my case, the actual restore took less than 2 minutes!Once it finished, I can go back to the document library and see what we have, and it is exactly the same as what we had prior to the accidental overwrite. The metadata, including timestamps has been saved. (Note: While it didn’t affect us in this scenario, if there had been any changes that were made since last night’s backup, these would have been lost. To address this risk, DocAve Backup and Restore can be used.) As you can see, using InstaMount within Recovery Manager for SharePoint is a painless and efficient way to solve many of your recovery headaches. In the final article, I’ll share some guidance on when InstaMount works best for your recovery situations.
