KB4835

[lmendel]

Just learned about this browsing Reddit:

From https://www.veeam.com/kb4835

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?

[raftbone]

Thanks for posting... Wasn't yet aware of this too.

I'm interested too if their is a way to identify files which are affected...

[Polina]

Hi all,

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.

[huddie]

Thanks @Polina,

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.

[raftbone]

Hi all,

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.

Any update on the release of this fix?

[Polina]

Hi raftbone,

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.

[lmendel]

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.

[raftbone]

Version 8.4 is just released.
https://www.veeam.com/products/download ... rsion.html

[msobm]

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?

[mrowell]

I submitted this feedback on the KB page:

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.

[Bjoern_ch]

@veeam
Why did you not inform your customers directly (via email) about this?
How can affected data be identified?
How can corrupted data be fixed?

[juerg.hirschi]

+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.

[MILJW002]

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.

[Mike Resseler]

Hi @juerg.hirschi, @Bjoern_ch

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.

I hope it helps

[Bjoern_ch]

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?

[GHerbstman]

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.

[Bjoern_ch]

@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?

[lmendel]

@Mike Resseler

As a partner/reseller/service provider - we learned about the issue by pure luck, KB came up in reddit results while I was searching for something else, no communication from Veeam whatsoever. Surely this isn't correct way to communicate about issue, regardless of what caused it.

Veeam had a fix on 25/03 then waited a week to quietly 'notify' customers and 'partners' on 31/03 and another 2.5 weeks to provide a fix on 16/04? This is evasive and dishonest, as you have many times stated that you are using the same software as we are. Looks like you care about your own tenants just a little bit more then you care about ours.

[holzhei]

Hi,
Can someone from Veeam confirm in plain English?

After we install the latest patch, is it still possible that some of the files we backed up between the beginning of March and when we installed the patch, are currently corrupt? If this is the case, I feel like the wording on the KB article could be a bit more explicit.

[Polina]

Hi Michael,

The latest v8.4 fixes the root cause of the issue, meaning that all backups created after you upgrade to 8.4 will be healthy. At the same time, it does not fix impacted historical backups - our RND is working on a solution for that.

[msobm]

Any news about how to identify and fix the corrupted backup-files? There is still nothing about that in the KB.

It is nearly 2 months now. Veeam should be working faster on this issue as this could impact production Data when Restores are not working.

[Polina]

We doing the best we can. KB will be updated when the fix is available.

[HolgerE]

Any news about a timeline?
Veeam was able to fix the repositories in Veeam Data Cloud for Microsoft 365 backups some time ago (at least 2 weeks ago) so it shouldn't take long to fix it on Prem.

[Polina]

Hi Holger,

VDC received the same fix for the root cause as VB365 did. Or do you mean any other repository fix?

[bertdhont]

We had an issue with the restore of SharePoint files.
The issue we had is described in KB4835 (https://www.veeam.com/kb4835)

We updated to v8.4, but as stated in the KB, items that were not changed since last backup are still affected:

Affected items in the backups, if any, that have not changed in production since the last backup remain impacted by the issue. Veeam is working on a solution that will allow customers to remediate the impacted items.


I tested by creating a new backup repository, created test-job of the affected site.
Restore of these files is now OK, so indeed.. the issue is resolved in v8.4, but only for NEW backups.

Is there any update on the issue for existing backups?
Is there a workaround available? I was thinking to start the SharePoint backup job from a PowerShell command using the -Full parameter, but I doubt if it will re-download the files. I guess Veeam will only resync, but will see the file (with that version) is already in the repository and thus will skip the file...

[Polina]

Hi Bert,

I moved your post to the existing topic on the matter where you can follow updates.

For the impacted data, there're currently no workarounds. Force full synx will not help either. Soon we will deliver a solution.

Thanks!

[HolgerE]

Hi Holger,

VDC received the same fix for the root cause as VB365 did. Or do you mean any other repository fix?

Hello Polina

I refer to this statement in KB4835:
"Affected items in the backups, if any, that have not changed in production since the last backup remain impacted by the issue. Veeam is working on a solution that will allow customers to remediate the impacted items. This article will be updated when further information is available."

Thanks, Holger

[Polina]

Hi Holger,

This is fixing the root cause and it has already been delivered to both VDC M365 and VB365.

Thanks

[righter]

Any news if Veeam will be publish a fix to detect and repair the fixed files?
We have douzen of customers which we don't know if their backup is healthy. We cannot do a complete 2nd Full Backup on each Tenant..