none
Error-Consistency Check: Cannont find the file specified (80070002) RRS feed

  • Question

  • Would you have a suggestion of what I can do to resolve the following Consistency Check error: "An unexpected error occurred while the job was running. (ID 104 Details: The system cannot find the file specified (0x80070002))"?

    Symptoms: The consistency check runs for a period of time then fails with the error above.  It has failed 3 times.  One time after 47 hours, another after 51 hours and another time after 1 hour.

    Here are some details:

    1. DPM Server. SC 2012 R2, Windows Server 2008 R2, 64 GB memory, 27 TB used on server; 47 TB free

    2. Protected Server. Problem volume has 5.7 TB allocated, 3.3 TB allocated for Recovery Point with a 60 day retention period.  Windows 2008 R2 server, 8 GB memory

    3. Other volumes status.  Only 1 of 5 volumes is failing for the protected server.  Three other volumes and the System State backup run successfully.

    4. Things Tried.  I've reset the DPM server, reset the protected server, restarted DPM services (DPM), restarted protected server services (VSS, DPMRA), removed and recreated the problematic volume, reviewed DPM forum responses, searched through error logs (DPMRAxx, MSDPMxx).

    Thank you in advance for taking a look at this item.

    - Jenna Katie

    Tuesday, July 22, 2014 2:12 PM

Answers

  • Hi,

    KB2871085 sounds like a potential fix and certainly would not hurt anything.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by Jenna Katie Wednesday, July 30, 2014 8:12 PM
    Wednesday, July 30, 2014 5:53 PM
    Moderator

All replies

  • Hi,

    It sounds like the VSS Shadow copy is getting deleted on the protected server - look for System Event messages from source Volsnap.   Check to be sure you have adequate free space on that volume, or you can move the shadow copy storage to another volume that has adequate free space to maintain the shadow copy while a backup is in progress.

    Run the following from an administrative command prompt and make sure the shadowstorage is unbounded for the problematic volume.

    C:\>VSSADMIN LIST SHADOWSTORAGE


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, July 22, 2014 3:58 PM
    Moderator
  • Mike:

    Yes, there is a VolSnap error, "The shadow copies of volume G: were deleted because the shadow copy storage could not grow in time. Consider reducing the IO load on the system or choose a shadow copy storage volume that is not being shadow copied".

    Of interest is that "Disk Queue Length" as seen from Resource Monitor averages 1.8 or more and has reached 5.  The response time in milliseconds for System and DPMRA.exe hovers over 400 and as high as 550.

    When running the VSSAdmin command that you recommended, it shows the storage set to "Unbounded".

    Could it be a fragmentation related problem, requiring running CHKDSK /F on the volume?  Or is there a known hotfix that resolves this problem?

    - Jenna


    • Edited by Jenna Katie Thursday, July 24, 2014 1:18 PM
    Wednesday, July 23, 2014 8:11 PM
  • Hi,

    It certainly does look like a disk IO performance problem that needs to be addressed so the snapshot can be maintained.  I would start by doing a complete disk defrag to help consolidate free space.  If that does not help, then look more at the storage bottleneck. 


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, July 24, 2014 6:04 PM
    Moderator
  • Thank you for your reply.

    I rebooted the protected server, re-ran the Consistency Check and now I was able to successfully create a recovery point.

    Although this is now working, I wonder if I should apply the 2871085 hotfix that resolves I/O problems with VolSnap on large volumes. 

    Volsnap.sys on the protected server that had the problem is dated 11/20/2010 (6.1.7601.17514).  The Volsnap in the hotfix is newer.

    Would you recommend making this update?  Is there another hotfix that explicitly resolves the problem I'm seeing here?

    - Jenna


    • Edited by Jenna Katie Wednesday, July 30, 2014 2:50 PM
    Wednesday, July 30, 2014 2:28 PM
  • Hi,

    KB2871085 sounds like a potential fix and certainly would not hurt anything.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by Jenna Katie Wednesday, July 30, 2014 8:12 PM
    Wednesday, July 30, 2014 5:53 PM
    Moderator
  • I'm marking this item complete and very satisfied with the answer.

    Thank you Mike for all of your efforts in responding with your expertise in this forum!

    Wednesday, July 30, 2014 8:14 PM