SharePoint / OneDrive for Business backups – Copied file size bytes differs from source file size

Some people report this “Copied file size bytes differs from source file size” message in SharePoint and OneDrive for Business backups. It’s nothing to worry about, as these skipped files are attempted again on the next backup run. Here’s why it happens.

TL;DR Summary 

  1. This issue typically happens on your first backup, where thousands of files are downloaded. 
  2. This issue is self-correcting in BackupAssist 365. If a file is skipped in your first backup, then the second backup will try it again. 
  3. It occurs because a verification check failed – which we believe is a sporadic bug in Office 365, and not a problem with your data itself. 
  4. We plan on releasing an update which will retry these failed files at the end of the first backup, so the chances of encountering this problem will be minimized. 
  5. If you get the same error repeatedly (the same files cannot be backed up several times in a row) then please contact our Technical Support department by submitting a support ticket, from the ‘Get support’ tab in the software. 

#1 Where can this issue occur? 

This issue happens if you back up SharePoint sites – and because SharePoint is the underlying store for multiple services, then it also includes: 

  • OneDrive for Business user storage accounts 
  • Microsoft Teams Files & Wiki 

Most frequently, it happens on your first full backup. This is because the first backup will download thousands of files. 

#2 How does BackupAssist 365 self-correct this? 

BackupAssist 365 was designed to deal with the unreliability of cloud services. 

Any files that are not backed up in your first backup will be attempted when the next backup runs. This is because BackupAssist 365 performs a differential backup – it compares the data in the cloud to the data in the local backup, and downloads the deltas. 

Sidenote: despite what cloud vendors say, the cloud storage is not as reliable as you might be told, especially compared to a local hard drive.  

For example, if we issue a million requests to cloud storage or local storage, we commonly see: 

  • Zero failures from local storage (unless your hard drive has bad sectors). 
  • Hundreds or thousands of failures on cloud storage – for which we find two main causes: 
    • internal server errors at the cloud storage provider end – including load balancing issues, “temporarily unavailable” issues 
    • internet outages, even if there are only a few seconds of downtime. 

#3 What causes this to happen? 

After downloading each file, BackupAssist 365 performs a “sanity check” to make sure the downloaded file has the same file length as the cloud copy. 

If this sanity check fails, then we mark the file as an error. 

The problem we observe is that sporadically, SharePoint reports the incorrect length of the file in the cloud.  

We can confirm, through meticulous testing, there is no problem with the files on SharePoint themselves, nor is it caused by open files. It is purely a problem where SharePoint reports the incorrect file length. We believe, through speaking to various experts, that this is some kind of error related to rounding. 

#4 What changes are we planning in the software? 

In November 2021, we have seen an increase in users reporting this issue. Previously, something that was a 0.03% occurrence is now as high as 10%. 

Accordingly, we will make enhancements in our next version (v1.9.7) which will automatically put skipped files on a retry list. 

We believe this should dramatically reduce the incidence of this issue. 

We anticipate that v1.9.7 will be released around 30 November 2021. 

#5 What if it keeps on happening? 

To date, we have had zero reports of this problem happening repeatedly, even without the planned retry features. So we believe it’s unlikely to happen to you.  

If the problem persists for you, please submit a support ticket using the ‘Get support’ tab in the BackupAssist 365 administration console. 

Leave a Comment

Share on email
Share on print
Share on facebook
Share on google
Share on twitter
Share on linkedin

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email. Join 1,874 other subscribers