A quick sidenote: I’m pretty much a coding noob and used Claude Opus and Gemini Pro to help me build my daily backup script for Cronicle. We somehow managed to figure this workaround out together. I'm not 100% sure if this is a genuine bug in the rclone pipeline or if I just missed a specific setting, but the local-crypt workaround is doing the job perfectly for me now. I just wanted to report this in case it helps others or points to something that needs fixing!
I am experiencing a severe internal bottleneck when using a crypt remote layered directly on top of the native filen remote (and previously tested with WebDAV to Filen) when uploading massive single files (e.g., 15-20 GiB vzdump backups).
My internet upload is capable of ~100 Mbit/s, and I use --bwlimit 9M. When the job starts, rclone uploads multiple smaller files concurrently (--transfers 6) and perfectly saturates the 9 MiB/s limit. However, when the job reaches the final, massive single file, the overall transfer speed drops significantly to roughly 2.5 - 3 MiB/s and stays capped there.
I initially suspected an ISP routing issue or a volume-based throttle by Filen (since the drop usually happens around the 11 GiB mark of the total job). However, I ruled this out:
Enabling --multi-thread-streams did not bypass the issue, even though the massive file was chunked (to 500Mb) by Rclone.
The workaround that proved it's an rclone bug: I restructured my script to bypass the live-encryption pipeline. Step 1: I use a local crypt remote to encrypt the data directly onto a local SSD temporary folder. Step 2: I upload the pre-encrypted files using the standard, unencrypted filen remote. With this setup, the exact same massive file uploads perfectly at a constant 9 MiB/s from start to finish.
TL;DR Summary of testing:
Native filen (unencrypted): Full speed (9 MiB/s)
crypt over WebDAV (Filen): Speed drops to ~3 MiB/s on large files (after ~11 GiB)
crypt over native filen: Same result, speed drops to ~3 MiB/s on large files
Local crypt (to SSD) -> Native filen upload: Full speed (9 MiB/s)
This strongly suggests there is an internal pipeline/processing bottleneck in the crypt module when layered over filen for massive files, restricting the throughput of a single encrypted file stream to ~3 MiB/s.
Run the command 'rclone version' and share the full output of the command.
rclone v1.74.1 (had the problems with 1.73.0 and updated it afterwards)
- os/version: debian 13.4 (64 bit)
- os/kernel: 7.0.2-3-pve (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.26.3
- go/linking: static
- go/tags: none
Which cloud storage system are you using? (eg Google Drive)
The command you were trying to run (eg rclone copy /tmp remote:tmp)
# This is the command that triggers the bottleneck on large files:
rclone copy /mnt/pve-backups FilenCrypt: --transfers 6 --checkers 8 --buffer-size 128M --bwlimit 9M --multi-thread-streams 4 --stats 60s -vv
#I've tried many different settings, all with the same result
The rclone config contents with secrets removed.
rclone config
Current remotes:
Name Type
==== ====
FilenCloud filen
FilenCrypt crypt (inactive)
LocalCrypt crypt
A log from the command with the -vv flag
I currently only have standard INFO logs showing the speed dropping from 9 MiB/s to 3 MiB/s when the large file starts.
Honestly, I just wanted to report this finding to the community. I don't have a -vv or debug log right now (which I know would be helpful), but since this is a live production server, I won't switch back to the broken setup just to generate those logs. I hope you understand!
Regarding the single-thread encryption: I spent many hours testing various configurations and explicitly tried forcing different thread settings, but nothing worked (even single thread). The bottleneck remained whenever rclone tried to encrypt a massive file on the fly while streaming it directly to the Filen backend. The only thing that restored my full 9 MiB/s bandwidth was caching the encrypted files in a local temporary folder on the SSD first.
If anyone wants to try and reproduce this: My setup automatically uploads roughly 20-30 GiB daily from Proxmox backups into Filen, with a large 15+ GiB single-file VM backup at the very end triggering the drop.
CPU load for Rclone never went above 5% for 2 assigned cores and memory-usage never went above 900Mb. To check if there was a bottleneck in my settings I assigned 6 more cores and 8Gb of RAM but nothing changed the upload.
I can only provide one -vv log for the 2nd setup. Some parts of the logs are in german.
1. Setup I'm running now with full speed (Pre-encrypted via SSD)
Details: Same settings as setup 1, but upload speed is declining or stalling completely. I’ve tried different settings, even single-thread and higher/lower buffer-sizes.