Error: uploaded but the returned size was 0

Support
1

Backup is taking weeks. It will backup several MBs and then fail with:

Blockquote
(Inner Exception #0) Duplicati.Library.Interface.UserInformationException: The file duplicati-i4319c9a9bb1040e3b245aaea7ccc643f.dindex.zip.aes was uploaded but the returned size was 0 and it was expected to be 40957 at Duplicati.Library.Main.Operation.Common.BackendHandler.

Blockquote
(Inner Exception #1) System.AggregateException: One or more errors occurred. —> Duplicati.Library.Interface.UserInformationException: The file duplicati-i4319c9a9bb1040e3b245aaea7ccc643f.dindex.zip.aes was uploaded but the returned size was 0 and it was expected to be 40957 at Duplicati.Library.Main.Operation.Common.BackendHandler.d__21`1.MoveNext()

Using Duplicati - 2.0.4.5_beta_2018-11-28 on Windows 7.
Backing up to offsite FileZilla server via FTPS.

Let me know if more of the log would be helpful in determining the cause of the error.

The file changes each time, but the error about returning size was zero remains the same.

When I FTP onto the FileZilla server, the file in question is there and appears to be the proper size. FileZilla appears to be reporting the wrong file size back to Duplicati. Could directory caching in FileZilla be causing this or does the file size request override any caching? Maybe Duplicati is not giving FileZilla enough time to update the file size?

Would a different destination type be better than FTPS?
Would a different FTP server be better than FileZilla?

Thanks,
Scott

2

Hello @beans and welcome to the forum!

Looking over and maybe posting FileZilla Server logs would show timing of operations, if that’s a suspect.

Is this FTP or FTP (Alternative)? Can you manage to switch the FTPS to the other? I can’t give directions. Although the main backup doesn’t sound healthy, you could do this testing on a test backup to avoid risks.

Can you recreate this with FTP (not FTPS) in a safe environment? Don’t FTP over Internet – it’s insecure.

The exact error message would probably be avoided because it looks like it’s specific to the FTP protocol, which does a verify after upload by default. You can test with the below, but I’d be nervous about leaving it on until there’s a better understanding of the problem. Turning off safeguards isn’t always an improvement.

--disable-upload-verify
To protect against network failures, every upload will be attempted verified. Use this option to disable this verification to make the upload faster but less reliable.

3

Thanks for your help with this. I ended up getting past it when I switched to “FTP” instead of “FTP Alternative”. I never got around to researching the cause of the errors.

Thanks.