During backup operations, files, list attachments, or images from SharePoint, OneDrive, or Teams were saved with the contents of the HTML error pages returned by the API, rather than their actual file content.
Veeam first observed this issue in early March 2026.
This issue impacts Veeam Data Cloud for Microsoft 365 and all supported versions of Veeam Backup for Microsoft 365. It is independent of repository type, affecting both JET-based and object storage repositories.
No errors are shown in backup jobs or restore tasks; the issue surfaces only when the user attempts to open the restored file.
I'm lost for words.
Is there a way to verify the extent of how many Tenants/Services/Files are affected? Are they backups even usable at this stage?
The issue is observed on some of the files, and otherwise the current backups remain usable.
First hand we are preparting a fix for the root cause - it's now undergoing the last tests. Verification and remediation of the impact (whereas possible) will be a fast-follow.
Btw, you can subscribe for Veeam's KBs updates to get notified once the new content is out.
As others are asking, in the meantime is there any way of determining which backed up documents are impacted ? What's the scope of the problem ? There's no update on https://www.veeam.com/kb4835.
The issue is observed on some of the files, and otherwise the current backups remain usable.
First hand we are preparting a fix for the root cause - it's now undergoing the last tests. Verification and remediation of the impact (whereas possible) will be a fast-follow.
Btw, you can subscribe for Veeam's KBs updates to get notified once the new content is out.
Our immediate priority is fixing the root cause to prevent any further impact. I expect it to be ready within the next few days.
Once that's out, we'll move on to scoping the affected data and assessing what can be remediated — I don't have a timeline for that part yet, but we'll share updates as we go. The KB article will be updated as new information becomes available.
Any updates on the issue? It's been over two weeks since KB was published but Veeam has been very 'evasive' about the issue. I get that issue affects all backup vendors and was caused by Microsoft, but it would be nice to at least know the extent of affected backups.
Are there any details on whether Veeam Backup for Microsoft 365 checks files that were written before version 8.4 was installed?
From what I understand from the KB4835, version 8.4 only prevents the issue from occurring going forward. But what about files that were already saved incorrectly?
Is there any tool or process available that can be run to detect and re-write/repair potentially defective files created prior to version 8.4?
This is a factually incorrect and totally dishonest representation of the issue.
"Backup of SharePoint, OneDrive, and Teams data completes successfully, and subsequent restores of this protected data are successful. "
Neither the original backup was successful nor the restore as the data was simply not backed up.
You could possible get away with saying "Backup of SharePoint, OneDrive, and Teams data are reported as successful and restores are reported as successful, but the data was not backed up and thus is not restorable due to a bug in VBM365."
Ideally Veeam should upfront admit that you failed to backup data due to a coding error instead of hiding in obtuse wording. This is an ongoing theme with Veeam and greatly reduces your standing as a reliable vendor.
Also, the KB should clearly state if the upgrade retrospectively fixes the error or not.
+1
We have currently customers holding back on signing license renewals mentioning this case. "how can we trust Veeam any longer, if they hide behind a KB article instead of activly warning about the situation?"
i dont know what to tell them, apart from agreed, communication disaster.
I understand that there doesn’t appear to be any built-in functionality to get VBM365 to perform a health check or reconciliation, but is there any way to manually trigger one?
As I understand the situation, we currently have a vague period of time where if an item was changed or captured in a backup that data is currently corrupted or lost.
The only options I see are to keep the old backup repositories for a period of time hoping that data before the corruption might be okay, and then doing a new/fresh/seperate backup to try and make sure data is hopefully correct from now.
The issues with variations of this are a mix of a lack of confidence with historical backups and duplication of backup data adding complexity and cost for local and/or object storage.
I don't believe we are hiding behind a KB. We have sent communications to all customers of M365 but this is obviously based on the company contacts that we have. However, it does mean that sometimes our contact information are not the administrators from a customer. The latest version to fix the issue is also available (Release notes on it here: https://www.veeam.com/kb4843).
For the files that (might) have been affected. We do now have solved the root cause. We are working hard on also having a solution in the product that will go over all those files and find affected ones and re-protect those during the next run, as described in the KB. Note that what is affected effectively generated a file for us to download. So we downloaded a file that is not corrupted, but is effectively a web-based type of file, but obviously not the correct one.
Hi Mike,
thanks for weighing in.
Well, looks like many customers are complaining that you have not informed them properly. I receive many mails from veeam but none for this. You have my mail address (as we have a contract) but did not send a mail to me. None of my colleagues received a notification as well!
Your support just told me that you do not inform about issues like this via mail but via KB article...
What do I need to do to make sure that I will receive a email in the future?
I will also say there has been no notification of this significant issue where backups fail significantly. We get weekly Veeam weekly forum updates and we are Veeam partners. We have not seen anything that stood out and alerted us to this issue. We found out when clients backups started failing. We also blame Microsoft here significantly as it seems on a couple tenants they have already disabled EWS for F and kiosk licenses ahead of their announced schedule.
@Mike Resseler
as support told me about the status page I have looked into it. We are an onprem service provider, so there should normally be no need to do that. https://vdcstatus.veeam.com/incidents/0 ... YX0T5PZ6N2
Looks like you informed your vdc customers March20th and deployed a fix March 25th. May I ask why it took 3 more weeks to provide a fix to your onprem customers? I thought vdc is using the same software?