Rclone copy Google Drive to Dropbox slow

Help and Support
1

What is the problem you are having with rclone?

Rclone copy Google Drive to Dropbox slow

Run the command 'rclone version' and share the full output of the command.

rclone v1.61.1

  • os/version: ubuntu 22.04 (64 bit)
  • os/kernel: 5.15.0-1034-kvm (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.19.4
  • go/linking: static
  • go/tags: none

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

Google Drive & Dropbox

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone copy 009: MTV: --transfers 12 --order-by modtime,desc --checkers 12 --tpslimit 12 --max-transfer 750G --cutoff-mode soft --dropbox-batch-mode async --fast-list --checksum --dropbox-batch-size 1000 --dropbox-batch-timeout 10s --bwlimit 50M:60M --progress --ignore-existing

The rclone config contents with secrets removed.

[ettvcrypt-009]
type = drive
scope = drive
service_account_file = /opt/sa/all/150.json
team_drive = 0ABaxZ1MrBETnUk9PVA

[009]
type = crypt
remote = ettvcrypt-009:
password = **
password2 = e3p2-**-nZzaRzQ2J50thxndJRnw

[Matt-TV]
type = dropbox
client_id = ***
client_secret = ***
token = {"access_token":"sl.*******>

[MTV]
type = crypt
remote = Matt-TV:Media
password = Vj-**
password2 = **


Transferred:       23.462 GiB / 11.578 TiB, 0%, 2.313 MiB/s, ETA 8w4d15h1m19s
Checks:                 1 / 1, 100%
Transferred:           19 / 10043, 0%
Elapsed time:   2h51m18.8s

This is my first post folks sorry if i miss something, currently I'm trying to move my google library to Dropbox but transfer speed it's awful it's any way to improve the performance.

Sorry if have some typos, English its not my main languaje.

2

Can you share a debug log file?

3

Will --log-file /home/gnolasco/upload.log be enough or i will need to add --log-level flag?

4

You need to add either -vv or --log-level DEBUG

5

When you are done with log and wait for animosity to have a look check this:

I see you are using:

client_id = ***
client_secret = ***

which is good. But I see very often issue with token not being bound to your personal clientID. It is easy and quick to verify:

rclone config reconnect Matt-TV:

Now if you see rclone logo and name in browser authentication than it is not working correctly - you are using shared clientID - the easiest way to fix it is to create remote again from scratch - providing client_id/client_secret in the process when asked

image
image1070×886 139 KB

you should see something like this (instead of kptsky_rclone it should be the name you gave to your clientID) - then all good.

image
image1148×1000 63.5 KB

6

Here is the log:

7

Please add
--bind YOUR_ipv4

And maybe use less options :wink:

8

I do it according to Rclone dropbox config instructions.

9

Which is very right thing to do. But what happens often people create dropbox remote and authenticate. Then create clientID and insert it into config. And it is not active...

this is why I think it is super easy to check:

rclone config reconnect Matt-TV:

and you know 100%

10

Thats the result, should i proceed to refresh?
gnolasco@Ubuntu-22:~$ rclone config reconnect Matt-TV:
Already have a token - refresh?
y) Yes (default)
n) No
y/n>

11

yes - proceed - then yes again and check browser

12

It's behind nat, should i use LAN or WAN IP? on the bind flag?

13

And you can remove this
As this is only a limitation if you UPload to google drive
The download is something about 10TB rolling in 24 hours

To stop the copy if you reach the DL limit you may add this (but with bwlimit throttled you won’t reach it anyhow):
--drive-stop-on-download-limit

14

WAN IP (ipv4, as I recognized that default it will go through ipv6 and that is slower)

15

well... it is not so simple. What is true is that IPv4 vs IPv6 performance can differ - subject of ISP setup.

So it is good advice to check.

Right thing (if you are "lucky" to have ISP supporting both) is to test binding to IPv4 and IPv6 - there is no simple rule that one is faster. If all is right they should be the same. But they it is true that a lot of people discovered that life is not perfect and not always as it should be.

1 Like
16

True. For me on two diff servers at diff hosting it helped a lot to switch to ipv4.

17

I do not have IPv6 yet in my backwaters yet:) But I keep an eye on this subject in case advance civilizations arrives here as well.

2 Likes
18

Using bind IP got this:

19

bind work only nice on simple networks - if you are in some company environment then you can ignore it. Check better your clientid.

20

Thanks a lot guys, bind to nat ip and 90MiB/s thanks a lot.

1 Like