DPM 2010 - System State to tape failing RRS feed

  • Question

  • Hi. I have a protection group setup that backs up 9 servers system states straight to tape once a week. They all backup fine apart from one. When I check WBS on that protected server (file server) it has created the System State fine (sucess). This happens every week with a DPM error saying:

    If cluster failover has happened during backup, please retry the operation. Otherwise, increase the amount of free space on volume \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy403\ on the source server and then retry the operation.

    DPM failed to access the volume \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy403\ on BMDFPS01.BusinessMoves.local. This could be due to
    1) Cluster failover during backup or
    2) Inadequate disk space on the volume.
     (ID 2040 Details: The device is not ready (0x80070015))

    There is enough free space and this is obvious because the WBS completes fine.

    The protected server is windows 2008 R2. The DPM server is the same and uses DPM 2010.

    Any ideas? I have used VSADMIN list writers and that is fine.


    Tuesday, November 29, 2011 1:07 PM

All replies

  • Hi,

    It could be that the shadow copy on the protected server is being deleted (due to lack of shadow copy storage space) before we can copy the systemstate backup from it.  Look in the system event log errors for errros from source volsnap.   Free some more disk space from the volume holding the WindowsImagebackup folder, or move it to another volume with more free space.

    Change the Location of the Backup File  (dpm 2007 content still applicable to DPM 2010)

    1. On the protected computer, open PSDatasourceConfig.xml in an XML or text editor. PSDatasourceConfig.xml is typically located at install path\Program Files\Microsoft Data Protection Manager\DPM\Datasources.

    2. Under the System Protection section as shown below - Change the <FilesToProtect> value from present drive letter IE: C: to the desired new locations drive letter IE: D: (do not change the folder name)

    <ComponentName>System Protection</ComponentName>

    3. Save the file. 

    4. On the DPM server, if there is a protection group protecting the system state of the protected computer in step 1, run a consistency check.

    5. The consistency check will fail and generate an alert. Perform the recommended actions in the alert as follows:

    a. In the alert details, click the Modify protection group link, and then step through the wizard.

    b. Perform a consistency check.


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, November 29, 2011 7:53 PM
  • Hi Mike. Thanks for your reply. I think you are onto something and pointed me in the right direction thank you. I should have said I have already redirected the systemstate via the xml file but when I searched in eventviewer for volsnap errors I noticed the following:

    "The shadow copies of volume E: were aborted because the shadow copy storage could not grow due to a user imposed limit."


    "The oldest shadow copy of volume E: was deleted to keep disk space usage for shadow copies of volume E: below the user defined limit."

    There is 66gb free on that volume so I have just looked in the Shadowcopy config of E: and it had a user limit of 15gb. I have just upped it to 30gb so that still leaves enough free space for the time being. I will see how that runs this week (it actually runs on Friday so I will get back to you on Monday).

    Thanks very much Mike.

    • Edited by nicknickuk Wednesday, November 30, 2011 9:47 AM
    Wednesday, November 30, 2011 9:36 AM
  • Great, that makes sense and it sounds like the solution should work - look forward to the results on Monday.
    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, November 30, 2011 11:49 AM
  • Hi Mike

    I still had the same problem. The same error messages were appearing in EventViewer and the System state for the FPS server failed to backup to tape. It doesnt make sense to me. Also which is proberly linked to the problem the Shadowcopy is only keeping one copy and overwrites itself each day although the shadowcopy snapshot is only 1.5gb.

    Shadowcopy is setup as follows:

    Disk space of E: is currently 65gb free of 299gb

    User limit of 30gb

    Schedule weekly at 7am and 12pm mon to fri

    To me that seem like plenty of space.

    The only other thing I can think of that might be causing a problem is the E: drive data is always syncronising in dpm because there is so much data (over 200gb).

    Scratching my head a bit now...


    Monday, December 5, 2011 10:22 AM
  • Just for a test try this:  vssadmin Resize ShadowStorage /For=E: /On=E: /MaxSize=UNBOUNDED

    Then try a new backup of systemstate.

    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, December 5, 2011 3:58 PM
  • Hi Mike, thanks for your reply.

    I might be wrong so please tell me if I am way off but I am a bit weary about running that command and then the systemstate backup incase the shadowcopy fills up the space because it would cause huge problems for this particular customer if that was to happen.

    I know I could run the systemstate backup during the day and monitor it but we run systemstate backups over night because we do not want to use up the bandwidth during the day, so I would not be about to cancel it if it did take up the space. It uses up lots of bandwidth because the DPM server is not in the same location as the datacentre where the FPS is.

    For the moment I have disabled shadowcopy on the FPS server and will see if on Friday night DPM backs up the FPS systemstate sucessfully then I can narrow it down a bit more.

    If it still fails then maybe I can try the UNBOUNDED command.

    Tuesday, December 6, 2011 12:24 PM
  • Well I have narrowed this down a bit. I disabled the shadowcopy and over the weekend it has completed a sucessfull SystemState abckup of that FPS server.

    So I know there is a problem with Shadowcopy. Just wondering how to troubleshoot that now....

    Tuesday, December 13, 2011 8:28 AM