Is it possible to build support for rclone (https://rclone.org) as a backend? Would be great as it leverages the extensive work done there on supporting a lot of backends — also I have some problems with the duplicacy google backend (cannot prune without errors) but rclone works so that is also helpful in that respect.
What errors are you running into with Google? An rclone backend has been suggested before but I don’t know if there is enough interest.
The pruning as described in (Prune failure on Google team drives) is still broken but rclone seems to work fine in creating/deleting files in Google Drives backend.
What do you mean by an Rclone backend? Would this be the same as a mounted remote?
Hmm. Seems as though Restic has already done something similar with Rclone as a backend. This sounds very intriguing!
Though it appears as though such a backend has to be implemented on the side of Rclone as a serve type (REST API in the case of restic). There are sftp and webdav types which I guess would function the same and should work with Duplicacy(?).
Yes please! A rclone backend would be amazing, with an option to upload rclone config files into the Duplicacy Web GUI (to make it easy to setup)
When this topic was created, I was thinking about what the use cases for such functionality could be, which were not already served by the rclone mount and/or rclone serve commands. I couldn’t think of anything different.
@barry.jones, what would your use case be?
Yes I guess you are right. All the use cases would be covered by rclone serving up a webdav mount for Duplicacy.
I guess what I was imaging was a tighter integration between Duplicacy and rclone (especially for Duplicacy Web Users) so that it was easy to setup and implement.
For example the ability to upload rclone config files through the Duplicacy web interface etc.
Rclone users still need to mess with CLI to get rclone working, and once they do — duplicacy can already connect to SFTP of rclone serve.
I too fail to see the point in marrying duplicacy and rclone at this point. (Kopia did precisely that btw, and just like here, benefits are questionable at best for same reason)
Essentially what is asked in this topic is support for doing that one very specific operation: rclone serve sftp before running backup and stopping the server once backup run is done.
But why limit to this one operation? Duplicacy (CLI) already supports pre- and post- action scripts. All that needs to be done is to expose that in WebUI. And then if users want to use that for rclone — they can.
Fair point for sure.
Would you consider incorporating the latest rclone in the Duplicacy Web docker container so that users of the container could use pre- and post- action scripts to trigger rclone actions that they want to occur?
Interesting idea.
Today duplicacy web does not support pre and post scripts; you can make it work if you know implementation details and track down ever changing location for the cache files for specific jobs to put scripts into; but those hacks are not sustainable nor portable, and will break even after seemingly unrelated changes in the UI such as deleting unused backup target or reordering schedules. The only way to make it work reliably is for duplicacy web to support that.
However for your purposes you don’t even need that: You can run rclone serve in another container and set it as dependency for duplicacy container. That’s what containers are for — to construct useful system from simple independent services.
I use rclone on WSL a lot and it is great; but my duplicacy is run via the underlying windows and it would be great to get rclone support embeded in…
Yes you are right I could use a rclone container (I already have a few for different things), in this case I guess I was more thinking rclone under the control of pre / post backup scripts and I think the easiest way to do this would be to have rclone in the same container (I hadn’t thought about the problems with pre / post scripts in the current Web UI).
2 Likes