unexpected EOF on backup

Morgan G     Jun 7 12:32AM 2018 CLI

I'm attempting to run a backup from a Macbookpro over to my backup drive on an imac.

This has worked in the past from other machines to this backup drive, but with this mac I keep getting a failure like this, during "listing all chunks":

Failed to list the directory chunks/73/:unexpected EOF

Each time the specific directory where it fails is different. It is not always 73.

I am doing this backup via SFTP, using a special backups user I have created.

Just to be sure, I did a chown of the entire duplicacy folder on the destination drive. I have also checked that I can do a directory listing of the affected directories as this user 'backups'. e.g.:

> ls 73
(no errors raised during extensive listing)

I initially thought it was maybe because one of the systems was going to sleep during a very long listing. So I connected the systems via ethernet, and watched/waited while a backup was attempted. With both systems definitely awake and active, I still got this error.

Is there something else I should try?

Thanks Morgan

kevinvinv    Jun 7 12:11PM 2018

I too am getting a similar issue using SFTP from a MAC to a local NAS.

I also started a thread on this a couple weeks ago.

I have not been able to find the problem.

gchen thinks it might be a temporary network glitch and he says he is going to add some retry logic to the ftp routines. I am hoping this happens soon.

I have added some retries myself to a scripted call to the duplicacy CLI... it is ok but I cant do that at a chunk level... only at the entire backup level and I still am seeing significant issues with a backup level retry logic....

Anyway- you are not alone. I have about 8 machines going to this NAS...some local and some remote... and only a couple are having this problem.


gchen    Jun 7 10:18PM 2018

Morgan's case is slightly different since the error occurred while listing the remote directory when the backup just gets started.

You may need to dig into /var/log/system.log on the server to see if there is any log message explaining why the connection was closed. If there isn't, maybe you need to change the logging level in /etc/ssh/sshd_config.

Copyright © Acrosync LLC 2016-2017