DPM 1801 not backing up but reports all OK

[ADMaster]

My DPM server is reporting most protection groups as OK, but they all have a last backup of 2/21

I did the upgrade on 2/22.

 

I just looked at the jobs list and a data sync was completed every day including just a half hour ago. However the newest restore point is two weeks old.

I did a manual sync for a database on 3/5 and have that recovery point.

 

Looking at the job history I have successful sync, consistency, and replica creation for various job types. VMs, Sql and User files are the main types.

 

Anyone else updated to 1801 have this issue, or know where to look.

 

I've just rebooted the server this morning too so will see if that helps.

 

Thanks,

[ADMaster]

I was just able to right click and create a manual recovery point so confusing.

[ADMaster]

Anyone?

I thought I had a snapshot from before the upgrade, but do have January's monthly offsite I can go to.

How will that effect the data disk with February restore points or is that why dpmsync does?

 

Thanks,

[ADMaster]

I guess this will just be a solo thread.

 

I uninstalled dpm and sql then reinstalled. I think something was corrupt with the sql reporting services.

I could not restore the DB backup as long as it existed on the server. After the reinstalled I dropped the fresh DB and restored the backup successfully. Then ran dpmsync.

 

I've been monitoring it for a few days now and it seams to be working.

 

I just have two VM's not backing up consistently, but they have been issues for a while.

[Bruce123]

We've having a very similar problem with DPM 2012.

 

The Protection Groups show as OK and there is a green tick next to the Group and all it's members , but when you select an individual protected source (e.g. D:\ or E:\), it shows Lastest Recovery point of around 2 weeks ago.

 

Essentially, DPM stopped backing up these volumes without even reporting there was a problem (!) never mind giving any reason. Microsoft, this is really bad™.

 

I've seen the same issue many years ago when supporting DPM2010, but hoped the MS team responsible for developing DPM would have resolved it by now, maybe expecting too much...

 

Yesterday, I installed the latest Update Rollup 14 and rebooted the server, and when I check again this morning the protection groups were exactly the same (as in reporting OK but with a latest recover point over two weeks old).

 

When this happened in DPM2010, I did some research and found some a real horror story of where a company had depended on DPM 2010 to backup critical MS SQL DBs, and DPM was reporting that everything was fine. Until it came to needing to do a restore, when they found that backups hadn't been working for weeks (corrupt replica), but guess what, DPM hadn't noticed. I think it was due to problems like this, that they introduced the option of a running scheduled full consistency check into the Protection group options. In theory performing a regular full consistency check should pickup on problems with the backups/replicas, but they can be very slow and might not fit well with the backup window.

 

So to answer the question, can you depend on DPM for your backups when you REALLY need it? The answer is No.

 

There are loads of other issues with the way DPM has been designed (which make it unsuitable for Disaster Recovery), which I won't go into here....

 

Thanks,

 

Bruce.

Edited December 7, 2018 by Bruce123

[Bruce123]

We've having a very similar problem with DPM 2012.

 

The Protection Groups show as OK and there is a green tick [ATTACH=CONFIG]51380[/ATTACH] next to the Group and all it's members , but when you select an individual protected source (e.g. D:\ or E:\), it shows Lastest Recovery point of around 2 weeks ago.

 

Essentially, DPM stopped backing up these volumes without even reporting there was a problem (!) never mind giving any reason. Microsoft, this is really bad™.

 

I've seen the same issue many years ago when supporting DPM2010, but hoped the MS team responsible for developing DPM would have resolved it by now, maybe expecting too much...

 

Yesterday, I installed the latest Update Rollup 14 and rebooted the server, and when I check again this morning the protection groups were exactly the same (as in reporting OK but with a latest recover point over two weeks old).

 

When this happened in DPM2010, I did some research and found some a real horror story of where a company had depended on DPM 2010 to backup critical MS SQL DBs, and DPM was reporting that everything was fine. Until it came to needing to do a restore, when they found that backups hadn't been working for weeks (corrupt replica), but guess what, DPM hadn't noticed. I think it was due to problems like this, that they introduced the option of a running scheduled full consistency check into the Protection group options. In theory performing a regular full consistency check should pickup on problems with the backups/replicas, but they can be very slow and might not fit well with the backup window.

 

So to answer the question, can you depend on DPM for your backups when you REALLY need it? The answer is No.

 

There are loads of other issues with the way DPM has been designed (which make it unsuitable for Disaster Recovery), which I won't go into here....

 

Thanks,

 

Bruce.

 

As per ADMaster, running a consistency check and manually creating a recovery point for each protected source resolved the issue (effectively triggered the scheduled backups back into action).

 

But I guess there's no hope that upgrading to DPM 2016 will resolve the the issue as the OP reported the same issue in 2016.

 

So same issue present in 2010 (assume also present in 2007), 2012, 2016 1801 (RTM 2018) and not identified/resolved. Come on Microsoft 8 years to acknowledge and fix a serious bug! Stopping introducing new features and focus on fixing the issues.

 

Thanks,

 

Bruce.