none
MaxFailedFiles Registry on DPM 2019 doesn't work HELP! RRS feed

  • Question

  • Hi All,

    I'm having trouble backing up a large user share (4TB+) i'm getting:

    Number of files skipped for synchronization due to errors has exceeded the maximum allowed limit of 100 files on this data source (ID 32538 Details: Internal error code: 0x809909FE)

    In the past I'd add the MaxFailedFiles 32-Bit DWORD to the protected machine. I know these files I need to figure out but for now I just need the source backed up so I can work on the file issues. 

    I added the registry key to HKLM\Software\Microsoft\Microsoft Data Protection Manager\AgentContinueOnFailure and added DWORD MaxFailedFiles with a value of 9999 decimal.

    I then restart DPMRA on both nodes of my files server (it wasn't running anyway).

    I then rerun the consistency check but it fails again saying the maximum allowed limit has been hit at 100. I've tried using 1000 as the number too. It seems it always fails at 100. 

    Am I doing something wrong here? Has this registry key changed on the new DPM? I'm at a loss right now. Any ideas?

    Tuesday, June 11, 2019 8:50 PM

All replies

  • Hi,

    I haven't used the registry workaround since some versions so I cannot confirm, but I think it should work for newer DPM versions.

    Do you have any antivirus software on your server? Is the protected server's disk encrypted?

    You could try giving the local SYSTEM user full control permissions on the user share and see if it helps.


    I would really recommend reviewing why there are so many skipped files though, even though the backup is important.


    This can be done by mounting the volume and finding the FailedFiles.dat file, or you can check the DPM log on the protected server under C:\Program Files\Microsoft Data Protection Manager\DPM\Temp.

    Run the following command:

    Find /I "BackupRead failed" DPMRA*.errlog > C:\Temp\Error.txt


    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    Tuesday, June 11, 2019 9:31 PM
  • So I checked the log and I believe it's due to possible viruses/malware on some of the user shares. I've receiving 0x800700e1 on all files in FailedFiles.txt. I have realtime virus scanning disabled on the Protected Server. The backup server is a 2019 box and it may be enabled on the backup server itself. Although I'm feeling this is just DPM doing this itself. 

    I'm aware I need to clean the possible "malware" files from user shares but I'd rather not reach in and delete a ton of stuff before I have a backup in case it's in error. 

    Anyway to disable this checking? I'd preferably like to just get at least one backup and then go through and clean the files. 

    Wednesday, June 12, 2019 12:10 AM
  • If the registry workaround doesn't work, then I'm afraid you have no other option other than to go through the skipped files, if these are indeed malware, you should be very concerned.

    I suggest you run a deep anti-virus/malware scan to start off, then go through the files, also make sure there isn't any other software that may be blocking the file access. Also check the permissions of some of these files, check whether DPM can access them (SYSTEM user).

    Side note: Even if the antivirus/antimalware software is disabled, it doesn't necessarily mean that it's not running, I've encountered many cases where these software still block access to files, this can cause issues for backup software like DPM.


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, June 12, 2019 12:04 PM
  • I've run a full scan and it still didn't clear it up. It's like it didn't even quarantine all files. I really need to get this backed up. I can't believe I can't tell it to just ignore this.
    Friday, June 21, 2019 7:54 PM
  • Another reason to why DPM might skip the files is if the file path is too long, you can find long file paths with the following command:

    cmd /c dir /s /b |? {$_.length -gt 260}

    Here's also a tool: Path Length Checker


    Blog: https://thesystemcenterblog.com LinkedIn:

    Tuesday, June 25, 2019 10:30 PM