Attempting to upload backups to another server via SSH fails, causes the encrypted backups to be deleted #17
Comments
|
Hello The encrypted directory is expected to be empty after the operation, because this directory is only an encrypted mount of the real directory, it doesn't really contain anything. I believe that to add Could you try that ? |
|
I will try to do that as soon as my backups sync with my main computer via Nextcloud. (That might take a while since it's 11 GB) |
|
Just tried your tip, and while the files are not deleted anymore, they're still not being transferred either: |
|
I wonder, is your file system unusual ? I'm quite surprised to see rsync modifying each time permission, owner and group ! |
|
Regarding permissions, the target storage folder is being added to my Nextcloud instance as an external folder, so it can be synced to my main computer. Is it due to the permissions of the storage folder that I'm having this incident? |
|
I think maybe there's something weird with the file system or something like that. You should try either to mount manually the encrypted directory to see if it's working and/or add some debug to the encfs command, it seems that the encryption is having some trouble that I can't explain with the current log. |
|
Just to confirm, that'd be adding a |
|
Regarding the file system, it's currently configured to copy the backups to the main backup folder, apparently via symlinks: |
|
Config file relevant lines: |
Indeed.
This explain that rsync change the permission each time. Does your distant server has anything into its |
The remote folder is empty, this is attempting the first synchronization. Is there a specific step to be taken before the first remote sync? |
|
You may need to initiate an ssh connection a first time to ensure ssh is ready to work. But nothing more. Did you get any error message from encfs when mounting the encrypted directory ? |
|
I ran the script again, this is the error message (had to manually translate a few errors from Spanish to English, hopefully they match the original strings): |
|
OK, but that was probably the second mount that occurs while the first one was not yet expired. I was expecting an error that would tell us more. |
|
Ok, do try please with this version of the main script, https://github.com/maniackcrudelis/archivist/blob/encryption_debug/archivist.sh It will avoid a remount of the directory and prevent such failure from encfs, but still gives us a log. What we should check is the first log of encfs, when mounting the directory for the first time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When attempting to run Archivist, the section where it uploads the backup to an external server via SSH and rsync fails with no apparent reason. Please review the log file: archivist-log.txt
Relevant lines:
rsync: [sender] readlink_stat("/home/yunohost.app/archivist/encrypted_backup/2UXLD7rtnefGHjDcSlvU4FqW/ePSWKxAbTsIp783m7,7g8vob,kw56QlWemCzRPwUD2sp9,") failed: Input/output error (5)rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1333) [sender=3.2.3]Furthermore, after the script finishes running, the whole
/home/yunohost.app/archivist/encrypted_backup/folder is completely empty, likely a side effect of thersyncprocess failing to send files to the external server.The text was updated successfully, but these errors were encountered: