I am on Linux Mint 19.2 and since the upgrade the pCloud AppImage desktop program has been completely erratic and unreliable. At the same time, I've been configuring RClone for use with Google Drive and S3 and getting to know its capabilities. I've added my pCloud account as a remote and can browse to interact with it via RClone.
I have been using pCloud less for cloud storage and more as an always-on backup solution (ala Backblaze, Carbonite, SpiderOak, etc.), whereby changes to my local are synced to pCloud. I have several pCloud "syncs" all really one way from local to pCloud.
I am thinking that using RClone will have a lot less overhead, and I can just set up a cron to do this perodically throughout the working day.
Anyone else doing this? If so, what do you recommend as my method?
The easiest thing to do is just run a script on a timer (cron) that performs rclone sync to your remote, as you already said. I'm not sure how much more there is to add to that unless you need step-by-step instructions on how to.
--track-renames is also very useful to enable as it will allow rclone to re-organize already uploaded files if you move them around locally instead of blindly re-uploading them again. This will however require hashes to identify files, so unless you use a filesystem that has hashes compatible with the cloud service you use it will need to fully read the files on sync and generate them. This means it may not be ideal if you want to sync very many files very often. Use it or not depending on what you think is appropriate for your use-case.
You can also look into using the backup dir flag (see usage doc) if you want to keep an extra layer of protection if you accidentally delete something and then rclone happens to sync right after (thus also deleting the cloud file).
If you have need for it you can also apply filtering to ignore certain types of files, or certain folders inside a directory structure you otherwise want to sync ect. ect.
So TLDR - rclone is well suited for the job and has lots of flexibility. I can't say if rclone is runs lighter than any other given sync manager (because I'd need to be familiar with that sync agent to comment), but you can certainly have it run very light and use fairly trivial resources if you configure it like that (the default settings tend to be very light already).
Thanks for your thoughtful answer. I am pretty sure that whatever is synced to pCloud is backed up by them archivally so that one can go back in time (Rewind). If that's true, I know how to do the rest and achieve backups without their client.
It turns out that pCloud has moved to using Electron for their GUI desktop app, and the issues with their client on my system have to do with how Electron is interacting with my desktop (Cinnamon).
Question, assuming I use rclone sync is there a switch which forces one way (local-->remote) with local always being the master?
Some cloud services feature file revisions, so that also be an option yes. The backup-dir is sort of a lite-version of that that don't have to rely on file revisions being a feature of the provider.
Sync by default works one-way, exactly as you describe. If in doubt you can always use --dry-run as a parameter to see what would happen without doing any of the actual operations before comitting. I don't think a standalone two-way sync exists, but you could certainly create one by using 2 sync operations with appropriate parameters run back-to-back.
I'm going to be doing an ongoing sync of my home folder in Linux for backup purposes. After the first sync, I don't expect to pumping huge amounts of files or sizes daily. I have good bandwidth, but don't want to dominate in the case there is a stray several GB file that gets uploaded.
As noted earlier in the thread I will strictly go local-->pCloud. Do you recommend using bwlimit or any other throttling? if so what would be some good 'safe" settings. I'm thinking that I would run sync as a cron every few hours.
Use an rclone sync on a timer via cron. These optional flags flags may may be worthconsidering:
--track-renames
This can compare hashes and avoid having to re-upload data unnecessarily if you happen to re-name or reorganize the location of your local files. Do be aware that this means your computer has to read all files and compute a hash each sync (unless your filesystem supports compatible file-hashes natively which it probably doesn't), so there is a tradeoff here in terms of more local reads vs. potentially a lot of bandwidth savings. You decide what is most important to you, but you don't move around large files/folders often and aren't very limited on bandwidth then you can probably just skip it
--bwlimit
As you said, if you want to avoid your syncs potentially saturating your bandwidth fully for a little while if there is al lot of big new files to upload you can cap it at something reasonable, like 70-80%. That probably leaves you more than enough that you won't notice it for any other work you are doing at the time. Just note that the limit has to be specified in megabytes, not megabits.
Forgive the elementary questions... I'm almost there.
I tested my upload speed a few times today, and I am getting: UPLOAD Mbps=36.50. Assuming I'm doing the conversion right, that means I'm getting 4.5625 MB/s. Are you suggesting that I take ~ 70% of that of 3.2M for my bwlimit?
That should be the right math yes. Exactly what percentage you should withhold from rclone is dependent on your bandwith and other uses, but I'd consider 70% quite conservative.