This is just an usage query.
I'm thinking about combining duplicity and rclone.
Duplicity can't deal with google teams drives, so I was thinking maybe mounting the drive with rclone and then, let duplicity do its thing.
How viable is this? In the past, I tried with ocamlfuse with horrible upload speeds, disconnections and huge cache occupation.
hello and weclome to the forum,
i use veeam to backup my computers and servers to a local backup server
after each backup completes, on the backup server, i run rclone sync to wasabi.
why do you need to mount the google drive?
Because maybe I don't have spare space to keep the backup and the original data
In theory this should work fine via a mount.
It comes down to a few details about how duplicity works though (of which I have no experience).
Most importantly, it has to be able to work on the file-level (as opposed to block-level or disk-level).
If the program outputs files rather than internally modifying existing ones then it's file-level and should thus work with rclone and mount. I see that it is intended to be used with various cloud services, so that is a very strong sign that it is file-based (as that will be required for almost any cloud-storage backend).
You will certainly want to use --vfs-cache-mode writes on the mount however, as this is the only way to get full compatibility with any calls that may come from an OS.
Additionally, one thing to look out for is if the program has a tendency to make temporary work-files. I would not really expect that from a backup-software, but it's something to look out for. If that should turn out to be an issue then we can still work around it though - but using a recurring upload script rather than a mount to dump the data to the cloud. It's slightly more of a setup, but I can provide you sample scripts for the job if we should find that we need to do this... (hopefully not) 
Ok, I might try mounting and see what happens.
As said, with ocamlfuse, there were issues with huge caches being occupied, and I guess I could run into the same issues here: I will report after testing.
On the other, duplicity is integrated with many file services but does not support google team drives, as I asked here: https://answers.launchpad.net/duplicity/+question/682795
Which is a shame, because it would make this kind of workarounds unnecessary and I really like the way it keeps incremental backups on a very practical and safe way.
it might not be needed here, if duplicity is simple writing a file sequentially.
what kind of overhead in terms of cpu, ram and other resources, are used for --vfs-cache-mode=writes?
It may not required - no.
But since I don't know the details of duplicity, a write-cache is always the safest and most compatible.
I'd certainly test with it first - then see if it still works if you remove it
If it does just need to move some large contigous files then a cache may indeed be superflous.
If using an upload script instead of mount then a cache will not be needed either way - so that is also an option. Note that you can hook this to a mount too if you want that for making it easier to interface third-party software. This is actually the method I prefer myself due to the speed and control it affords (but it's not as neat and self-contained a solution as just using the integrated cache...)
the vfs write cache will primarily just use 2 types of resources:
In terms of CPU/RAM - trivial impact.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.