Multiple USB backup targets with Windows Server Backup

Question

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.

Solution 1

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.

Solution 2

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.

Solution 3

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.}

Comments

[Admin]

@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.

[Kcmamu]

Thanks for the idea, however unfortunately this won't help, as the problem occurs without any reformatting of drives.

[Kcmamu]

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.

[Ian Yates]

You're right - the GUID does change. But it didn't help me either.

[Ian Yates]

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 Murphy]

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....