none
DPM 2012 Replica Inconsistent Error: ID 60 Details: Internal error code: 0x809909B0 RRS feed

  • Question

  • I’m having a heck of a time getting a consistent replica from some large volumes on one of our file servers. The file server is running Windows Storage Server 2008 R2 Enterprise. The DPM server is Server 2008 R2 Standard, running DPM 2012.

    The protected server has three large volumes. E:, F:, and G:, approximately 8TB, 2TB, and 6TB in size, respectively. I performed a manual copy for the original data population, then performed synchronizations with consistency checks. I’ve been able to get the 6TB G: volume working consistently, and have had daily successful recovery points for the last week or so, which is nice, since it proves that things aren’t completely broken.

    E: and F:, however, have been giving me nothing but problems. Originally I had some problems with things like the 100 failed files limit (on a volume containing millions, 100 is a pretty easy threshold to hit) and compressed files on a SIS volume. I also have read of potential network saturation issues, and have throttled the protection agent accordingly. However, I’m still having trouble. For the last few tries, E: and F: have behaved as follows:

    I start a consistency check. A relatively consistent period of time later (~40 hours later for E: and ~12 hours later for F:), the replica is marked as inconsistent again. The fact that it’s always ~40 or ~12 hours later may be a coincidence, or maybe not. It’s almost like the consistency check finishes, and immediately thereafter the replica is reported as inconsistent. The error is always:

    The protection agent on PLYDPM1.mcquay.com was temporarily unable to respond because it was in an unexpected state. (ID 60 Details: Internal error code: 0x809909B0)

    Plydpm1 is the DPM server. There are a lot of warnings and some fatal errors in the logs, but I’m having trouble making sense of it all. So I’ve uploaded the DPMRA.errlog files from both the DPM server and the protected file server (Plyfile1) for the time of one of the  recent failures of the F: consistency check. The event occurred in DPM on 7/15/2012 at 8:49:03 PM. We’re in Central time, so I believe this corresponds to 7/16/2012 1:49:03 AM in the log files.

    DPM Server (Plydpm1) DPMRA Log file: https://skydrive.live.com/redir?resid=E0F895536B91899B!136

    Protected File Server (Plyfile1) DPMRA log file: https://skydrive.live.com/redir?resid=E0F895536B91899B!137

    Any help or advice anyone can give would be greatly appreciated. If you’d like any more info, want to see a different log file, or have suggestions or questions of me, fire away…

    Tuesday, July 17, 2012 6:57 PM

All replies

  • Same thing again, this time I even hung around to watch it. The consistency check for F: finished after about 11 hours. For a short period of time, it's protection status was green. However, when I tried to manually create a recovery point, the only available option was "Create a recovery point without synchronizing", and when I attempted to do so, I received an error:

    No recovery point was created, either because synchronization has not occurred since the last recovery point was created, or because no changes were found during synchronization. (ID 208)

    After 10 minutes or so, it flagged red again, with the same error as usual:

    The protection agent on PLYDPM1.mcquay.com was temporarily unable to respond because it was in an unexpected state. (ID 60 Details: Internal error code: 0x809909B0)

    Again, any advice would be immensely appreciated.

    Wednesday, July 18, 2012 2:29 AM
  • Getting the same issue here. Were you able to resolve this?

    Tuesday, January 29, 2013 3:28 PM
  • For me it was SIS. It seems SIS and DPM just don't work well together, especially on large volumes. Disabling Single Instance Storage allowed DPM to work as expected. See this thread: http://social.technet.microsoft.com/Forums/en-US/dpmfilebackup/thread/7a4ea070-3faf-40e8-8d7b-91c62196b451

    Hope that helps...

    Tuesday, January 29, 2013 4:00 PM