Ssh_fx_failure?

Support
#1

What would you guys do to trouble shoot this?

2020-01-01 20:45:14.126 ERROR UPLOAD_CHUNK Failed to upload the chunk 6f1c72d1ff7267bf3f2822c0f0c18d2185b3b209193bae46a7022a6ae4f81324: sftp: “Failure” (SSH_FX_FAILURE)
Failed to upload the chunk 6f1c72d1ff7267bf3f2822c0f0c18d2185b3b209193bae46a7022a6ae4f81324: sftp: “Failure” (SSH_FX_FAILURE)

#2

According to the RFC, SSH_FX_FAILURE is a generic error that could indicate a lot of different errors.

   SSH_FX_FAILURE
      An error occurred, but no specific error code exists to describe
      the failure.

      This error message SHOULD always have meaningful text in the the
      'error message' field.

Obviously in this case the underlying SSH implementation didn’t return “meaningful text”.

Are you running the latest version? In recent versions the SFTP backend should retry a few times before reporting an error.

#3

I think I am on the latest version but will double check. Thanks!

#4

Sorry I was wrong. The SFTP backend only retries on EOF errors (that is, when the connection is unexpectedly closed), so even the latest version would not retry on this SSH_FX_FAILURE error.

Does this error persist if you run the backup again?

#5

It seems to have subsided for now… I’ll report back next time it happens.

#6

I am also getting this error on the web-gui version.

I can sftp into the target and ls the dir w/o issues. Any ideas how to debug it?

#7

Is target a synology Diskstation by a chance?

#8

No. It’s an Raspberry Pi 3B mounted SSD. There is actually an issue that it keeps unmounting (probably power issues). However, when this error occured I could access it otherwise. Possibly the backup was corrupt, since deleting it and starting from scratch worked (until it dismounted again), but obviously that’s not very satisfying if some file system corruption completely breaks the backup.

#9

I see.

I would highly discourage hosting (what appears to be USB) storage media on a raspberry pi, especially 3 series:

  • They are extremely sensitive to power quality and highly susceptible to EMC; it can cause reset in the best case; however usually noise on a power lines is known to inject errors into data streams. I have witnessed that more than once. After all, it’s a prototyping device not designed for a long term reliability required to host data longterm; can hardly blame it.
  • and even if it wasn’t – the non-checksumming filesystem on a fragile USB mass storage stack cannot provide any data consistency guarantees. Your backup will eventually rot silently and you will not know until you need to restore, thus rendering this backup useless. You can of course run periodic full checks (check -a --files) but this is equivalent to full test restores of all versions of all files and is hardly feasible.

If you need local hosted backup please build or buy bit-rot aware storage.

1 Like
#10

Thanks, that makes sense. Somehow missed this post.

Do you happen to have any good pointers or recommendations? Are you essentially discouraging the use of any external usb disks, because they all have this issue?

#11

This happened to me this morning. Command line 2.7.2 version run on iMac Big Sur 11.2.1. The repository is on an external 2Tb usb drive, hosted by Ubuntu 16.04.3.

#12

Maybe the disk is full?

#13

Touche! My two repositories are around 500Gb each, so they should have fitted easily on a 2Tb drive. Turned out, there still was an old third unused repository and disk was full. Thanks for the tip!