10

I'm trying to add multiple USB external disk targets to a Windows Server 2012 Backup schedule.

Having gone through the steps in the GUI to add an additional target, the process fails with the error The system cannot find the path specified.

I followed the steps in this article:

  • Option 1 is a non starter, because we have over a dozen removable disks, and I don't want to buy a box full of USB hubs and hang all these disks out the back of the server rack. So in this instance, the article suggests moving on to step 3.
  • Option 2 removes old disks from the backup schedule, not an option, for obvious reasons.
  • Option 3 suggests running the command WBADMIN ENABLE BACKUP -addtarget:{DISKGUID}, but this fails with the error message ERROR - The specified backup location could not be found or is not a supported backup storage location.

I've found numerous threads with some people reporting success on option 3, but others with, like myself have the exact same problem.

I've checked event logs, and the files in the directory C:\Windows\Logs\WindowsServerBackup, but haven't found anything helpful. I've also tried deleting the volume on the disk and repeating the process, as well as pre-creating an NTFS volume on the disk.

I'm using a series of USB disks with an unformatted capacity of 2TB (1.82TB formatted) if that is of any relevance.

Has anyone else had this problem and managed to resolve it?


Update 1

An answer to this question suggested putting quotes around the GUID e.g. WBADMIN ENABLE BACKUP -addtarget:"{DISKGUID}". This goes a step further as it asks me if I want to format the device, however, after formatting, it then fails with the error The system cannot find the path specified.

Bryan
  • 7,538
  • 15
  • 68
  • 92
  • Anyone please? Got the same problem here. Fortunately, I only have 5 disks so doable to attach them all and run the config wizard once. Still, a very nasty bug! –  Jan 02 '13 at 10:58
  • @BartRamharter I've changed backup strategy completely so this isn't an issue for me any more (and can't test easily test any answers that are now provided). I've added a bounty in the hope someone might know the answer. Please let me know if any posted solutions resolve the problem for you, so I can reward the bounty to anyone finding the answer. – Bryan Jan 02 '13 at 18:01

7 Answers7

7

I don't think there is a way to do this reliably with built-in Windows tools. However, BackupAssist allows you to use multiple USB disks with Windows Server Backup in the same way that one might use multiple tapes, e.g. for rotating offsite backups. It also will automatically "safely remove" USB disks when a backup job is complete, so that the person responsible for taking the USB disks offsite doesn't need administrative access to the server.

Skyhawk
  • 14,149
  • 3
  • 52
  • 95
  • I suspect that you are correct, I don't believe that there is a way of getting round this with the natively. I've ended up completely changing our backup process due to lack of finding a fix/workaround for this issue. – Bryan Jan 10 '13 at 11:04
3

I'm rather disappointed that I ran into this fairly serious problem 2 years after this question was posted - and this was on a new install of Windows 2012 Essentials with (I think) all updates installed.

Fortunately, a HotFix was released last year: http://support.microsoft.com/kb/2833738

This worked for me. I was able to add a new disk to backup with the command:

WBADMIN ENABLE BACKUP -addtarget:{DISKGUID}

Before installing the HotFix, I was getting the "The system cannot find the path specified." error.

Leonard
  • 65
  • 7
1

Use a PowerShell script to run WBADMIN as an alternative to creating a backup schedule with the Windows Server Backup GUI. You can use Windows Task Scheduler to run your script. There is no functional difference between a backup created from a script or command line using the WBADMIN command and those created by the GUI-generated backups.

Here is a PowerShell 3.0 script I use to create backups using WBADMIN on Server 2012. It searches for backup target disks using their volume GUID as I usually don't assign drive letters to my backup drives:

# Configuration
$BackupTargetDiskGUID_A = "\\?\Volume{c61d486a-c007-4070-a5a0-24924fe735f6}\"
$BackupTargetDiskGUID_B = "\\?\Volume{e0a09f69-3be6-11e4-942b-001e676ec6a8}\"
$BackupTargetDiskGUID_C = "\\?\Volume{4bb968a7-93f6-11e2-918e-001e6725c7e0}\"


# Get the Disk GUIDs (DeviceID) of all attached volumes.
# Step through all attached volumes.
$TargetDiskGUID = $null
:VolumeForeachLoop foreach ($Volume in Get-WmiObject -Class Win32_Volume | Where-Object {$_.DeviceID -like "\\?\*"})
{
    # Match the first backup disk
    Switch ($Volume.DeviceID)
    {
        $BackupTargetDiskGUID_A
        {
            $TargetDiskGUID = $Volume.DeviceID
            break VolumeForeachLoop
        }

        $BackupTargetDiskGUID_B
        {
            $TargetDiskGUID = $Volume.DeviceID
            break VolumeForeachLoop
        }

        $BackupTargetDiskGUID_C
        {
            $TargetDiskGUID = $Volume.DeviceID
            break VolumeForeachLoop
        }


    }
}


If ($TargetDiskGUID)
{

    # Run the backup
    # The -include and -exclude switches accept comma delimited paths individually inclosed in quotes without trailing backslashes
    wbadmin start backup -backuptarget:$TargetDiskGUID -quiet -vssCopy -allCritical -systemState --% -include:"D:" -exclude:"D:\Non-Backed Up Data"
}
Else
{
    "No backup disk found."
}

The WSB GUI creates a special backup policy, which once created, demands that backup targets be added to the policy before a scheduled backup will be written to said drive. Unfortunately, Windows Server Backup as exposed through the GUI is completely broken in Server 2012. Unless you have all backup destination drives connected to the machine*, you cannot do the following:

  1. Add backup target disk
  2. Remove a backup target disk
  3. Modify the backup selections (!)

Unless Microsoft fixes this, scripting WBADMIN in my opinion is the only way to continue using WSB on Server 2012.

*Murphy's Law also states this is the best time for a building fire since the source data and all backups are in the same place at the same time.

I say Reinstate Monica
  • 3,100
  • 7
  • 23
  • 51
-1

You have to eliminate the variable of the drives being quietly rejected for being detected as removable media.

Windows Backup for all of its age is constrained with virtues from the mid 1990's, it doesn't like target drives smaller than 1GB and by default refuses to backup images of the %systemdrive% (C:) to removable media. Windows schizophrenically treats removable media with disdain and acceptance and fails to properly log the reasons. You can install Windows even before Windows 8 onto USB media but try to perform particular functions such as Windows Update or windows Backup and other mechanisms rejects itself the way a body can reject a transplanted organ.

The removable drives would benefit from the XPEFilterDriver, it is an implementation of the Hitachi CompactFlash driver for those old mini hard drives that were actually shrunk down into a type II CF card and even made little grinding sounds, the drivers inf file is modified with your removable drives bus and device identifier then substituted as the driver. The XP community realized this years ago after CF cards had grown in size and speed (300x at a minimum is recommended since it seems to perform comparably to a 7,200 RPM EIDE drive) and started lego'ing decent cards into things like the [Addonics CF/SATA adapters][1] and you could build an SSD for a fraction of the cost SSD's used to cost.

Windows is terrible about accurately reporting removable device errors since it handles them scizohphrenically, I mean that officially and until Windows 8 or unless you installed an XPe server and adopted all the constraints of it, Microsoft rejected the idea of installing traditional fat, professional or ultimate version of any windows on USB despite the communities proof of concept and evidence of increased performance but they weren't adequately preventing it from being done since setup.exe would still succeed on installing and booting. But other features such as using it as a backup drive, or even the basic ability use disk manager to just format it as USB were patently rejected, things like successfully using Windows Update would fail without adequate error reporting (but went away if the same build and installation ghosted to a traditional hard drive detected as a fixed disk) because of some ambiguous programmatic rejection of removable media.

The steps are straightforward and "The Island" of hosts that offer the XPEfilter can seem to move, I'm not implying this is "rapidshareware" or piratebay stuff, hardly, but there is a compact and often sub 500kb zip file called "XPEFilterDriver" and "HitachiMicrofilter" that is pervasive across the web and has a cfadisk.sys and cfadisk.inf file.

Hopefully, and it seems likely, that you've already done something like this before and if you're a 2012 server box buster I bet you've had to with the drivers from Microsoft's update catalog when installing "unsupported drivers" that seem to work just fine and dandy anyway.

Obtain it and use any of the instructions from any of the sites you prefer but they'll all tell you to copy your current removable media's device ID and insert into the drivers line of the inf file ( I'm not a spot capable of just demoing this for you but it won't do too much good since the device entry is unique to every USB disk and yours will be different than mine).

From device manager (devmgmgt.msc) and after the USB drive has been inserted because its just easier but not absolutely necessary if you know how to do this directly from the registry

locate the removable drive and upgrade the driver and select the Have a disk options, locate your modified cfadisk.inf file, (you're allowed to consolidate all of your USB drives into one INF file) and select the list of disks displayed after choosing your customized INF.

Accept the warnings about lack of signing and unknown and all that, those are the same warnings presented when I install Windows 8 or server 2012 drivers from Microsoft's update catalog web site.

Since these are removable USB drives, you won't have to reboot despite the warnings to do so, but you might have to safely eject the hardware and reinsert to see the driver go into effect. Sometimes I've succeeded by just stopping the disk from device manager and re-enabling it but not always and I wish I could differentiate the success rate based on manufacturer, type or version of Windows but it seems uncertain which drives will successfully reload the new driver without being removed.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
-1

I have a feeling that the GUID changes after formatting.

You could therefore run wbadmin get disks again after formatting and then run WBADMIN ENABLE BACKUP -addtarget:"{DISKGUID}" again..

shouldbeq931
  • 509
  • 4
  • 15
-1

I ran into this. 2 options:

  1. attach all of your backup disks to the server and then run the scheduling wizard.
  2. change the drive letter of the desired external drive once attached.
Grant
  • 17,671
  • 14
  • 69
  • 101
-1

This solution arrives a bit late, but hopefully anyone searching can use this.

This solution is quite simple and it worked for me.

Given that you have now got a volume with no letter but with a label of something like SERVER_2013_10_11 12:34 Disk_02 (after trying and failing to add a volume via the gui or command line) just

  • open the Disk manager tool
  • Assign a letter to the volume (lets say its D:)
  • This will mean that you can see it from the OS once again.
  • From the command line do WBADMIN ENABLE BACKUP -addtarget:D:

it won't reformat the disk but should include it and, hopefully, just work on the next pass.

Ian Murphy
  • 1,329
  • 4
  • 19
  • 29
  • The problem with doing -addTarget:D: is that you're telling windows backup to use a folder (which might as well be a network path) as a destination. You can't mix that with the whole-disk style of destination. WBADMIN warns of exactly this and says if you proceed it will delete destinations of other types. Otherwise a great answer. – Ian Yates Nov 18 '13 at 05:56
  • I've only used this option in cases were I just cannot convince wb to use the disks it should use. I've seen this in a couple of cases and, after much work, I've given up in each case and just programmed a job to backup to d:\. Its not how it should be, but given the choice between no backup and something.... – Ian Murphy Nov 19 '13 at 12:06