Monthly Archives: March 2014

Thoughts on ConfigMgr backup strategy…

One of the things many people discuss at the community is defining a strategy for backing up a ConfigMgr site hierarchy. I’ve had a few challenges on this as well with numerous customers and I’ve found a way that works well with most customers and for myself as well…

This post assumes a ConfigMgr 2012 SP1 or a ConfigMgr 2012 R2 hierarchy is used. Organizations who are still using ConfigMgr 2012 RTM (or even ConfigMgr 2007 SP2) should really consider upgrading or migrating to SP1 or R2…

As usual, TechNet provides a website which can be used as a starting point for the backup strategy:

Basically, 3 options are available for backup:

  • Using the backup maintenance task in ConfigMgr
  • Using a maintenance plan configured in SQL
  • Using Data Protection Manager (DPM)

Using DPM delivers some limitations and would add a level of complexity. Since I prefer to keep things simple, I wouldn’t recommend using DPM for this purpose. More information on backing up using DPM is available at the following website:

The other two options are the ones I recommend using, the fun part is I use both for various reasons.

From an architectural point of view, I recommend to place the Definitive Software Library (DSL) on a separate file server to store all content ConfigMgr is going to use, for example applications, images, updates, drivers. To add a level of abstraction and flexibility, I define a DFS Namespace for that share as well.

So, why not use that same DSL to store my backups?

The backup maintenance task copies the required files for a restore operation to the selected location. Since that location is a file server, it is pretty safe to assume that a daily backup mechanism is available. DPM is particularly useful for this purpose. Knowing that the location is backed up every day, I don’t need to use the AfterBackup.bat file for archiving purposes.

What about the maintenance plan?

Personally, I recommend using the backup maintenance task to restore the Site Database. However, the maintenance plan has some advanced options that will prove very beneficial to keep your Site Database healthy (and keeps the Console responsive too).

Steve Thompson wrote a nice article which I use as well:

Using a maintenance plan will cause SQL to fully commit all transactions to the database. Once committed, the transactions logs are deleted. This will reduce the time needed for the backup maintenance task because a significantly smaller file has to be copied. It makes perfect sense to schedule the maintenance before the backup maintenance task.

I recommend placing the .bak files at the same location where the site maintenance task puts its files (maybe in separate directories to maintain an overview). I recommend using the maintenance plan only to keep the database healthy, I don’t use the .bak file for a restore.

To summarize, here’s the list of recommendations:

  • Use the backup maintenance task as the primary backup solution for restoring a ConfigMgr Site
  • Use an SQL maintenance plan to maintain database health and support the backup maintenance task
  • Use DPM only to back up the files on the share

Feel free to comment on my thoughts.

Make sure the backup strategy is tested properly to make sure a restore can be made…

Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen