How to backdate rclone

Suspected Bug
1

What is the problem you are having with rclone?

i put on the latest version of rclone friday/yesterday

rclone --version

rclone v1.64.0

  • os/version: centos 8.5.2111 (64 bit)
  • os/kernel: 4.18.0-348.7.1.el8_5.x86_64 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.21.1
  • go/linking: static
  • go/tags: none

now my backups are really really slow:

2023/09/16 15:31:09 INFO :
Transferred: 96 MiB / 8.979 GiB, 1%, 186 B/s, ETA 1y32w4d
Transferred: 0 / 1, 0%
Elapsed time: 5m0.2s
Transferring:

  •                         2023-09-14_L3.fbk:  1% /8.979Gi, 177/s, **14956h20m39s**

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

b2

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

in perl...

```$rclone copy $backup_root/$work[3]/$filename rclone:$bucket_name/$work[3]/ -v --log-file $log_dir/$work[3].log 2>&1

essentially, I'm just doing a copy.

anyhow -- is there an easy way to backdate (I was on 1.61) without having to resort to doing a restore?

The rclone config contents with secrets removed.

```[rclone]
type = b2
account = xxxx
key = xxxx
endpoint =
2

rclone is a portable executable. no need to install.
so just download whatever verson of rclone and run it.

for testing, i keep different versions of rclone on my systems. rclone_1.53.0, rclone_1.64.0
for example,

/home/username/rclone/versions/rclone_1.53.1 version
/home/username/rclone/versions/rclone_1.64.0 version
3

How did you update?

If you did rclone selfupdate then there is a flag --version to control which rclone version.

4

thanks to both for your assistance.

I was (easily) able to backdate rclone to 1.61.1 am an now seeing this in my log:

```Transferred:       59.719 MiB / 8.979 GiB, 1%, 1.816 MiB/s, ETA **1h23m49s**
```Transferred:            0 / 1, 0%
```Elapsed time:       2m0.3s
```Transferring:
``` *                             2023-09-14_L3.fbk:  0% /8.979Gi, 1.816Mi/s, **1h23m50s**

(quite reasonable eta times imo!)

dunno....but it seems to me that there might be an issue with 1.64 and performance. I will (continue) to say, that nothing changed except for the version of rclone. I didn't change the system (eg, do an dnf update), nor did I change my (perl) code that wraps rclone. I realize there could have been an issue with the network. with my systems being in a datacenter with high-end network, it seems unlikely that the network is at fault.

To add to my data gathering, look at this:

Message from syslogd@opus1 at Sep 17 02:33:28 ...
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 33s! [ksoftirqd/3:29]

Message from syslogd@opus1 at Sep 17 02:33:30 ...
kernel:watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/dying:2998464]

Message from syslogd@opus1 at Sep 17 02:33:30 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [httpd:1447]

Message from syslogd@opus1 at Sep 17 02:33:31 ...
kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [lsmd:896]

I found the above in my session when I (finally) had time to work on this issue again.

the rclone copy that was running yesterday (when I opened this topic, see the log entry from my original post) was still running today. here's the end of the log for that process:

Transferred:           96 MiB / 8.979 GiB, 1%, 0 B/s, ETA -
Transferred:            0 / 1, 0%
Elapsed time:   20h26m0.2s
Transferring:
``` *                             2023-09-14_L3.fbk:  1% /8.979Gi, 0/s, 2562047h47m16s

again -- i don't know...but it sure seems like 1.64 has some issues...
5

That looks more like you are having an OS/hardware issue.

6

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