RSS

Thoughts on ConfigMgr backup strategy…

06 Mar

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:

http://technet.microsoft.com/en-us/library/gg712697.aspx

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:

http://technet.microsoft.com/en-us/library/gg712697.aspx#BKMK_DPMBackup

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:

http://stevethompsonmvp.wordpress.com/2013/06/07/sql-server-backup-recommendations-for-configuration-manager/

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…

Advertisements
 

4 responses to “Thoughts on ConfigMgr backup strategy…

  1. configmgrmvp

    06/03/2014 at 15:29

    Hi Marc, Thank you for linking to my blog. The only downside of using both the SQL Maintenance task and the Configmgr backup task, you’ll need more storage. With the SQL maintenance task, you can use database compression and as you point out ConfigMgr 2012 Sp1 and later no longer need the files created by the CM backup task. In fact, MS told us that those files are thrown away during restore 😉

     
    • mwesterink

      06/03/2014 at 22:30

      Hi Steve,

      Thank you for your feedback.
      It’s true that my approach requires more storage…

      If I understand your comments correctly, then from SP1 the backup maintenance task would be obsolete, the Rebuild Indexes task too.
      After all, SQL is required for ConfigMgr so why not use the maintenance plan…

      I think MS should document the throwing away part of the restore process 😉

       

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

MDTGuy.WordPress.com

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This WordPress.com 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

%d bloggers like this: