Configuration:
Windows Server 2012 R2
Running as a domain controller
Backing up to 2 external hard drives attached via eSATA
External hard drives are encrypted using BitLocker
Windows Server Backup is configured to backup to both drives as volumes.

Error:
Both drives must be attached to the server on boot.  If they aren't, errors ensue.

When opening the Windows Server Backup GUI the following message is displayed:

A fatal error occurred during a Windows Server Backup snap-in (Wbadmin.msc) operation.
Error details: The Windows Server Backup service has stopped..
Close Wbadmin.msc and then restart it.

In the Event Viewer, there is an Application error with Event ID 1000:

Faulting application name: wbengine.exe, version: 6.3.9600.17415, time stamp: 0x54504543
Faulting module name: wbengine.exe, version: 6.3.9600.17415, time stamp: 0x54504543
Exception code: 0xc0000005
Fault offset: 0x000000000011e4d7
Faulting process id: 0x1308
Faulting application start time: 0x01d08451e1f1960b
Faulting application path: C:\Windows\system32\wbengine.exe
Faulting module path: C:\Windows\system32\wbengine.exe
Report Id: 257ca2e7-f045-11e4-80d2-001e67c53a63
Faulting package full name:
Faulting package-relative application ID

Attaching both drives does not fix the problem, but rebooting after both drives are attached does fix it.  If both drives are attached on boot, one can be removed and Windows Server Backup will function correctly until the next boot.  This leads me to believe that Windows Server Backup is looking for both drive on boot and failing in some way if they are not available.  The desire is to rotate one drive offsite for disaster recovery, so having both attached on every boot is undesirable.  Windows Server Backup works with this configuration without problem on Windows Server 2008 R2 and Windows Server 2012.

Deleting the catalog using "wbadmin delete catalog" and then recreating the backup schedule did not help.  Is there anything obvious that I'm missing?

• Edited by Stoutner Friday, May 01, 2015 9:50 PM

Log boot(set in F8 menu) to find which process is causing troubles. However I would restart server with devices that the server needs/asks.

Rgds

Milos

As far as I can tell, the problem is with the wbadmin process itself, which has been programmed to not run if it cannot see all the backup drives it is programmed to use.  This is a change from previous behavior in Windows Server 2008 R2 and Windows Server 2012, where wbadmin only needs to have both drives attached during setup and then is fine with only one drive attached at a time.  In other words, this is a regression (bug) in wbadmin.

So after a bunch of troubleshooting, I believe I have discovered the underlying cause of the behavior and a workaround.  The following description is my assumption of how wbadmin works based on observed behavior.

When a new backup schedule is created, all the backup drives must be attached.  There are differences in how the backup schedule is created based on whether the drives are attached via eSATA or USB.  The system expects eSATA drives to always be attached on boot and produces an error if they are not.  It does not expect USB drives to be attached at boot.

If both external backup drives are attached via eSATA during setup, the system will expect to see both drives at every boot.  If one drive is attached via eSATA and the other via USB, the system will expect to see an eSATA drive at every boot, but doesn't care whether the USB drive is attached or not.

Wbadmin doesn't actually mark an individual drive as eSATA or USB, so it doesn't matter which one is connected to which.  All it knows is that it is expecting one eSATA and one USB.  If both drives are setup as USB and then one is latter connected via eSATA when the system boots, wbadmin will produce an error, because internally it says, "both of my backup drives are USB, so I don't care if they are attached at boot, but now I see that one of them is eSATA, so I think I will just throw an error."

This problem had never manifested to me before because all my previous servers have had only one eSATA port, so setup always necessitated one of the drives being attached via USB on initial setup.

This behavior is completely undocumented, and highly undesirable.  But once you know the rules, it is pretty easy to work around.

• Marked as answer by Stoutner 10 hours 18 minutes ago