TRY NOW
book meeting
BACK TO KB LIST

How to Identify and Repair Files That Cannot Be Opened After Restore

KB ID: 4874
Product: Veeam Backup for Microsoft 365 | 8
Published: 2026-06-29
Last Modified: 2026-09-17
mailbox
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

Cheers for trusting us with the spot in your mailbox!

Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest

error icon

Oops! Something went wrong.

Please, try again later.

Updated for Veeam Backup for Microsoft 365 8.6

This article has been updated to document new Integrity Check capabilities included with Veeam Backup for Microsoft 365 8.6. The integrity check can now process JET-based repositories and immutable repositories.

Customers who ran an Integrity Check while running Veeam Backup for Microsoft 365 8.5, are advised to upgrade to version 8.6 and run the Integrity Check again.

Purpose

This article provides steps to identify and repair SharePoint, OneDrive, Teams files, and list attachments that were backed up with corrupted content due to the issue described in KB4835.

Solution

Before You Begin

Ensure you’re running Veeam Backup for Microsoft 365 version 8.5 or later before proceeding.

When the Integrity Check is performed on an object storage repository, there will be a temporary increase in the number of API calls the storage system handles while previously written files are scanned for inconsistencies. The redownloading of affected files afterward also increases storage usage on that same repository.

Repair Procedure

The following steps are to be completed for each repository that contains SharePoint, OneDrive, and Teams files. The steps in this section use PowerShell commands that reference variables defined in one step and used in later steps, so all 5 steps should be completed sequentially for each repository.

  • In Veeam Backup for Microsoft 365 8.5, this procedure only supports non-immutable object storage repositories.
  • In version 8.6 and later, support for immutable object storage repositories and JET-based repositories was added.
Step 1: Run an Integrity Check
  1. Open Veeam Backup for Microsoft 365.
  2. In the main menu ( ☰ ), expand Console, and select PowerShell.
    Note: Launching PowerShell from outside Veeam Backup for Microsoft 365 may require manual loading of PowerShell modules.
  3. In the PowerShell console, run the following command to import the module used by this article:
    This DLL module must be loaded directly to ensure the Start-VBORepositoryRepairSession cmdlet is available.
Import-Module "C:\Program Files\Veeam\Backup365\Veeam.Archiver.PowerShell.dll"
  1. Run the following cmdlet for the repository being investigated:
$repository = Get-VBORepository -Name "Repository Name"
Test-VBORepository -Repository $repository
Step 2: Review the Results

If the Test-VBORepository output contains any of the following messages, proceed to Step 3:

For Veeam Backup for Microsoft 365 8.5

The following site has corrupted file data

The following list contains items referencing corrupted files

For Veeam Backup for Microsoft 365 8.6

The following site has inconsistent file data

The following list contains items referencing inconsistent files

WARNING: The following list contains items that reference files with incomplete downloads
 
 
  • If no messages appear, no further action is required for that repository.
  • If you see messages other than those listed above, please contact Veeam Technical Support for assistance in investigating further.
Step 3: Scan Repository and Flag Affected Items

Run the following cmdlet to scan the repository and flag the affected items for re-backup. Their correct content will be redownloaded during the next backup job run in Step 4. Note that during scanning, the repository remains locked for any other operations, including backups, restores, and management. All backup and restore sessions related to this repository must be stopped before running a repair session.

  • For an object storage repository:
$session = Start-VBORepositoryRepairSession -Repository $repository -Type CleanMissingFilesData -Mode Full -Scope Full
  • For a JET-based repository (Veeam Backup for Microsoft 365 8.6+ Only):
$session = Start-VBORepositoryRepairSession -Repository $repository -Type CleanMissingFilesData -Mode Full
  • To limit the scope to a specific SharePoint site, use the -WebIds parameter:
$session = Start-VBORepositoryRepairSession -Repository $repository -Type CleanMissingFilesData -Mode Full -WebIds '{InternalWebId}','{InternalWebId}'
Wait for the session to complete before proceeding to Step 4. To verify that a session has completed, check its status using the session object returned in Step 3: 
Get-VBORepositoryRepairSession -Id $session.Id
Step 4: Run Backup Jobs

After the repair session has finished, run the backup jobs containing impacted SharePoint, OneDrive, and Teams files data. Files that are still present in production will be redownloaded with their correct content.

Step 5: Review Outcome and Identify Unrecoverable Files

To identify files that could not be redownloaded in Step 4, run the following cmdlet:

Test-VBORepository -Repository $repository -DetailedOutput

The output will be saved to logs located in: C:\ProgramData\Veeam\Backup365\Logs\IntegrityVerification\

Files that could not be redownloaded will have log entries containing both of the following. The first message varies by object type:

File preview has empty content length
Item has empty content length
Attachment has empty content length

repair history: FileWasReset

Error line example for an object storage repository:

  • [Info] File preview has empty content length (repository ID: {repo-guid}, organization: {tenant}.onmicrosoft.com, web: OrganizationId: {orgGuid}, SiteId: {siteID-guid}, WebId: {webID-guid}, InternalWebId: {intwebID-guid}, web URL: /sites/example, list ID: {listID-guid}, item ID: {itemID-guid}, item title: example item, file name: example.png, file ref: /sites/example/Lists/example/2_.000, file ID: {fileID-guid}, file version: 2, OneDrive: False, file size: 8675309, from: mm/dd/yyyy hh:mm:ss PM, to: mm/dd/yyyy hh:mm:ss AM, data loss type: AllVersionsLost, repair history: FileWasReset)

Error line examples for a JET-based repository:

  • [Info] Item has empty content length (repository ID: {repo-guid}, site ID: {siteID-guid}, web ID: {webID-guid}, list ID: {listID-guid}, item ID: {itemID-guid}, version: 4, repair history: FileWasReset, file URL: /sites/example.pdf, file reference: /sites/example.pdf)

  • [Info] Attachment has empty content length (repository ID: {repo-guid}, site ID: {siteID-guid}, web ID: {webID-guid}, list ID: {listID-guid}, item ID: {itemID-guid}, file ID: {fileID-guid}, file version: 2, repair history: FileWasReset, file URL: /sites/example.pdf, item file reference: /sites/example/Lists/example/2_.000)

To simplify this process, open the log files in Notepad++ and use the following regex search:

^(?=.*has empty content length)(?=.*repair history: FileWasReset).*$

Repairing Backup Copies

Test-VBORepository cannot be run against a repository that serves as the target of a backup copy job. If inconsistent files were copied to such a repository before they were repaired, scan and fix the source repository first, following Steps 1 through 4 above.

In Veeam Backup for Microsoft 365 8.6* and later, once inconsistent files have been repaired in the source repository, no manual action is required to repair them in the backup copy target repository. On the next scheduled run of the backup copy job, the job automatically detects that the source backup contains repaired files, re-reads those files from the source repository, and re-copies them to the target repository. Every file repaired in the source repository is copied, and only those files are copied. The job does not perform a full resync of unaffected data, and each repaired file is copied once.

Note: The detailed report described in Step 5 is not available for a backup copy target repository. Verify the outcome against the source repository instead.

*The automatic triggering of the Backup Copy to repair files on its destination storage that were redownloaded on the primary backup storage will only occur if the Integrity Check was performed using version 8.6 or newer. If an Integrity Check was run using Veeam Backup for Microsoft 365 v8.5, after upgrading to version 8.6, the backup copy must be manually triggered to repair its destination files:

$job = Get-VBOJob -Name "Backup Job Name"
$copyJob = Get-VBOCopyJob -BackupJob $job
Start-VBOCopyJob -Job $copyJob -Full -SharePointData

More Information

For the description of the root cause, see KB4835: Potential Issue With Backing up SharePoint, OneDrive, Teams Files, and List Attachments.

If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case.

To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

Thank you!

Thank you!

Your feedback has been received and will be reviewed.

Oops! Something went wrong.

Please, try again later.

You have selected too large block!

Please try select less.

KB Feedback/Suggestion

This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Start using Veeam:
Download the product
&
Activate the license key
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please, try again later.