DPM2010 - Replica inconsistent due to access denied in user profiles cookies folder RRS feed

  • Question

  • Running DPM2010 on 2008R2, backing up target machine running 2008R2

    The Errors:

    The replica of E:\ on server.domain.local is inconsistent with the protected data source. All protection activities for this data source will fail until the replica is synchronized with consistency check. Number of files skipped for synchronization due to errors has exceeded the maximum allowed limit of 100 files on this data source 

    I also had an error that gave me more details on where to find the failedfileslog:
    Review the failure errors for individual files from the log file \\?\Volume{c18bee0a-f772-11df-a02c-d8d385b5ea0d}\9DBF52DB-CB0F-488B-A1E8-84A6CC14EA5D\FailedFilesLog.txt and take appropriate action. If some files fail consistently, you can exclude the folders containing these files by modifying the protection group or moving the files to another location.

    Inside that file there are 100 lines all with similar error codes:
    0x80070005 \\?\Volume{66ab2207-894a-40db-b14c-60abd43604ad}\SHARE\Users\USERNAME\Cookies\USERNAME@atdmt[1].txt

    It looks like 0x80070005 translates to Access Denied.

    So to attempt a resolution, I've set MaxFailedFiles DWORD to 99999 in
    HKLM\Software\Microsoft\Microsoft Data Protection Manager\Agent\ContinueOnFailure

    Then I restarted DPMRA on the target server and am currently running a sync with consistency check. Hopefully it's enough to get a full backup.

    Although backing up cookies is not a critical function, I'd like the backup to run normally without having to create exceptions or having to allow so many failed files. What can I do to allow DPM to copy these files?



    Wednesday, December 8, 2010 4:45 PM

All replies

  • 26 hours later and the consistency check is still running (yes, it's a huge share). Just thought I'd share a quick workaround I came up with in case it helps others.

    I don't really care about cookies that have been stored in a user's profile folder on a network share, so I figured I'd delete them using:

    del *[?].txt /s

    from the root of the Users share.
    (in my case all cookies had a blah@domain[1].txt or blah@domain[2].txt and we didn't have any other files with that in their file names, your situation might be different, so be careful when deleting things out of user profile folders)


    Thursday, December 9, 2010 7:40 PM
  • FYI,  0x80070005 - Access Denied errors are usually caused by anti-virus software having an exclusive handle open to the file(s) - can't say for sure that was the cause, but should it happen again, investigate that as a possibility.
    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, December 10, 2010 11:16 PM
  • Thanks - I disabled all AV and removed/readded to the protection group. Forcing a new sync now, we'll see how it goes this time around.
    Tuesday, December 14, 2010 5:11 PM
  • If the problem has been identified, it is recommended to re-set 'MaxFailedFiles' to some lower value so that you do not end up skipping large number of files (99999 in your case).
    Thanks, Surendra Singh [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, December 15, 2010 3:51 AM