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.