SFTP issues with Synology

I’ve tried to my Synology SFTP server as a backup storage. However I seem to get a lot of intermittent errors. The logs all read like this:

019-09-16 22:06:27.166 WARN SFTP_RETRY Encountered an error (EOF); retry after 1 second(s)
2019-09-16 22:06:28.507 WARN SFTP_RETRY Encountered an error (EOF); retry after 2 second(s)
2019-09-16 22:06:30.853 WARN SFTP_RETRY Encountered an error (EOF); retry after 4 second(s)
2019-09-16 22:06:35.198 WARN SFTP_RETRY Encountered an error (EOF); retry after 8 second(s)
2019-09-16 22:06:43.555 WARN SFTP_RETRY Encountered an error (EOF); retry after 16 second(s)
2019-09-16 22:06:59.977 WARN SFTP_RETRY Encountered an error (EOF); retry after 32 second(s)
2019-09-16 22:07:32.344 ERROR STORAGE_CONFIG Failed to download the configuration file from the storage: EOF

Sometimes an operation like backup or check works, most of the time it fails. Here is a check operation that was slow but eventually worked.

Running check command from C:\Users\kork/.duplicacy-web/repositories/localhost/all
Options: [-log check -storage DS9 -a -tabular]
2019-09-16 22:05:52.167 INFO STORAGE_SET Storage set to sftp://duplicacy@ds9/duplicacy-backup
2019-09-16 22:05:52.552 WARN SFTP_RETRY Encountered an error (EOF); retry after 1 second(s)
2019-09-16 22:05:53.901 WARN SFTP_RETRY Encountered an error (EOF); retry after 1 second(s)
2019-09-16 22:05:55.235 WARN SFTP_RETRY Encountered an error (EOF); retry after 2 second(s)
2019-09-16 22:05:57.559 WARN SFTP_RETRY Encountered an error (EOF); retry after 4 second(s)
2019-09-16 22:06:01.914 WARN SFTP_RETRY Encountered an error (EOF); retry after 8 second(s)
2019-09-16 22:06:10.228 INFO SNAPSHOT_CHECK Listing all chunks
2019-09-16 22:06:10.279 WARN SFTP_RETRY Encountered an error (EOF); retry after 1 second(s)
2019-09-16 22:06:11.626 WARN SFTP_RETRY Encountered an error (EOF); retry after 2 second(s)
2019-09-16 22:06:14.015 WARN SFTP_RETRY Encountered an error (EOF); retry after 4 second(s)
2019-09-16 22:06:18.359 WARN SFTP_RETRY Encountered an error (EOF); retry after 8 second(s)
2019-09-16 22:06:26.733 INFO SNAPSHOT_CHECK 1 snapshots and 2 revisions
2019-09-16 22:06:26.733 INFO SNAPSHOT_CHECK Total chunk size is 431 in 4 chunks
2019-09-16 22:06:26.733 INFO SNAPSHOT_CHECK All chunks referenced by snapshot memoryalpha-kork at revision 1 exist
2019-09-16 22:06:26.733 INFO SNAPSHOT_CHECK All chunks referenced by snapshot memoryalpha-kork at revision 2 exist
2019-09-16 22:06:26.734 INFO SNAPSHOT_CHECK 
             snap | rev |                          | files | bytes | chunks | bytes | uniq | bytes | new | bytes |
 memoryalpha-kork |   1 | @ 2019-09-16 21:30 -hash |       |       |      3 |   228 |    1 |   204 |   3 |   228 |
 memoryalpha-kork |   2 | @ 2019-09-16 21:52       |       |       |      3 |   227 |    1 |   203 |   1 |   203 |
 memoryalpha-kork | all |                          |       |       |      4 |   431 |    4 |   431 |     |       |

I have no issues accessing the SFTP server with other software and also network connectivity is not a problem (local LAN, wired connection).

This is a known Synology issue: Chunk uploading error with Synology

2 Likes

Thank you very much. I added an extra slash before the path and it indeed seems to work this way. It’s strange that other software doesn’t seem to have this issue, but if a slash is all that is needed to make it work, I’ll take this :slight_smile:

Well, I fear i celebrated too early. I did a first backup to this location (which was really insanely fast compared to Arq backup which is what I am using right now), but sadly the backup seems to be corrupted. When I try to restore it or just check the storage I get errors about missing chunks:

Running check command from C:\Users\kork/.duplicacy-web/repositories/localhost/all
Options: [-log check -storage DS9 -a -tabular]
2019-09-17 20:48:02.595 INFO STORAGE_SET Storage set to sftp://duplicacy@ds9//duplicacy-backup
2019-09-17 20:48:02.878 INFO SNAPSHOT_CHECK Listing all chunks
2019-09-17 20:48:03.372 INFO SNAPSHOT_CHECK 1 snapshots and 1 revisions
2019-09-17 20:48:03.372 INFO SNAPSHOT_CHECK Total chunk size is 8,471M in 2069 chunks
2019-09-17 20:48:03.373 WARN SNAPSHOT_VALIDATE Chunk ba1e216d4b7fd6d034019fd6ac7cea35c63227b10ce71a516e1359d0576386e2 referenced by snapshot memoryalpha-kork at revision 1 does not exist
2019-09-17 20:48:03.373 WARN SNAPSHOT_VALIDATE Chunk 3bd1332085ddf729fee230ee55b3772a034aceae063b274c97b0f32d5f35178d referenced by snapshot memoryalpha-kork at revision 1 does not exist
2019-09-17 20:48:03.374 WARN SNAPSHOT_VALIDATE Chunk 3925b74952f8e599cd7b6e229cc3477a332e7111be48203129787b60eb11fcb8 referenced by snapshot memoryalpha-kork at revision 1 does not exist
2019-09-17 20:48:03.374 WARN SNAPSHOT_CHECK Some chunks referenced by snapshot memoryalpha-kork at revision 1 are missing
2019-09-17 20:48:03.374 ERROR SNAPSHOT_CHECK Some chunks referenced by some snapshots do not exist in the storage

Here is the guide on what to do when there are missing chunks: Fix missing chunks

Thank you very much for the quick link. I wonder if I did something wrong or if this is erratic behaviour of Duplicacy? I think using SFTP with Synology is probably not a good idea. I’ll try to set up MINIO and use the S3 service to see if this works better.

Pure speculation, but I’m wondering if the storage didn’t initialise properly due to the lack of slash in the path the first time you ran it. So when revision 1 got backed up, the chunks didn’t end up in the folder structure at /duplicacy-backup/chunks but instead the cwd/home dir for the sftp account?

Did you start from scratch after adding the slash?

Alternatively, try assigning a new repository ID to your backup so that starts again but without re-uploading most chunks (it’s mentioned in that ‘fix missing chunks’ post).

1 Like

Well I “added” the slash when creating the storage in the UI by adding an extra slash before the folder name. Because the UI builds the final URL from the contents of the fields, I was able to “sneak in” an extra slash. So the final URL built actually contained two slashes before the store was initialized. I tried using S3 with MINIO now and this seemed to work better.