DPM / Azure Backup Server error

[dayzd]

I'm crossing my fingers that someone can help/advise, here, as I'm pulling my hair out with this one.

 

I've recently deployed Microsoft Azure Backup Server (DPM 2016 in disguise) and I'm struggling with a very persistent error. I have one volume that constantly failed to keep it's replica consistent. The message I keep seeing is this:

 

The replica of Volume D:\ on .local is inconsistent with the protected data source. All protection activities for data source will fail until the replica is synchronized with consistency check. You can recover data from existing recovery points, but new recovery points cannot be created until the replica is consistent. 

For SharePoint farm, recovery points will continue getting created with the databases that are consistent. To backup inconsistent databases, run a consistency check on the farm. (ID 3106)

DPM failed to clean up data of old incremental backups on the replica for Volume D:\ on .local. Synchronization will fail until the replica cleanup succeeds. (ID 30134 Details: Cannot create a file when that file already exists (0x800700B7))

This may happen if the replica volume is being accessed from outside of DPM. Please see the detailed error, resolve the issue with respect to the replica volume path, and retry the job. Otherwise, DPM will synchronize with the changes during the next scheduled synchronization job.

 

Now, having Googled this I've found very little, but I've done whatever I could: chkdsk the source volume, look for VSS errors, pruned old shadow copies (with 'pruneshadowcopiesDpm.ps1'), but nothing has worked. Every time I run the suggested synchronisation job, within seconds it fails again.

 

The only thing I've not done is remove the entire Protection Group and start over, since I've got other volumes in the same PG I don't want to lose the backups for...

 

Does anyone have any suggestions?

[Steve21]

Does that server run sophos at all? Seen it when it's getting upset with a file that keeps changing during it's usage before, had to exclude the backup directly using a reg key

 

Steve

[BKGarry]

I seems to remeber something similar with failed to this, I ended up going into the volume which there is a link to is in Program Files .... System Centre 2012...... DPM......Volumes etc (this was DPM 2012 r2)

 

Once I found the volume i delete the log files for failed files and it worked again, it may be something very similar just with the clean up logs.

 

this may be the case, but it is a long shot.

 

I also found the ending task on the explorer process in task manager and then telling it to run as administrator when starting it up again in task manager helps with the navigation to the volumes

[dayzd]

Does that server run sophos at all? Seen it when it's getting upset with a file that keeps changing during it's usage before, had to exclude the backup directly using a reg key

Yeah, I'd read that too. I looked a bit further in to it and read that the reg key trick doesn't work on 2012 R2 servers, and that better management of process exclusions will be coming in the next version of Sophos Enterprise Console (5.5.1).

Have you tried using the reg key on an 2012 R2 machine? I suppose I've got nothing to loose by trying it!

 

I seems to remeber something similar with failed to this, I ended up going into the volume which there is a link to is in Program Files .... System Centre 2012...... DPM......Volumes etc (this was DPM 2012 r2)

 

Once I found the volume i delete the log files for failed files and it worked again, it may be something very similar just with the clean up logs.

I'd found something like this before, too. There's a 'FailedFiles.dat' (or similar) that used to be accessible in the volume path you've described. Sadly for me, this implementation of DPM keeps a tight grip on those volumes, and I can't see their contents, even using your Explorer/Administrator trick. I did manage command line access one day last week as SYSTEM, but I couldn't find a FailedFiles log anywhere.

[dayzd]

To update, I never solved this problem. After pulling my hair out for days, I gave in, removed the disk from the Protection Group then re-added it (at great cost to my storage pool!) . It's been a bit more than a week now, and it seems to be running just fine.

 

I'm still playing whack-a-mole with this thing, though - I'm forever getting shadow copy volume size errors, failed files and online recovery point failures... To the point I'm now investigating Veeam, even though I'm already over budget this year!

 

Thanks for the assistance!