Force DPM 2025 RA to use FQDN or trust server certificate when trying to backup SQL Server
Hi, anybody know a way to force the Recovery Agent to use the FQDN instead of the NETBIOS name or configure it to trust the SQL Server certificate on a SQL Server cluster. The certificate has both the NETBIOS and FQDN certificate and the server requires encryption I am getting the following error WARNING SQL - Detailed Description "Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2227882." SQLQueryHelper.cpp(384) [0000004DD7EFF560] WARNING SQL - Detailed Description "SSL Provider: The target principal name is incorrect. The server has the latest OLE DB driver, Microsoft OLE DB Driver 19 for SQL Server as required by DPM2025
0 storage consumed on protected devices
Hello! My System Center 2022 DPM console shows that some protected devices take up 0kb of storage. I know its inaccurate because I can recover data from those devices. Any idea as to how to get the accurate storage consumed number to show? I tried running the "Update-DPMProductionServer" command via the DPM management shell and it tells me that it cant convert the value.
Computer / System Protection using large amount of storage
We have a domain controller (Windows Server 2019 Standard) which has the DPM agent installed and is backed up through DPM (2019). The domain controller has a 600GB disk and the used space is approx. 50GB as this server doesn't perform any other function. We have noticed that the Computer \ System Protection data source is using over 900GB of disk storage. Why would the System Protection be using so much storage space for backups?On-premise storage requirements with online backup
Before I added MARS online backup to my DPM 2022 server, I did not have storage limit issues on my on-premises backup. It seems like the online Azure backup has added to the storage requirements for the on-premises storage and I am exhausting my on-premises storage. Am I imagining this or is this the case? Thanks.
SQL server backups in MABS V4 will not create initial replica
Hi, We have various SQL servers and they backup fine in MABS V4 and have previous been upgraded from older SQL versions etc. One of our SQL servers has refused to backup the DB's in MABS since it was upgraded. We have recreated Protection Groups, set up a new MABS and still are unable to get it working again. In MABS the DB job gets the below error/s: The replica of SQL Server 2016 database SERVERNAME\DBNAME on SERVERNAME.DOMAINNAME. 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) Change journal not initialized or is the wrong size (ID 30118 Details: The volume change journal is not active (0x8007049B)) The DB's are detected and added to the protection group but the initial replica is never created and is only 18MB for each DB. DOMRACURR.errlog has some errors but they are quite generic, any pointers as to what might I might look at next? Can't roll back SQL or migrate to another server for quite some time so need to get this working as is. SQL server 2016 SP3 CU1 running on server 2016. Not sure if to look more at the SQL side of things, any pointers would be appreciated. Thanks
DPM 2022 UR2 Refresh Protected Server Restart Required?
In the DPM 2022 UR2 Refresh installation documentation, it is noted that you will need to restart the protected servers if you want to create or change protection groups on the updated server. Is this correct? Link to documentation: https://support.microsoft.com/en-au/topic/update-rollup-2-refresh-for-system-center-2022-data-protection-manager-cc6dbea6-b0ed-4390-8a7f-e59af8dd1ec0
Consistency Check taking an unusually long time
DPM 2019, using SQL 2019 on a 2019 Server. The server is doing a consistency check on a file server. The check is about 33 hrs in and has items scanned showing over 4 million items. There is no way the server has 1 million files and folders let alone 4 million. Anyone have any idea why that items scanned number would be so high. I've never had a consistency check so long before.SCDPM workgroup(untrusted domain) machine system state backup can't restore application.
I've encountered an issue with DPM Workgroup untrusted machine backup. After backing up the system state, I couldn't locate my application. While I can see that all the programs are installed, I'm unable to find the shortcut to run the program. I'm uncertain whether a workgroup untrusted machine can successfully back up the application/program.Systems Center DPM 2022 UR2 - Errors protecting Hyper-V Hosts
I recently installed UR2 for Systems Center DPM 2022. I have 2 Hyper-V hosts running Windows Server 2022. Whenever a Recovery Point is created (either Scheduled or Manually) it immediately fails, with Error ID 30135 stating the Replica is Inconsistent. I can run a manual Consistency Check and it completes successfully, but if I try running another Recovery Point right after the successful Consistency Check, it fails again with the same error. This is affecting our nightly offsite backups to Azure, because all of the Recovery Points fail and then it has to run an automatic Consistency Check which causes the Azure backup job to fail with Error ID 33344, the latest disk backup already exits. Which means every day I have had to go into the Sever to send the last backup to Azure. I have tried the following troubleshooting steps: Reinstalled the DPM Agent on the Hyper-V Hosts. Removed a protected Hyper-V Client and deleted the Replica Data on disk. Then reprotected the Data. Created a new Protection Group with one Hyper-V Host. None have solved the problem. Interestingly, I have the same DPM Server protecting File Servers and SQL Servers and those have been running without issue. Would love any suggestions to solve this.
