Using InstaMount to Speed Up SharePoint Recovery (Part 2/3)

Post Date: 07/26/2011
feature image

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 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: image 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 (Import-SPWeb cmdlet) to import the library to a temporary team site on the same farm. 15 minutes assuming you are good with PowerShell.4. Identify the files that were overwritten and manually copy them into the correct document library. 5-10 minutes for a few files.5. Recreate any lost metadata as this is lost in step 4. About 5-10 minutes for a few files assuming you still have it.So the total recovery time is maybe 90 minutes with about half of that waiting for the database to restore. It’s a fairly manual but skilled process and in the end, you could still lose precious metadata.As we’ll see, I can perform this same restore using Recovery Manager in about 20 minutes withoutRestoring the SQL databaseUsing PowerShellLosing metadataLet’s see how. Step 1: Create an “Analyze SQL Backup” Job Before a virtual database restore can be done, you must first create a job to analyze your SQL backup. While Recovery Manager supports multiple backup formats, I’ll only be focusing on SQL database backup. The database backup could have been created many ways. It may be from a farm backup run directly from SharePoint (Central Administration, PowerShell or STSADM). It may be directly from SQL Server, or it may be a platform backup from directly within DocAve Backup and Restore. Here’s what you do from inside Recovery Manager. Go to Data Protection Menu –> Restore Controller –> Restore from SQL –> Analyze SQL Backup as shown here. image_thumb_1_1215A099.png

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. image_thumb_2_1215A099.png

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: image_thumb_3_1215A099.png

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 (\raw-sql1DocAveDevice): image_thumb_7_1215A099.png

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: image_thumb_11_1215A099.png

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: image_thumb_9_1215A099.png

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: image_thumb_12_1215A099.png
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. image_thumb_10_4002F351.png

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: image_thumb_14_4002F351.png

Here are the file properties for the database. The data and log file seems to have been stored in our temporary path (D:temp). image_thumb_15_4002F351.png

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 sparse files for Windows, they’re pretty cool. It’s a way of storing large files whose data consists of lots of either empty space (technically all zeros in binary) or files whose content originate from another file. You’ll also find .mapping files that map database page offsets into locations within the sparse files. (Note: Sparse files are also used with database snapshots in SQL Server in a similar way). image_thumb_16_4002F351.png

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: image_thumb_18_4002F351.png

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. image_thumb_04C5ADEB.png

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. image_thumb_23_100B9B5C.png

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: image_thumb_04C5ADEB.png

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. ​

Subscribe to our blog