Archive for the ‘Data Protection Manager 2012’ Category

Backing up SharePoint 2010 and Remote Blob Storage with Data Protection Manager 2012

June 10, 2012

I’ve recently finished upgrading one my SMB’s from Data Protection Manager 2010 (DPM) to DPM 2012. The upgrade went well, added a bunch of useful functionality, and gave me a chance to modify their long-term storage solution to use external USB drives with Firestreamer virtual tape library. All going well so far!

One of the other components we installed was Stepwise for Remote Blob Storage, and this also meant slightly modifying the protection groups to make sure their backups were consistent. I’ve already blogged about backup with Stepwise previously, but the fundamental principle is to ensure you backup your database first, then your filesystem(s) second. This ensures all the files exist that your SharePoint database is referencing. However with incremental backups in DPM you can relax this somewhat – see below for more information.

I created a Protection Group that consisted of my SharePoint 2010 content databases and a separate Protection Group for my files and my network file shares. The protection groups were set up to complete a full express backup every night at 10pm, with a synch frequency of 15 minutes. DPM uses block-based backup technology when it performs full express backups, which can save an enormous amount of time and effort for the systems to back up data. It does this by only backing up blocks on the disk that have changed, rather than iterating through the filesystem searching for individually changed files.

Data Protection Groups for SharePoint 2010 and Remote Blob Storage

Protecting SharePoint 2010 and Stepwise Remote Blob Storage with DPM 2012

The issue with DPM is that you can’t force an order for a protection group to run in and guarantee that it will occur. For example, even though the sych frequency is every 15 minutes, there is no guarantee that my file-based protection group and my sql server protection group will happen at *exactly* the same time. For a “perfect” backup scenario it would be better to have the backups synchronised in their proper order, but here is where I think it doesn’t really matter too much.

Scenario 1 – you need to restore your content database

Simple enough – use DPM to restore the content database. Your Remote Blob Storage files haven’t changed, so you don’t need to restore them. IMPORTANT:  all Remote Blob Storage technologies are effectively Write-Once Read-Many (WORM) devices – they *never* overwrite existing files, always create new files. Even if you save over the same document in SharePoint that does not have version control turned on, Stepwise would create a completely new file as per the Remote Blob Storage interface requirements.

Scenario 2 – you need to restore your filesystem

This should only usually occur when there has been a hardware failure or corruption, but if so you would restore your filesystem from the DPM protection group to the same, or another, location.

Scenario 3 – you need to restore both SharePoint and your filesystem

Complete site failure? Of hopefully you are testing in your pre-production environment! Regardless, you would restore both protection groups to get all your data back again.

What about restoring only one file? Or one site?

Here is where things get fun. Because Stepwise has a copy of all files and versions of files, you typically don’t need to restore your filesystem at all. As long as the SharePoint content database still has a reference to your original file, you only need to worry about the SharePoint content database. It may be as simple as restoring your content database as a different database name and then using the SharePoint Central Admin site to get your data exported and re-imported to a location of your choosing. Because the backup of your database will have a reference to the Stepwise document id, it can be retrieved with the data as part of an export process.

For a more in-depth discussion of Remote Blob Storage, SharePoint 2010 and Stepwise, see my previous post series.


Diagnosing Backup Problems with Data Protection Manager 2012

May 28, 2012

I’ve used Data Protection Manager 2010 and 2012 for some of my clients who have a Microsoft-only environment. They generally use it to back up primary systems such as System State for servers, Exchange Server and SQL Server. This post is showing some of the issues I have had and resolutions for Data Protection Manager 2012 (though the same would generally apply for 2010 in most cases).

For any issues with recovery point creation you should look at the Monitoring section as this will give you the most information about failed backup jobs.

System State Fails for Windows Server 2008

My Windows Server 2003 server had no problems, but all Windows Server 2008 servers failed. The fix for this issue was to make sure Windows Server Backup is installed on the Windows Server 2008 servers. This is a feature that can be added via Manage Computer.

SQL Server Recovery Point Errors

One of my previous recovery point jobs had been running as a process on SQL Server for days, and it took me a while to track it down. I killed the process via SQL Managed Studio and restarted the recovery point job on Data Protection Manager.

Another issue I found was a rogue Transaction Log that was enormous (72GB) but was 99% empty. I manually backed up the data and transaction log until I was able to shrink the transaction log down to 200MB. Running the consistency check worked from then on.

Microsoft Exchange Recovery Point Errors

This occurred during a replacement for the self-signed certificate on the Exchange Edge subscription. I had to recreate the self-signed certificate and re-enroll the server, which caused issues during the recovery point creation process.