WBAdmin BMR backup says "There is not enough free space on the backup storage location to back up the data."

We're doing nightly BMR backups of a small 2012 R2 Hyper-V host via wbadmin to 2TB USB disks, via
  wbadmin start backup -backupTarget:z: -quiet -noverify -vssFull -include:e:,c: -allCritical
(where E: contains the sole VM).

We are using the same backup system on other similar Hyper-V hosts running 2008 R2 and 2012, with no problems. However, with this 2012 R2 host, after a few months of no problems the backups started failing with:
  There is not enough free space on the backup storage location to back up the data.

This made no sense, and continues to make no sense:

• The 2TB backup disks are only half full (>1TB free), with 600GB of unallocated shadowstorage.
• There should be room for many more backups on these disks. Each currently contains 11 to 13 backups, with the initial full backup having required about 600GB and each subsequent backup only requiring another 20GB to 40GB.
• There is over 40GB free on the C: drive and 300GB free on the E: drive; free space on the host volumes is not an issue.
• Increasing the shadowstorage limit on the backup disks to unbounded doesn't resolve the issue.
• This is not a problem of a RECOVERY partition that's too small, and SystemState backups always complete successfully.

The first workaround we found was to temporarily reduce (not increase) the shadowstorage allocation on the E: drive (containing the VM) and then increase it back (with the end result of deleting old shadow copies).

This worked reliably, but looking for a root cause led us to uninstall the Windows Updates installed mid-September (in particular the Aug 2014 and Sep 2014 roll-ups), which preceded the start of this problem. But instead of resolving the problem the uninstalls made it worse, in that our workaround stopped working.

We reinstalled the Windows Updates, and then tried setting backup performance to normal, in case the problem was related to VSS on the host volumes, but the errors continued.

At this point the only way we've found to work around the error is to delete 1 or 2 of the oldest backups on the destination disk, via
  wbadmin delete backup -backupTarget:z: -deleteOldest
after which the new backup will succeed.

But, again, this makes no sense, as the destination disks are only half full, and even if space was an issue wbadmin should delete old backups as required. And this same system is working fine on 2008 R2 and 2012.

Any suggestions?

Thanks,

John