Thank you for contacting us on Microsoft Q&A platform. Happy to help!
You can ignor the below mentioned error as your local backup failed due to which no new recovery point is not available to backup to cloud.
"DPM skipped cloud backup for SQL Server 2017 database <Servername>\MSDPMINSTANCE\model on <Servername> because the latest disk backup is already backed up to cloud. (ID 33344)"Also, it seems you are facing issue due to USN Journal error on SQL Server as you are getting below mentioned error on DPM server.
A journal wrap error has occurred on the change journal, and therefore DPM is unable to track any more changes or may have missed some changes for the data source <Servername>\MSDPMINSTANCE\ReportServer$MSDPMINSTANCE on <Servername> (ID 30117 Details: Internal error code: 0x809909D1)
Request you to check the application events on the SQL server and check if you are able to find any USN change Journal errors on it.
To resolve the issue please follow below mentioned steps on the drive where the SQL databases is hosted on protected server and check if it addresses your issue.
1.Find Total number of files on an NTFS volume
At an elevated command prompt, type:
C:\Windows\system32> dir C:\ /s /a /w
...
Total Files Listed:
1291512 File(s) 1,946,620,624,461 bytes
325206 Dir(s) 390,660,280,320 bytes free
Add the number of files and directories together for the total amount; 1,616,718 in this example.
2.Check current USN journal size
Query the current value:
C:\Windows\system32> fsutil usn queryjournal C:
Usn Journal ID : 0x01cba9fe68247fa6
First Usn : 0x0000001047d00000
Next Usn : 0x000000104a0bac58
Lowest Valid Usn : 0x0000000000000000
Max Usn : 0x7fffffffffff0000
Maximum Size : 0x0000000002000000
Allocation Delta : 0x0000000000400000
Use the table below to find the approriate values for Maximum Size and Allocation Delta.
Files Maximum Size (m) in bytes Allocation Delta (a) in bytes m (MB) m (hex) a (hex)
400,000 536,870,912 67,108,864 512 20000000 4000000
600,000 805,306,368 100,663,296 768 30000000 6000000
800,000 1,073,741,824 134,217,728 1,024 40000000 8000000
1,000,000 1,342,177,280 167,772,160 1,280 50000000 A000000
1,200,000 1,610,612,736 201,326,592 1,536 60000000 C000000
1,400,000 1,879,048,192 234,881,024 1,792 70000000 E000000
1,600,000 2,147,483,648 268,435,456 2,048 80000000 10000000
1,800,000 2,415,919,104 301,989,888 2,304 90000000 12000000
2,000,000 2,684,354,560 335,544,320 2,560 A0000000 14000000
2,200,000 2,952,790,016 369,098,752 2,816 B0000000 16000000
2,400,000 3,221,225,472 402,653,184 3,072 C0000000 18000000
2,600,000 3,489,660,928 436,207,616 3,328 D0000000 1A000000
2,800,000 3,758,096,384 469,762,048 3,584 E0000000 1C000000
3,000,000 4,026,531,840 503,316,480 3,840 F0000000 1E000000
3,200,000 4,294,967,296 536,870,912 4,096 100000000 20000000
As for the example above, the default USN change journal size of 33,554,432 is to small for the volume. According to the table above, since our volume has at least 1,616,718 file entries; we should set the Maximum Size to 2,415,919,104 and Allocation Delta to 301,989,888.
3. Change the size of the USN change journal
Increase the Maximum Size of the USN change journal using fsutil:
C:\Windows\system32> fsutil usn createjournal m=2415919104 a=301989888 D:
Query the USN change journal to verify the changes were applied:
C:\Windows\system32> fsutil usn queryjournal D:
Usn Journal ID : 0x01cba9fe68247fa6
First Usn : 0x0000001047d00000
Next Usn : 0x000000104a0bac58
Lowest Valid Usn : 0x0000000000000000
Max Usn : 0x7fffffffffff0000
Maximum Size : 0x0000000090000000
Allocation Delta : 0x0000000012000000
**** Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful ****