KB4835

[Bubblebop]

Craziest thing I have experienced, we figured this out randomly yesterday.

Colleague had moved 1 TB of data but then in the backup report saw only a few MB and a Success message...

0 notifications from veeam, i had to manually find kb4835.

I have notification for kb4869 yesterday and KB4821 in february.

Hope this fix is not Soon™, does the managers know?

I made a forum account just to post this

[Polina]

Hi Bubble Bop,

Could you please elaborate which data have you moved, how and where? Cause it's not entirely clear atm how it is related to the issue from KB4835.

We have sent email notifications on KB4835 to all customers quite a while ago. If you didn't receive it, we can check if the issue is on our side so that it never happened again.

Thanks!

[Bubblebop]

Hi,

My colleague transferred from the customer's on-prem SMB to SharePoint.

He tested if the new sites were actually being backed up.

We hadn't updated 8.4 before that job , and veeam365 now thinks we have all the data.

As for the email notification, this is a 'me-too', since I see others in the thread complaining about the same thing.

[Bubblebop]

I know there are a lot of smart people at Veeam, smarter than me. I've used and sold it since Veeam Backup 2.0.

I think we can tackle this the same way as Crypto Virus; the files have a signature "Sorry, something went wrong", HTML content in non-HTML files is easy to identify and fix.

Then you can scan all new files created in 2026 to reassure everyone.

My own OneDrive files are also corrupted, including the veeam365-usage report over several months.

[Polina]

I'm afraid verification is a bit more complex than that, not to mention fixing the corrupted data.

[Polina]

@Bubblebop

A quickly checked if any contacts from your company were among the recepients of our email communication on KB4835, and found that Case Admin of your account should received our email from April 8th. Other accounts that we used to have on the mailing list unsubscribed from our communications before these communications were sent. If needed, I can share with you emails in DM to verify if those are the correct ones.

I'm sorry for this inconvence and suggest you subscribe to notifications on our KB updates.

[Bubblebop]

Yes, please share in DM

[Bubblebop]

Thanks. Both addresses received the email notice on April 8, and version 8.4 became available on April 27.

The first address doesn’t have the technical ability to notify the rest of us, since it belongs to a license seller. The second address, however, should have been able to act on the notification.

My own address did receive the other notifications, though, and I have not unsubscribed from anything.

Is subscribing to “Get weekly article updates” on the KB the correct way to receive all important updates like this, or is there another recommended notification channel? If possible, could you clarify this for me and for others who may have the same question?

Hope you guys are making progress with the fix

[b.vanhaastrecht]

I only became aware of this issue this week when a customer was unable to restore critical files. Frankly, I'm astonished by the timeline.

The issue has been known since March. A fix for newly created or modified files was released on April 16th, which seems reasonable. What I struggle to understand is why it has now taken more than three months to address the corruption affecting existing, unchanged files during restore operations.

Backup software exists for one primary reason: to ensure that data can be restored when needed. Customers trust Veeam with their business-critical data and pay for that assurance. Given the severity of this issue, it's difficult to understand why there is still no fix available and why support is unable to provide any estimated release date.

Can Veeam provide more transparency on the status of the permanent fix and the expected timeline?

[b.vanhaastrecht]

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.

This statement is incorrect. From what support has told me, after installing 8.4 only Changed or Created files will be healthy, non touched files remain corrupted after restore.

[Polina]

The fix delivered in 8.4 is considered permanent.
Remediating the consequences of the issue requires a separate mechanism which is being worked on as we speak. The first phase of it will cover object storage repositories with regular backups. I cannot provide the timeline, but expect to get it delivered soon.

[msobm]

It‘s unbelievable how long it takes for Veeam to get a solution for already corrupted data. That should be one of the highest priority. I don‘t get how that could take (more than) 3 months for such a big company with that much of possible ressources.

[Polina]

v8.5 which includes the ability to verify object storage repositories is now available for download.
See more in the Release Information KB: https://www.veeam.com/kb4873

[FJGyCKCx4d]

The kb say only to non-immutable Object Storage but in the future it will also work on Immutable Object Stockage ? can I run the test commande to see if my repository are affected ?

[Polina]

With 8.5, you can check if any data in non-immutable object storage repositories is impacted.

[flavio.santos]

Did anyone applied the new version? My first test went bad, old backup still corrupted.
Is there any special task to do?

[b.vanhaastrecht]

v8.5 which includes the ability to verify object storage repositories is now available for download.

Whats the fix ETA for JET-based ones?

[Polina]

@flavio.santos Installing the build is not enough - you need to take actions described https://www.veeam.com/kb4874

@b.vanhaastrecht I expect closer to the end of this month.

[aeph]

@Polina all our S3-Repos are using 14 days of immutable retention + 1-5 years of "normal" retention. Does this mean i cannot use the Test-Tool and the Repair-Session for all of them?

If not, when to expect a solution for S3-Repos WITH immutability?

[renatorichina]

Hi

In KB4874 it's mentioned, that the repair script only works with object-storage based Repos and that for JET-based one, this will be provided in "a future update". Could you clarify "future", do we speak about day, weeks, months? Our own installation of VBM365 and all our customers installations are JET-Based. According to my personal opinion, this is a quite critical problem, when some files potentially didn't backup successfully in the past. And I would really appreciate to have a Test/Fix cmdlt asap for JET-based repos.

Thanks
Renato

[Mildur]

Hi Renato,

I moved your question to the existing topic, where Polina already answered: "I expect closer to the end of this month."

Best,
Fabian

[flavio.santos]

Hello @Polina, thanks for sending that KB to me. I did that, and it worked. Thanks a lot.

Is there any script to automate that part? We have 10 VBO sites, with an average of 600 repositories on each.

Thanks!

Flavio

[jasonede]

I'm working through this now and suspect that an automation script would be possible for the scanning and fixing at least. I might try and put something together here as we've quite a few repos to work through.

[Polina]

Hi All,

@aeph Commandlets provided in v8.5 cannot be used for repositories with your settings indeed. Verification of immutable repositories is ready testing, but I cannot estimate at this point how long it would take.

@flavio.santos Such scripts are always a community effort - hopefully your peers will share their automation options here )

[jasonede]

Working through the steps in https://www.veeam.com/kb4874 and at step 5 it sort of just ends. If those messages are found does it mean that the items have since been deleted and therefore cannot be backed up and are lost for good? It's not very clear.

[Polina]

Hi jasonede,

In step 5, the KB explicitly says "Identify Unrecoverable Files" and "Files that could not be redownloaded will have log entries containing the following two messages". Items found on step 5 cannot be repaired and are lost.

[jasonede]

Running the verification at the end of step 5. I can't find that reg-ex string in the logs, but the command outputs loads of lines in red with format like the below (names and id's masked).
Are these anything to be concerned about or just indicating that it's been backed up and fixed.


Test-VBORepository: File data is corrupted: OrganizationId: 071b3828-XXXX-XXXX-XXXX-XXXXXXXXXXXX, SiteId: 6da1eea0-XXXX-XXXX-XXXX-XXXXXXXXXXXX, WebId: b46e8173-XXXX-XXXX-XXXX-XXXXXXXXXXXX, InternalWebId: e3ee0bbd-XXXX-XXXX-XXXX-XXXXXXXXXXXX (file Id: 089f195c-XXXX-XXXX-XXXX-XXXXXXXXXXXX, Version: 0, ContentLength: 66048, BytesInStorage: 66048, StorageType:FileData, RepairHistory: FileWasReset).
Test-VBORepository: File data is corrupted: OrganizationId: 071b3828-XXXX-XXXX-XXXX-XXXXXXXXXXXX, SiteId: 6da1eea0-XXXX-XXXX-XXXX-XXXXXXXXXXXX, WebId: b46e8173-XXXX-XXXX-XXXX-XXXXXXXXXXXX, InternalWebId: e3ee0bbd-XXXX-XXXX-XXXX-XXXXXXXXXXXX (file Id: a43ae6d8-XXXX-XXXX-XXXX-XXXXXXXXXXXX, Version: 0, ContentLength: 101376, BytesInStorage: 101376, StorageType:FileData, RepairHistory: FileWasReset).
Test-VBORepository: The following list contains items referencing corrupted files: /personal/user1_contoso_com/Documents (OrganizationId: 071b3828-XXXX-XXXX-XXXX-XXXXXXXXXXXX, SiteId: 6da1eea0-XXXX-XXXX-XXXX-XXXXXXXXXXXX, WebId: b46e8173-XXXX-XXXX-XXXX-XXXXXXXXXXXX, InternalWebId: e3ee0bbd-XXXX-XXXX-XXXX-XXXXXXXXXXXX, list ID: 60f5fff2-XXXX-XXXX-XXXX-XXXXXXXXXXXX, count: 4).
Test-VBORepository: The following site has corrupted file data: https://contoso-my.sharepoint.com/perso ... ontoso_com (OrganizationId: 071b3828-XXXX-XXXX-XXXX-XXXXXXXXXXXX, SiteId: c5f8c3d8-XXXX-XXXX-XXXX-XXXXXXXXXXXX, WebId: 9bada29f-XXXX-XXXX-XXXX-XXXXXXXXXXXX, InternalWebId: 0d276285-XXXX-XXXX-XXXX-XXXXXXXXXXXX, count: 3).

[admd]

Hello,

I wasn't sure to create another topic or not.

I got this output for Step 1 for one customer and on Step 5 for another after repairing the repo.
I think it's good ?

PS C:\Users\XXX> Test-VBORepository -Repository $repository -DetailedOutput
Verifying repository: REPO-S3-XXX...
Test-VBORepository: Duplicate web restore points found in object storage.

Thanks !

[Bubblebop]

Hi,

I've completed all my spot checks, and everything looks OK on my side. I'm currently on step 5 as well.

I do see the red error text in PowerShell as described, but no logs are being generated. To rule out a missing folder issue, I manually created the IntegrityVerification directory, but that did not change the behavior.

To verify whether any new log files were being created, I ran the following command to list files modified after 16:00 on July 3, 2026:

Get-ChildItem -Recurse -Path "C:\ProgramData\Veeam\Backup365\Logs\" -Filter *.* | Where-Object { $_.LastWriteTime -ge (Get-Date "2026-07-03 16:00:00") }

The only files returned were: C:\ProgramData\Veeam\Backup365\Logs\PowerShell\Veeam.Archiver.PowerShell_*

I could not find any Integrity Verification logs being generated.

Please let me know if there are any additional diagnostics I can collect or other log locations I should check.

Best regards

[Bubblebop]

Hey, just thought of it in the car on the way home, the files are on the proxy. As they were More work on Monday.