Kopia’s Rclone support is experimental: not all the cloud storages supported by Rclone have been tested to work with Kopia, and some may not work with Kopia; Kopia has been tested to work with Dropbox, OneDrive, and Google Drive through Rclone
This is a little ambiguous to me.
Does this mean “Rclone + Dropbox/OneDrive/GoogleDrive are tested and ok to use for production workloads, but other Rclone backends are not”?
Or does it mean “Do not use any Rclone backends for production workloads; we’ve tested Dropbox/OneDrive/GoogleDrive and they APPEAR to work, but we have not done enough testing to be confident.”?
From my experience most backends work. But only just:) kopia integration with rclone is experimental.
Kopia/rclone combo is not usable for anything practical really today.
This is my experience. I have tried hard and IMO sooner or later it leads to disaster:) in case of rustic, rclone has its API built in. For sure it helped that rclone creator is using restic. If he was using kopia maybe situation would be different.
You do not have to take my word for granted. But I suggest you try to restore something bigger than one file. You will see how painfully slow it is. Also in my case 100% of kopia/rclone repos including onedrive ended up as corrupted.
Thanks @kapitainsky. If this is the case, I would like to see the documentation updated to be more clear and emphatic, removing the term “works”. I suggest the following: (and I would be happy to submit a PR for this edit)
It will be way faster to use Kopia with local repository then use rclone to synchronize that repository with rclone with cloud.
Kopia’s maintenance tasks take forever when using rclone.
Respectfully, speed is a secondary concern; reliability is my primary concern. Eg, Can you trust Kopia with an Rclone backend to reliably manage your backups? @kapitainsky has said you cannot based on his testing. That’s a good data point. But I would like to also hear from others (maybe even a project contributor?) with their thoughts.
For what it’s worth, I’ve been testing a Onedrive backend via Rclone. So far it appears to be working as I have not seen any issues. It has two snapshots in the backup set, each about 2.5Gb. To @jacklul 's point, backups to Rclone/Onedrive are definitely “slower” that other cloud destinations, but that’s all relative; in other words, I don’t consider the performance to be unacceptable. My main concern is, Can I trust the backup?
I believe it is rhetorical question. But having multiple copies of repository and constant testing integrity of restored data - the only thinks to believe, regardless of technical solution used for backup
I think you took my quote out of context. I was replying to someone who said (paraphrasing) “Don’t use rclone backends because they are slow”, and my response was “Speed is not my concern, reliability is”.
But even so, I think it’s reasonable to ask (of any backup software) “Can I trust the backup?” Of course one should periodically test backup integrity. But I would hope the answer to my question for any backup software is “Yes”, not “Maybe, so make sure you test integrity”.
Which is why I’m trying to get to the bottom of what is meant by “Rclone support is experimental”. Does it simply mean that it just hasn’t been tested as much as the other backends? Or are there known issues? Or do the issues only crop up with scale; eg over X GB of data, or Y number of files, or Z number of snapshots? etc…
IMHO, if reliability is your primary concern, then using anything “experimental” should be avoided. Adding one more layer of dependency to a solution can’t increase reliability but in opposite reducing it.
re rclone I did not have time and energy to try to figure out such details. Again - all my rclone based backups were painfully slow for maintenance and restore and got corrupted very fast. Other backups using proper S3 backend are fast and still working after year+.
For OneDrive I use restic/rustic + rclone and it works like a charm.
I think we are violently agreeing Which is why I posted the original question the way I did, pointing out that the current documentation is unclear (at least to me) and asking for clarificiation of what is meant by “experimental” vs “has been tested to work with…”:
Which is why I posted the original question the way I did, pointing out that the current documentation is unclear (at least to me) and asking for clarificiation of what is meant by “experimental” vs “has been tested to work with…”: