none
Server 2012 wbadmin backup failing - The mounted backup volume is inaccessible RRS feed

  • Question

  • Hi Folks,

    I'm trying to run a backup on one of my 2012 DC's using wbadmin's -allcritical switch. The backup is being directed to a network share on a Netapp. The machine is a VM running on VMWare, however, other physical 2012 servers are able to backup to this Netapp successfully. The syntax being used is:

    wbadmin start backup -backuptarget:"\\fileserver\VM Backup\MYDC\1st" -include:c: -allcritical -vssfull -quiet > "c:\scripts\Server Backup.log"

    Strangely, the 350 MB 'System Reserved' partition auto-created during the Windows install seems to back up and copy fine, but the C: drive will not. I have tried directing the backup to a different network share with the same result. I have wbadmin running sucessfully on 5 other 2008\R2 servers (also VM's running from the same VMWare server) against the same network share.

    Any ideas on this? I'm not really finding much on it I'm afraid. Thanks for any help,

    ianc

    Below is the output from the log: 

    Retrieving volume information...
    This will back up System Reserved (350.00 MB),MYDC(C:) to \\fileserver\VM Backup\MYDC\1st.
    The backup operation to \\fileserver\VM Backup\MYDC\1st is starting.
    Creating a shadow copy of the volumes specified for backup...
    Creating a shadow copy of the volumes specified for backup...
    Creating a backup of volume System Reserved (350.00 MB), copied (56%).
    The backup of volume System Reserved (350.00 MB) completed successfully.
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    The backup of volume MYDC(C:) could not be completed. Error: The mounted backup volume is inaccessible. Please retry the operation.
    Summary of the backup operation:
    ------------------

    The backup operation stopped before completing.
    The backup operation stopped before completing.
    Detailed error: The mounted backup volume is inaccessible. Please retry the operation.
    Log of files successfully backed up:
    C:\Windows\Logs\WindowsServerBackup\Backup-02-01-2013_21-17-33.log

    Log of files for which backup failed:
    C:\Windows\Logs\WindowsServerBackup\Backup_Error-02-01-2013_21-17-33.log

    There was a failure in preparing the backup image of one of the volumes in the backup set.
    The mounted backup volume is inaccessible. Please retry the operation.



    • Edited by ianc3 Thursday, January 3, 2013 4:54 PM
    Wednesday, January 2, 2013 10:41 PM

Answers

  • wel..

    can you try to increase the space allocated for  c: in the snap in..

    let not calculate any at the moment..  give it 10 gb for example.

    then try a abckup again.

    just increase that parameters, dont active or schedule shadow copies on volume c:, that is different thing, not related to wbadmin if similar concept.

    so.. go c: icon, right click go in shadow copies and from it allocate the space.

    Regards


    ------------------------------------------------------- I understand a little computers.

    • Marked as answer by ianc3 Monday, January 14, 2013 8:15 PM
    Friday, January 11, 2013 6:28 PM

All replies

  • Friday bump. Any help?

    ianc

    Friday, January 4, 2013 4:24 PM
  • Hello


     i would check permission on the share, about this i give you a link that will help you understand what i mean..

    http://technet.microsoft.com/en-us/library/cc742083(v=ws.10).aspx

    i dont see any "-user", "-password" or "-noinheritAcl" value in your string.. and your backing up to a shred folder.

    Regards


    ------------------------------------------------------- I understand a little computers.

    Saturday, January 5, 2013 1:04 AM
  • Hi,

    Thanks for your reply. I don't see this as being a permissions issue since, as stated, one of the VM's two volumes is backing up successfully to the share. A permissions issue would prevent that.

    Also, I have other VM's backing up successfully to that share using the same credentials as the problematic VM's scheduled task.

    Any other ideas? Thanks,

    ianc

    Monday, January 7, 2013 5:30 PM
  • I see..

    after i failed backup have you tried to check your vss providers ?

    vssadmin list providers, thay are all healthy and without errors ?

    Regards


    ------------------------------------------------------- I understand a little computers.

    Monday, January 7, 2013 5:38 PM
  • does integration tools on the vm are ok ? 

    can you check them in hyper v manager vm properties please..

    if vvs full backup is marked


    ------------------------------------------------------- I understand a little computers.

    Monday, January 7, 2013 5:41 PM
  • Hi Ales75,

    Regarding the VMWare tools, they are installed and the VMWare tools service is running. As originally mentioned, this is not a Hyper-V VM. Not sure what you mean by "vvs full backup is marked"...

    Here are the results from running 'vssadmin list providers' from the command line; I don't see any status or error messages there however:

    C:\Windows\system32>vssadmin list providers

    vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
    (C) Copyright 2001-2012 Microsoft Corp.

    Provider name: 'Microsoft File Share Shadow Copy provider'
       Provider type: Fileshare
       Provider Id: {89300202-3cec-4981-9171-19f59559e0f2}
       Version: 1.0.0.1

    Provider name: 'Microsoft Software Shadow Copy provider 1.0'
       Provider type: System
       Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
       Version: 1.0.0.7

    Thanks for your help,

    ianc


    Monday, January 7, 2013 8:39 PM
  • ooops sorry i didn't get  you are on wmware..

    and sorry.. i asked you to run list providers

    but i wanted you to run 

    vssadmin list writers

    after a failed backup

    Regards


    ------------------------------------------------------- I understand a little computers.

    Monday, January 7, 2013 8:56 PM
  • Hi Ales75,

    I just attempted to run a backup and when it failed I ran 'vssadmin list writers'. The results are listed below; I don't see any errors listed.

    Thanks again for the help,

    ianc

    C:\Windows\system32>vssadmin list writers
    vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
    (C) Copyright 2001-2012 Microsoft Corp.

    Writer name: 'Task Scheduler Writer'
       Writer Id: {d61d61c8-d73a-4eee-8cdd-f6f9786b7124}
       Writer Instance Id: {1bddd48e-5052-49db-9b07-b96f96727e6b}
       State: [1] Stable
       Last error: No error

    Writer name: 'VSS Metadata Store Writer'
       Writer Id: {75dfb225-e2e4-4d39-9ac9-ffaff65ddf06}
       Writer Instance Id: {088e7a7d-09a8-4cc6-a609-ad90e75ddc93}
       State: [1] Stable
       Last error: No error

    Writer name: 'Performance Counters Writer'
       Writer Id: {0bada1de-01a9-4625-8278-69e735f39dd2}
       Writer Instance Id: {f0086dda-9efc-47c5-8eb6-a944c3d09381}
       State: [1] Stable
       Last error: No error

    Writer name: 'System Writer'
       Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
       Writer Instance Id: {289325e1-1862-4c47-bbdc-1e106d8b1a33}
       State: [1] Stable
       Last error: No error

    Writer name: 'ASR Writer'
       Writer Id: {be000cbe-11fe-4426-9c58-531aa6355fc4}
       Writer Instance Id: {0d15e802-942b-4b69-94db-a0afce5b4a41}
       State: [1] Stable
       Last error: No error

    Writer name: 'Registry Writer'
       Writer Id: {afbab4a2-367d-4d15-a586-71dbb18f8485}
       Writer Instance Id: {94791bf4-ce05-407d-9c9f-9cff67834b54}
       State: [1] Stable
       Last error: No error

    Writer name: 'FRS Writer'
       Writer Id: {d76f5a28-3092-4589-ba48-2958fb88ce29}
       Writer Instance Id: {d8ce9d88-53d8-4f64-b69a-ab5d2e8d1c3b}
       State: [1] Stable
       Last error: No error

    Writer name: 'WMI Writer'
       Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
       Writer Instance Id: {1d8da999-79bd-4eb3-8c6d-8ba3a4ddb8ca}
       State: [1] Stable
       Last error: No error

    Writer name: 'Shadow Copy Optimization Writer'
       Writer Id: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}
       Writer Instance Id: {b65b59f7-8e0d-4efe-b177-2219004032b3}
       State: [1] Stable
       Last error: No error

    Writer name: 'COM+ REGDB Writer'
       Writer Id: {542da469-d3e1-473c-9f4f-7847f01fc64f}
       Writer Instance Id: {d0f9e977-eeac-46d1-a1cb-fc0f56ad1bd1}
       State: [1] Stable
       Last error: No error

    Writer name: 'NPS VSS Writer'
       Writer Id: {35e81631-13e1-48db-97fc-d5bc721bb18a}
       Writer Instance Id: {5efa1af8-43dd-469e-925f-50b3d78f344d}
       State: [1] Stable
       Last error: No error

    Writer name: 'NTDS'
       Writer Id: {b2014c9e-8711-4c5c-a5a9-3cf384484757}
       Writer Instance Id: {655cd057-f15a-4b19-974a-edac0ca7fa2f}
       State: [1] Stable
       Last error: No error

    Writer name: 'Dhcp Jet Writer'
       Writer Id: {be9ac81e-3619-421f-920f-4c6fea9e93ad}
       Writer Instance Id: {7cd69688-5a39-49f8-99c7-548e3ac1c2bc}
       State: [1] Stable
       Last error: No error

    Monday, January 7, 2013 9:12 PM
  • well they are good..

    ok ma be a stupid question, do you have an antivirus installed ? 


    ------------------------------------------------------- I understand a little computers.

    Monday, January 7, 2013 9:42 PM
  • Nope, no AV I'm afraid...

    Thanks again,

    ianc

    Monday, January 7, 2013 9:57 PM
  • Another bump - Any more ideas? Thanks,

    ianc

    Wednesday, January 9, 2013 4:56 PM
  • I'm running into the same thing. So far, the only workaround I've found is to send the initial backup to an alternate location. In this case, a file share off of another Windows server. Once the initial backup completes, copy the WindowsServerBackup\* files from the Windows share to the NetApp share. From then on, the 2012 server seems to be fine with overwriting the backup files on the NetApp target location.
    Wednesday, January 9, 2013 10:49 PM
  • hello

    it is a permission issue.. its just about understand where.. your system state goes well.. but not the drive c..

    if you have storage, can you perform a local back on a volume for example.. same backup.. just local on server, then if it works, try again backin up with remote folder.

    regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 12:57 AM
  • pleade also..

    may be you have other errors except the log result.. can you check your logs and post the errors..

    regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 1:01 AM
  • last but not least, may check you if your netapp is FULLY compatible with SMB 3.0

    Regards


    ------------------------------------------------------- I understand a little computers.


    • Edited by Ales75 Thursday, January 10, 2013 1:08 AM adjust
    Thursday, January 10, 2013 1:08 AM
  • also..

    did you try to map a network drive and choose it as destination.. its same like share but the creation of mapped drive involve permission applying that could help.

    Regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 1:14 AM
  • It's not a permissions issue, since I'm using the same account in all cases to run the backups. As soon as a full set of backup files are in the NetApp share, subsequent backups run fine.

    The WBEngine.0.etl log shows "The backup operation that started at '2013-01-09T22:21:29426820600Z' has failed with the following error code '0x807800C5' (There was a failure in preparing the backup image of one of the volumes in the backup set.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved."

    The Error log file shows "Backup of volume C: has failed. The specified backup disk cannot be found."

    I'm checking with our storage folks on the version of SMB that the NetApp supports. This seems to be the most likely cause.

    Finally, Windows Server Backup doesn't allow a mapped drive to be the backup target. It has to be either a local drive or a UNC path.

    Thursday, January 10, 2013 2:49 PM
  • hello

    sorry i have not been clear..

    map the share to a drive, and check you are able to browse, then alway use the unc path.

    just a try..

    Regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 3:04 PM
  • Yes, mapping the share to a drive works, and I'm able to browse/create/modify/delete files.
    Thursday, January 10, 2013 3:07 PM
  • check the smb thing.. and let me know..

    regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 3:15 PM
  • Ales75,

    It is not a permissions issue; this was discussed already. Please read the entire thread before replying. Logs have been posted already.

    I also have read the SMB 3.0 thing, but it is not the case here. I have a physical Server 2012 machine successfully running a backup against the same Netapp share that this particular 2012 VM is failing against, so that is not the issue. It seems we need to dig a little deeper here.

    I do not have sufficient disk space on the VM to do a local backup, and the VM is managed by a 3rd party, so I cannot easily add more.

    HColeman, interesting workaround that you've found RE: doing the backup to a Windows share then just moving the backup files to the Netapp. I'll give that a try and report back.

    Thanks,

    ianc

    Thursday, January 10, 2013 5:10 PM
  • hello..

    well i am not a netapp expert.. just had chances to get hands on a couple of time.. what i know from friends etc.. is that lastly and since smb 3.0 has beend introduced someone with may be older equipments are having little troubles. and for this i asked you to take a look into it..

    i know about that workaround.. but damn i would use it.. it must work ! :)

    let me know

    regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 5:15 PM
  • I tried disabling smb 3 signing on the Win 2012 server, and also disabling smb 3 altogether on the server, but neither of those resolved the failing backups.
    Thursday, January 10, 2013 5:30 PM
  • Well, our problems diverge then HColeman. Too bad; I would have been happy with your workaround it if had worked for me, but...

    I tried creating a share (everyone has write on the share and full control NTFS perms) on a Windows server and sending the backup there, but it still failed. Not only that, the 350 MB System Reserved partition which worked previously would not even back up. On a whim, I then removed the Windows Backup feature, rebooted and readded it, then tried again to both the windows server and the Netapp. Same result. The WindowsImageBackup folder and various subfolders and files are getting created in the destination(s), but then it just errors out. Looks like wbadmin can't actually access the shadow copy for some reason. Logs are now looking like below. Any more thoughts? Thanks,

    ianc

    Retrieving volume information...
    This will back up System Reserved (350.00 MB),MYDC(C:) to \\fileserver\VM Backup\MYDC\1st.
    The backup operation to \\fileserver\VM Backup\MYDC\1st is starting.
    Creating a shadow copy of the volumes specified for backup...
    Creating a shadow copy of the volumes specified for backup...
    Creating a backup of volume System Reserved (350.00 MB), copied (30%).
    The backup of volume System Reserved (350.00 MB) completed successfully.
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    Creating a backup of volume MYDC(C:), copied (0%).
    The backup of volume MYDC(C:) could not be completed. Error: The mounted backup volume is inaccessible. Please retry the operation.
    Summary of the backup operation:
    ------------------

    The backup operation stopped before completing.
    The backup operation stopped before completing.
    Detailed error: The mounted backup volume is inaccessible. Please retry the operation.
    Log of files successfully backed up:
    C:\Windows\Logs\WindowsServerBackup\Backup-10-01-2013_21-37-16.log

    Log of files for which backup failed:
    C:\Windows\Logs\WindowsServerBackup\Backup_Error-10-01-2013_21-37-16.log

    There was a failure in preparing the backup image of one of the volumes in the backup set.
    The mounted backup volume is inaccessible. Please retry the operation.



    • Edited by ianc3 Thursday, January 10, 2013 9:47 PM
    Thursday, January 10, 2013 9:45 PM
  • i give a fast answer for a fast check..

    can you check if have enough space fro creating shadowds copy ?..

    if it is not a problem for you, can you remove/delete all shadows copy again and try...

    disk shadow

    delete shadows all.

    Regards


    ------------------------------------------------------- I understand a little computers.

    Thursday, January 10, 2013 9:55 PM
  • Hi Ales75,

    Your instructions for checking\deleting shadow copies are not clear, but it seems unlikely to me that space is the issue. The C: drive has 25 out of 40 GB free, and when I right click on the drive in my computer and choose 'configure shadow copies', no existing shadow copies are displayed for that volume...

    ianc

    Friday, January 11, 2013 5:49 PM
  • Hello

    glad to hear that.. so may be we got it.. for this kinds of issues there are Always some things to check.. honestly i was much more into the permission issue.. butsince we assumed they were not.. i gave you my last hint.

    to delete snapshots.. 

    you can do it in diskshadow from the cli

    when in diskshadow

    delete shadows all

    exit

    however if you c: has not shadow copies configured doesnt mean any, we are talking about shadow stored for wbadmin.

    can you provide me the output of

    vssadmin list shadows

    regards


    ------------------------------------------------------- I understand a little computers.

    Friday, January 11, 2013 5:58 PM
  • forgot..

    please provide me also

    vssadmin list shadowstorage


    ------------------------------------------------------- I understand a little computers.

    Friday, January 11, 2013 6:06 PM
  • Hi Ales75,

    Thanks for your reply. Here is the output of the two commands you specified,

    ianc


    C:\Windows\system32>vssadmin list shadows
    vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
    (C) Copyright 2001-2012 Microsoft Corp.

    No items found that satisfy the query.

    C:\Windows\system32>vssadmin list shadowstorage
    vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
    (C) Copyright 2001-2012 Microsoft Corp.

    Shadow Copy Storage association
       For volume: (\\?\Volume{f4ca7318-2edd-11e2-93e7-806e6f6e6963}\)\\?\Volume{f4c
    a7318-2edd-11e2-93e7-806e6f6e6963}\
       Shadow Copy Storage volume: (\\?\Volume{f4ca7318-2edd-11e2-93e7-806e6f6e6963}
    \)\\?\Volume{f4ca7318-2edd-11e2-93e7-806e6f6e6963}\
       Used Shadow Copy Storage space: 0 bytes (0%)
       Allocated Shadow Copy Storage space: 0 bytes (0%)
       Maximum Shadow Copy Storage space: 35.0 MB (10%)

    Shadow Copy Storage association
       For volume: (C:)\\?\Volume{f4ca7319-2edd-11e2-93e7-806e6f6e6963}\
       Shadow Copy Storage volume: (C:)\\?\Volume{f4ca7319-2edd-11e2-93e7-806e6f6e69
    63}\
       Used Shadow Copy Storage space: 0 bytes (0%)
       Allocated Shadow Copy Storage space: 0 bytes (0%)
       Maximum Shadow Copy Storage space: 3.96 GB (10%)

    Friday, January 11, 2013 6:17 PM
  • wel..

    can you try to increase the space allocated for  c: in the snap in..

    let not calculate any at the moment..  give it 10 gb for example.

    then try a abckup again.

    just increase that parameters, dont active or schedule shadow copies on volume c:, that is different thing, not related to wbadmin if similar concept.

    so.. go c: icon, right click go in shadow copies and from it allocate the space.

    Regards


    ------------------------------------------------------- I understand a little computers.

    • Marked as answer by ianc3 Monday, January 14, 2013 8:15 PM
    Friday, January 11, 2013 6:28 PM
  • Hallelujah!

    That did the trick! Both of the partitions on the drive had limits set on them for shadow copy usage, although scheduled shadow copies were disabled. I just set both to 'No Limit', ran the backup again and it worked:

    Percentage-wise, the portion of space allocated for these partitions was about the same as those on physical machines that were succeeding, so I don't know why I ran into trouble here. I'm not going to try experimenting to see exactly how much space needs to be allocated here, but will just leave it at No Limits.

    Thanks again for the suggestions and your patience!

    ianc

    Monday, January 14, 2013 8:15 PM
  • Glad it worked..

    i dont suggest you to run it with unlimited space.. or if yes .. remember to monitor it often..

    regards


    ------------------------------------------------------- I understand a little computers.

    Wednesday, January 16, 2013 7:27 PM
  • i have the same problem
    Friday, April 19, 2013 2:01 PM
  • Hallelujah!

    That did the trick! Both of the partitions on the drive had limits set on them for shadow copy usage, although scheduled shadow copies were disabled. I just set both to 'No Limit', ran the backup again and it worked:

    Percentage-wise, the portion of space allocated for these partitions was about the same as those on physical machines that were succeeding, so I don't know why I ran into trouble here. I'm not going to try experimenting to see exactly how much space needs to be allocated here, but will just leave it at No Limits.

    Thanks again for the suggestions and your patience!

    ianc

    i tried this and it still fails
    Friday, April 19, 2013 2:26 PM
  • I have exactly the same issue as the original post. I have Hyper-V hosts and non-primary domain controllers backing up to a NAS using Windows Server Backup. For some reason, the C: drive from the primary domain controller won't back up for the issues stated above.

    My primary domain controller is running as a virtual machine on a hyper-V server. I modified the shadow copy settings as Ian has and this didn't change the outcome of the backup of C drive from the primary domain controller. I had created powershell scripts to configure windows backup on all environments and the only issue is the PDC C: drive.

    Our NAS uses domain authentication and I have also tried using a local account which has been defined on the PDC and the NAS for the backup credentials and this doesn't make a difference either.

    Is there anything unique about backing up a primary domain controller from within itself?

    --edit: I'm actually experiencing issues with copying files to the NAS from the PDC throught windows explorer. It keeps hanging and will need to fix that issue first!

    --edit: There was no communication issue with my QNAP but I was able to fix the problem. I performed the first backup on a local drive. For a virtual machine you have to create a second virtual hard disk, partition and format it etc. Back-up to this drive then copy the backup folder to the NAS. Modify the backup schedule to point to the NAS UNC path and test the back-up by doing a once-off backup with the scheduled backup configuration.

    My assumption as to why this works may be along the lines of Windows Server Backup being able to set permissions without error on the back-up files and folders as they are being created. Once this is done you can move the files with existing permissions to the NAS. Any thoughts on this would be great.

    • Edited by Nobby_ Wednesday, October 9, 2013 3:55 AM
    Tuesday, October 8, 2013 4:08 AM
  • I had the exact same problem but I was able to resolve it by deleting the 'WindowsImageBackup' folder in the destination path. After doing this I ran the job again and it recreated the folder and successfully completed a full backup of my DC.

    -Edit

    By the way volume shadow copies were not enabled on any volume in this VM and I did not need to enable them to complete a successful Windows Server Backup.

    • Edited by Daniel Bartholomaeus Wednesday, December 2, 2015 11:54 PM Additional Information
    • Proposed as answer by NETLDOE Tuesday, September 27, 2016 1:18 PM
    Wednesday, December 2, 2015 11:52 PM
  • I know this is 5 years too late, but I've been struggling with this for the past two days on 3 separate servers and just wanted to put this here in case anyone else stumbles on your thread looking for a solution, just like I did.

    To fix this problem on all 3 servers I followed this procedure:

    1. Remove the SystemState and BareMetal data sources from the DPM console, deleting the replica from disk
    2. Stop protection of any other data sources which are located on the protected server, retaining the replica
    3. Uninstall the DPM Agent from the protected computer in the 'Management' section of the DPM console
    4. On the protected computer, delete the 'C:\Program Files\Microsoft Data Protection Manager' folder
    5. On the protected computer, uninstall the Windows Server Backup feature
    6. On the protected computer, reinstall the Windows Server Backup feature
    7. Install the DPM Agent from the protected computer in the 'Management' section of the DPM console
    8. Add the SystemState and BareMetal data sources to your chosen protection group in the DPM console (This should now successfully back up the data source!)
    9. Re-add any additional data sources to their protection groups. This will force a consistency check.

    All should be back to normal after this.

    • Edited by WorkProfile Thursday, August 23, 2018 10:14 AM
    Wednesday, January 17, 2018 5:19 PM
  • So, this issue reared it's ugly head again, but I found a different solution this time around. In truth, this is probably the root cause of the issue, so thought I'd leave this here too.

    This issue presented itself with DPM not being able to to a 'Bare Metal' backup of a 2012R2 VM. The DPM client basically runs a batch file with the command:

    start  /WAIT %SystemRoot%\system32\wbadmin.exe start backup -allcritical -quiet -backuptarget:%1

    ...so this should still apply to OP's situation.

    When a bare metal backup is created the wbadmin executable creates .vhdx files for each volume. I opened the disk management utility to find that wbengine had mounted the .vhdx for the EFI partition and it looked fine. When it got to mounting the .vhdx for the C: partition, I saw that it claimed the disk wasn't initialised. I set the partition table to GPT and  formatted it as NTFS; default settings and did not assign a drive letter.

    After this, I deleted the DPM datasources and recreated them. DPM created the replica and it passed a consistency check OK, showing an available recovery point in the GUI. Manually running the command from the command line started working too.

    This whole issue stemmed from the .vhdx that the windows backup program created not being initialised correctly. If you have this error, check that.





    • Edited by WorkProfile Thursday, August 23, 2018 10:16 AM
    Thursday, August 23, 2018 10:14 AM
  • wel..

    can you try to increase the space allocated for  c: in the snap in..

    let not calculate any at the moment..  give it 10 gb for example.

    then try a abckup again.

    just increase that parameters, dont active or schedule shadow copies on volume c:, that is different thing, not related to wbadmin if similar concept.

    so.. go c: icon, right click go in shadow copies and from it allocate the space.

    Regards


    ------------------------------------------------------- I understand a little computers.

    I ran into this wbadmin error on a Win 8.1 Pro system (not a VM, just backup to external drive) and this answer alerted me to the shadow copies problem of running out of space on the EFI vol or the WinRe vol created by Windows install. 

    I was not able to use the "vssadmin add shadowstorage" or "vsadmin resize shadowstorage" commands that I found in this thread though it may work for some..  https://social.technet.microsoft.com/Forums/windowsserver/en-US/407263e9-b40f-449b-aec6-e2572d0d7ef3/windows-server-backup-baremetal-backup-hangs-vss-and-the-efi-system-partition?forum=winserver8gen

    What I ended up doing to get past the problem was to boot to an alternate device (USB) and use a partition manager that is capable of dynamic resize/move features. Then I did the following:

    1) resize C: and pushed the front of the partition up about 500mb to give some free space in front of it

    2) move resize the EFI part (orig at 100mb) to 400mb and pushed it up against the C: part

    3) resize the WinRe part (orig at 300mb) to take up the remaining space 

    This way I kept the partitions in the same order and they would keep same GUID and such so as not to break the boot.. After reboot, attempted the wbadmin again with the "-allCritical" option and it worked..

    Cheers!

    Monday, September 23, 2019 7:13 PM