Can't get --backup-dir option to preserve folder structure

What is the problem you are having with rclone?

I am trying to get the --backup-dir option to preserve the folder structure of the files that are moved to the backup directory.

From the documentation this should be possible:

any files which would have been overwritten or deleted are moved in their original hierarchy into this directory

What is your rclone version (output from rclone version)

rclone v1.50.2

  • os/arch: linux/amd64
  • go version: go1.13.6

Which OS you are using and how many bits (eg Windows 7, 64 bit)

KDE Neon 5.20.1

Which cloud storage system are you using? (eg Google Drive)

pCloud

The command you were trying to run

rclone sync /test remote:/test --backup-dir remote:/rbackup -vv

A log from the command with the -vv flag

user@pc:~$ rclone sync /test remote:/test --backup-dir remote:/rbackup/ -vv
2020/10/29 21:02:32 DEBUG : rclone: Version "v1.50.2" starting with parameters ["rclone" "sync" "/test" "remote:/test" "--backup-dir" "remote:/rbackup/" "-vv"]
2020/10/29 21:02:32 DEBUG : Using config file from "rclone.conf"
2020-10-29 21:02:43 INFO  : Encrypted drive 'remote:/test': Waiting for checks to finish
2020-10-29 21:02:43 DEBUG : 1.txt: Sizes differ (src 34674 vs dst 35178)
2020-10-29 21:02:45 INFO  : 1.txt: Moved (server side)
2020-10-29 21:02:45 INFO  : Encrypted drive 'remote:/test': Waiting for transfers to finish
2020-10-29 21:02:48 INFO  : 1.txt: Copied (new)
2020-10-29 21:02:48 INFO  : Waiting for deletions to finish
Transferred:       33.908k / 33.908 kBytes, 100%, 6.487 kBytes/s, ETA 0s
Errors:                 0
Checks:                 2 / 2, 100%
Transferred:            1 / 1, 100%
Elapsed time:        5.2s
2020/10/29 21:02:48 INFO  : 

2020/10/29 21:02:48 DEBUG : 7 go routines active
2020/10/29 21:02:48 DEBUG : rclone: Version "v1.50.2" finishing with parameters ["rclone" "sync" "/test" "remote:/test" "--backup-dir" "remote:/rbackup/" "-vv" "--progress"]

Results

The log file looks good I can see it did the server side move, no errors. When I look at the remote, I can see it did move the file to /rbackup but it didn't preserve the folder structure. It just put the file directly in the backup directory.

The file:

remote:/test/1.txt

should be moved to:

remote:/rbackup/test/1.txt

but instead was moved to:

remote:/rbackup/1.txt

So it lost the /test folder it came from. To be useful, I would expected the option would recreate the existing folder structure under the backup folder.

Is my syntax wrong or is it my understanding or what this command can do?

hello,

first thing to do is upgrade rclone to v.1.53.2.

as a test

  • delete the contents of remote:rbackup and remote:test
  • run the command again and post the debug output
  • run ls on /test and both of remote folders.

I think the command is working as expected. You set the root of the transfer to remote:/test which means all file names are relative to that. When 1.txt was backed up it went into the root of the backup dir remote:/rbackup/1.txt

If you want to have test in the backupdir then you'll need to put it in explicitly like this --backup-dir remote:/rbackup/test

Okay so this is a conceptual error. I designed a test to try and simulate how it works but my test was flawed. Thanks for the feedback!

1.50.2 is the version of rclone that comes from my operating system's app repository.

From what I have read the best practice is to keep this version of the app from an OS repository: easy to upgrade, more secure, compatibility, test with your OS, trusted 3rd party support etc.

I could request that rclone be updated in my repo.

Do you know who maintains the rclone repo on KDE Neon (aka Ubuntu) which is based on Debian?

hi,

in the case of rclone, the os repositories are out of date, sometimes year sold, using old, buggy and less secure versions of rclone.
for example, ubuntu 18.04 uses 1.36.

best to use keep rclone up to date using
https://rclone.org/downloads/#script-download-and-install

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.