Before writing this post, I’ve been working with support for several weeks regarding an error that didn’t occur in V7. Case #07440112.
Supposedly, this issue occurs when trying to process an item larger than 512 MB. Support has suggested reducing the number of items per batch and adjusting the BatchMaxItemSize. However, when reviewing the proxy startup logs, I noticed another key, BatchMaxSaveItemSize, which sets the maximum size to 256 MB.Processing archive mailbox XXX@XXX failed with error: Mail item data export failed. Error in deserializing body of reply message for operation 'ExportItems'. There is an error in XML document (1, 54789806). The token '"' was expected but found '<'. Line 1, position 54789806. :: 0:06:55
Reducing the number of items per request increases the total number of global requests for backup, which causes us to more quickly hit the organizational limitations of Microsoft APIs.
This case has been open since September 27 without a resolution, and it is affecting multiple clients who had no issues previously. The problem is no longer minor—customers are beginning to lose trust in Veeam and in us as their Office 365 backup providers.
There’s no SLA or document to reference for this issue. Previously, customers would occasionally check if their Veeam backup was working, trusting that the solution functioned consistently. Now, they check every morning at 7 AM, only to complain about repeated failures, as if we, the providers, aren't trying to fix the issue.
To avoid more serious issues with clients, we’ve had to separate the users experiencing these errors into work tasks, which we label as “Backup Errors.” This at least allows the client to see more green than red on their console.
As a service provider, I would like to request that the R&D team provide a list of known bugs in version V8 and indicate which ones are actively being worked on. I also suggest publishing this information, at the very least, in the service provider forum.