Don’t you just love those really simple error codes that DPM can provide you.
Today I bumped into a little challenge that I thought I would like to share with the community. Doing a standard verification process of a DPM servers actual recovery points I noticed that there where something fishy going on with a protected data source.
For some reason the data source was not able to create a recovery point and just synchronized a few MB of data and then just…gave up. In the Windows Application log it stated that the protected data source has lost its disk from this error alert.
Since the data source was also archived to an Azure recovery services vault I felt that it would be better to recreate the local backup and after that trigger a new online job for that data source.
After deleting the protected data source, but retaining the online recovery points so the archiving wouldn’t get lost, I recreated the data source. Everything looked awesome and after fetching a new cup of coffee I went back to my screen an noticed that the DPM console has chrashed…no good.
Doing some investigation in the log I found a classic event….*drum whirl*…Event ID 999. For those of you that are not familiar with this event this is a generic event that could describe almost anything so it REALLY important to read the actual logged data within the event.
Still a bit of a challenge when the DPMDB are referring to objects that are not there….hmm…there is only one way of solving this. Make the DPMDB consistent with the protected workloads via the DPMSYNC command.
Running the DPMSYNC -SYNC from the DPM management shell started out great…until that command TOTALLY crashed…*sigh*… If the DPMSYNC fails the DPM console will not be able to access the DPMDB since the DPMDB will be in a “interesting” state.
So the current status was that the DPM servers database ended non-operational and the access to the DPM console was smoked…but…there is always a way! Since Disaster Recovery is always a nice feature to have I simple restored a earlier version of the DPMDB. If you don’t have a DPM-DPM-DR setup made I highly recommend you to get started with that!
After restoring the DPMDB the DPMSYNC -SYNC command worked fine however all storage became unavailable….will this never end!!!!????
Never fear…Hedblom is here! By using the switch -ReallocateReplica (yes it works on DPM 2016 also…) I got all the replicas back in place and finished the restore process by running the DPMSYNC -SYNC again…now I was back on track! I could access the DPM console and make small adjustments to the MBS storage pool. All data that was archived to Azure was still accessible (GREAT JOB MICROSOFT!!!) and after performing a Consistency Check for the protected workloads my client now was back with ZERO data loss.
I hope this could give some answers or support if anyone in the community ends up in the same situation I did.