We have the following problem with the scheduling of System State backups, which evidently began with DPM 2012 Service Pack 1 and/or SP1 with Update Rollup 1 (4.1.3333):

If a Protection Group is configured with both File data (such as the C: volume) and Application data (such as the System State), for some reason DPM runs the System State backups both at the File Recovery Points times and the Application Recovery Points times. In previous versions of DPM is the File data backups (C: volumes and any other volumes) ran only at the File Recovery Points times, and the System State backups ran only at the Application Recovery Point times.

Take for example the following Protection Group:

  File Sync Frequency:                   Just before a recovery point
  File Recovery Points:                   1:00 AM Everyday
  Protected File Data:                    C: volumes on servers
  Application Recovery Points:        1:30 AM Sunday (Express Full Backup)
  Protected App Data:                    System States on servers

In the above example, the C: drive backups run daily at 1:00 AM as expected. However, the System State backups also run daily at 1:00 AM instead of just once a week on Sundays at 1:30 AM. This results in daily instead of (or, in addition to) weekly System State backups (which can lead to needing large recovery point volumes for the System State backups). Even if the System State backups are scheduled to run at the same time as the file data backups (such as 1:00 AM), DPM still schedules the System State backups to run twice around 1:00 AM.

We have observed this problem on both newly installed DPM 2012 SP1 UR1 servers as well as servers that were upgraded from DPM 2010 to DPM 2012 and then DPM 2012 SP1 UR1 (4.1.3333).

So is this a new bug with DPM? Any comments would be greatly appreciated.

-Taylorbox

Hi,

Thanks for reporting this issue, I was able to reproduce the issue In DPM 2012 UR3 (V4.0.1920.0) and also DPM 2012 Sp1 (V4.0.3313) and will report it to the DPM product group.  In the meantime, you can create a custom job filter and look for jobs scheduled for that system state for the next seven days, and cancel the ones that are scheduled to run during the week.  You can also place System State backups in it's own protection group as a worka

Thanks Mike.

I am very surprised that this bug has existed for five months and apparently I am the first one to report it (at least in this forum)!? We noticed this bug only recently because we just upgraded from DPM 2012 UR2 to DPM 2012 SP1 UR1. I suppose this protection group configuration must not be too common!  :o)

Canceling the System State backups during the week is not an option because DPM also cancels the C: drive backups in addition to the System State backup for the server. DPM isn't smart enough to only cancel the System State backups for a server and leave the C: drive backups scheduled.

Placing the System State backups in their own protection group is a workaround on a small scale, but for backups of hundreds of servers via dozens of protection groups across several DPM servers, well...it's just not practical to try rearranging all of that.

So, any idea on when a fix will come out?

-Taylorbox

Hi,

We have not had any customers report this issue to date, so all I can do is report the regression and see if this is something they want to address in a rollup.

Mike,

Update Rollup 2 for System Center 2012 Service Pack 1, which was just released, does not specifically say that it fixes the DPM bug presented in this thread. Can you please confirm whether or not this bug is fixed in Update Rollup 2?

http://support.microsoft.com/kb/2802159

Thanks,

-Taylorbox

Hi,

UR2 does not include a fix to the above issue, in the meantime, place the system state backups in their own PG as a workaround.

If this a high priority problem for you, please open a support case to help drive getting it

Hello Mike Jacquet,

Hopefully Update Rollup 3 for DPM 2012 Service Pack 1 will be released soon. Do you know whether the bug discussed in this thread will be fixed in UR3?

If not, we may have to open a support case, although that would seem odd since, as you said, this bug is a regression in DPM functionality...

-Taylorbox

Hi,

Unfortunately we have not had any customers call in on this issue.  Without a customer calling support with a strong business impact, the issue will not be addressed.  If someone wants to open a case you should not be charged if it's confirmed to be a code defect.