so the basic command might be
rclone sync --dry-run RichFlix:/The Skull/ PeaPod:/Rich/SKULL/
1 Like
I copied the passwords from one crypt to the other
Ok, so could you explain why I don't copy one encrypted drive to the other?
What was the difference between using the name of the crypt in my command as I did, as opposed to using the full path as you did.
The end result gave me my encrypted files at the destination, so I just want to understand what the downside was?
Ok, so to try and answer my own question... Is it because I'm unnecesarily getting rclone to encrypt and decrypt it again, so slowing the process down?
yeah, it is confusing but both commands with produce the same result, but in different ways.
rclone sync -i RichFlixCrypt: PeaPodCrypt:
that will force rclone to
- download a source file from
RichFlixCrypt: - decrypt the source file using the passwords from
RichFlixCrypt: - re-encrypt the source file using the passwords from
PeaPodCrypt: - copy the re-encrypted file to
PeaPodCrypt:
rclone sync --dry-run RichFlix:/The Skull/ PeaPod:/Rich/SKULL/
- download a source file from
RichFlix:/The Skull/ - copy the source file to
PeaPod:/Rich/SKULL/
so my way, uses less cpu resoruces, no need to decrypt and re-encrypt.
and if you using that cheap cloud vm, they offen have little cpu processing power, just a single vcore.
side note: technically rclone downloads/uploads chunks of a file at a time, does not download the entire file.
1 Like
Thank you, that is very clear and makes perfect sense 
So my final command might be something like...
rclone sync RichFlix:/The Skull/ PeaPod:/Rich/SKULL/ --checkers=16 --transfers=8 --drive-pacer-min-sleep=10ms
Hopefully that might come close to saturating my connection
and to clarify Sync is probably the best option as files are still being added to the source and there is a posibility I will have to stop and start the process a couple of times. Does that sound about right?
yes, rclone sync is the way to go.
sure, we could create some complex commands using rclone copy and/or --max-age
imho, if you want this transfer to work without surprises, a simple rclone sync is the way to go.
1 Like
I always look for the simple way to get things done.
For me, I ran a rclone move drive: dropbox: on a machine and just let it run for a few weeks and kept the same crypt keys between both and was done.
If deleting the source doesn't make sense for you, just do a copy or sync.
For me, I always go for less.
1 Like
This makes sense, however I don't trust myself to not make a mistake so the sync might be a better option for me
1 Like
Just a small idea if you do not want to use a VPS
You can export the data from google takeout directly to Dropbox.
You can make an automation folder in dropbox to automatically extract the archives google will create.
Not tested myself but should be able to do the job. Don't know how long it will take though.
It's also possible that the archives slightly changes the file time roundings. This might screw up rclone sync jobs. So properly test it if interested. I'm unsure whether dropbox supports zip64. So might be best to test .tgz for compression.
Not sure that would meet my needs as that makes a zipped file on the destination so I'd have to unzip 100TB and reupload it anyway.
Dropbox has automation functionality where you can make it automatically extract the created archives (i advise using .tgz instead of zip, see earlier reason)
Link for documentation on that?
Also, how are you getting around the file size limits? I''m assuming you can transfer over a 100TB zip file on takeout and have that work due to the file size limits?
Google exports at max 50GB zip files and will split as necessary. File type for export is either .zip or .tgz
Very cool, SL-Gundam. Have you attempted using this for a large library yet?
Not yet. Was thinking about it though.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.