Newbie, just checking to confirm when using rclone sync , files only get deleted at the destination if your source does not have that file. Thanks.
That is correct. Test first with --dry-run.
Use rclone copy if you don’t want files deleted.
@ncw I thought sync is only way one, which means it does a backup job, where you delete files from the source and they don’t get deleted in the destination, is that correct? Does using “rclone copy” on daily basis for the same source folder, gets all files re-uploaded again, or just the changed files?
@peanuts sync is definitely one way as far as I’ve been tested. After the first sync, the subsequent sync, if source files have been deleted, it will delete destination files to match up. At least that is how I understand.
Just changed ones.
Sync is exactly the same as copy with delete whatever is on destination and not in source.
No doubt, sync only makes the DESTINATION match the SOURCE. Doesn’t touch the source. Ever, period.
Course you could sync the remote to the source… I think? I’m pretty sure you can do it either way. I haven’t messed with it but I’m pretty sure you can do that. (otherwise how could you get your stuff back?)
So when typing the command… SOURCE is first… followed by DESTINATION… don’t get it backwards!
let me just make it clear. Lets say /mnt/stuff is your harddrive, and remote:/stuff is your cloud drive…
syntax is: rclone <flags> <command> <source> <destination>
rclone sync /mnt/stuff remote:/stuff <=== This will make the cloud match your harddrive
rclone sync remote:/stuff /mnt/stuff <=== This will make your harddrive match the cloud
but yeah, it’s always a one way sync, and only deletes on the destination
My tip? Only sync when you KNOW your source data is exactly what you want, mostly use COPY, so that way if you lose something on your source, you can recover it from your destination. If you lose something on your source, and don’t realize for awhile (like if you autobackup with cron or something) then it will be gone on the backup as well. So I suggest only using copy till you’ve verified your source. And only sync manually.
1 Like
Excellent tip.
You can also use --backup-dir and possibly --suffix which you can find in the latest beta - more info here: https://github.com/ncw/rclone/issues/98
1 Like
Any files which would have been deleted or overwritten get put in the directory specified.
See the link above for the docs.
I have a question about sync and it fits into this discussion.
In this example:
rclone sync /mnt/stuff remote:/stuff <=== This will make the cloud match your harddrive
rclone sync remote:/stuff /mnt/stuff <=== This will make your harddrive match the cloud
How can I have TWO separate machines that I want to keep in sync with one another?
I upload to backblaze from one machine and I want to pull the files down onto another machine using sync.
When doing a ---dry-run, I see this:
2017/07/21 13:57:44 NOTICE: sysadmin/awk-sed-related/awk-one-liners-explained.pdf: Not updating modification time as --dry-run
2017/07/21 13:57:44 NOTICE: sysadmin/awk-sed-related/sed-one-liners-explained.pdf: Not updating modification time as --dry-run
2017/07/21 13:57:44 NOTICE: sysadmin/awk-sed-related/awk.cheat.sheet.pdf: Not updating modification time as --dry-run
2017/07/21 13:57:44 NOTICE: sysadmin/awk-sed-related/awkcard.pdf: Not updating modification time as --dry-run
I don’t need any of this modified as the files have changed, only the modification time.
I thought sync checked the hash of the file and modification time. Does it only check modification time?
using:
rclone v1.36-DEV on freebsd
and
rclone v1.36 on windows
1 Like
I think the flag I want to use is:
--ignore-existing Skip all files that exist on destination
Is that correct? Is that what you rclone experts would use to sync more than one destination?
If you are syncing only in 1 direction A => cloud => B then rclone sync will work just fine.
However if you want to do B => cloud => A then you are asking for a two way sync which rclone doesn’t support (yet - it is a hard problem).
You could have two different buckets, one for A => b2 bucket1 => B and the other for B => b2 bucket2 => A.
It checks modification time first, - use --checksum to check hash first.
That will mean stuff never gets updated on the remote which probably isn’t what you want.
Suppose somebody accidentally reversed source and destination with Rackspace Cloud Files. Is there any way to recover the files? I really think there should be a warning here. Asking for a friend 
Alas no, unless you used --backup-dir. In future use copy instead of sync, or use --dry-run first, or use --backup-dir - sorry