Originally, restic started with just two backends: local and sftp. Over time, many new backends were added so that restic is now able to store a repository on a variety of different cloud-based services. However, it became clear that each new backend we add for a new cloud service works slightly different and requires almost constant maintenance.
This is great !!! I mean it !
Will try it as soon as I can !!
Amazing teamwork guys ! I will get my hand one the BETA soon and report back here.
This is great!
I’m testing the rclone backend using a Dropbox repo. I’m getting a lot of these:
rclone: 2018/04/05 15:53:37 ERROR : data/00/00a471f0a02b0308b24dbfd45d21189ec98dddb62818d717914bc66ed7c6d66b: Post request put error: upload failed: too_many_write_operations/
Save(<data/00a471f0a0>) returned error, retrying after 282.403981ms: server response unexpected: 500 Internal Server Error (500)
rclone: 2018/04/05 15:53:44 ERROR : data/50/50e730c9d4911e1868b1e25fdade3a30d381446cad1be68375a46c7c78ac6e96: Post request put error: upload failed: too_many_write_operations/..
Save(<data/50e730c9d4>) returned error, retrying after 297.613356ms: server response unexpected: 500 Internal Server Error (500)
rclone: 2018/04/05 15:53:50 ERROR : data/ce/cec4314ffdb563c66bc0c458d1ea126868c36919c731651313330c703a13bf75: Post request put error: upload failed: too_many_write_operations/..
Save(<data/cec4314ffd>) returned error, retrying after 734.23714ms: server response unexpected: 500 Internal Server Error (500)
rclone: 2018/04/05 15:54:07 ERROR : data/98/98f31d198b5c648850c7516dbd47fb57acb92fe4b36219ddbd6c0486c7bcf7ab: Post request put error: upload failed: too_many_write_operations/
rclone: 2018/04/05 15:54:07 ERROR : data/5e/5e53fb72f15922f850dc55ced7d7d9b806ee98804a206eee7d4e1be8d8621f97: Post request put error: upload failed: too_many_write_operations/...
Save(<data/98f31d198b>) returned error, retrying after 361.756985ms: server response unexpected: 500 Internal Server Error (500)
Save(<data/5e53fb72f1>) returned error, retrying after 546.113748ms: server response unexpected: 500 Internal Server Error (500)
rclone: 2018/04/05 15:54:22 ERROR : data/80/807471bb1556b46de8b89d99c76324ce6a09fd336608cd138149ac896e85310f: Post request put error: upload failed: too_many_write_operations/..
Save(<data/807471bb15>) returned error, retrying after 732.814106ms: server response unexpected: 500 Internal Server Error (500)
These rclone issues may be related (I haven’t read through them, just posting here for reference):
https://github.com/ncw/rclone/issues/1483 - Uploading to dropbox speed is fluctuating abnormally #1483
https://github.com/ncw/rclone/issues/1539 - Dropbox v2 api error too_many_write_operations #1539
Just curious: how is everyone using this feature? What are your use cases for it?
This looks really useful! If this rclone backend works, I do have one suggestion: why not change the restic rest server to be a wrapper around rclone that provides the extra restic related features (append only, authentication, etc). This way our server provides the functionality that we care about most, while letting rclone handle what it has been tested with?
Obviously this would happen over time, and there would have to be migration plans for the existing filesystem backend. But this would make it easy to have a fully featured proxy to cloud backends for people to use. Does this sound useful? I’d be interested in take a stab at this (first by testing this rclone backend). Regardless this sounds really good!
Authentication is already implemented in rclone, and the append-only mode has also been added in cmd/serve/restic: add append-only mode by skriss · Pull Request #2186 · rclone/rclone · GitHub. In addition, rclone can also serve files from a directory, exactly like the REST server.
Even better! Out of curiosity, what are the plans for the restic rest server? Is it going to be developed further? Is it going to be a test platform for future extensions to the rest protocol? I’m just curious for any future plans. Whatever the answer, I’m glad to see all these options.
We’ll probably unify the Go code used to serve the restic REST protocol at some point, no further plans beyond that one.
I have a questions regarding the cache and b2
I know there was an issue with restic making a lot of calls to b2 and that made the process slower and more costly.
Question is, what is the recommended way of using b2 storage?
What is restic plans?
Another question, Can the same bucket be used in rclone and direct with restic? and vice versa?
This is an important question as it’s a backup solution then it should work for a very long period of time!
I am planing on storing multiple TBs on B2. And This will be my official backup solution for the next few years.
Trying to understand the future of rclone and restic is important for me.
By the way, i hope to get it running it on a freenas machine. (where all the data is storage)
There was, and we addressed it. It’s much better now, we’ve reduced the number of HTTP requests needed and added a local cache for metadata. 
You can use restic directly or the rclone backend, whatever you prefer. The stability should be roughly the same. Please report back how it goes!
Yes. You can even download the repo to a local directory and then use restic on it directly to restore (or even the other way around: make a repo in a local dir, backup your data, then use rclone manually to sync it up to B2). It’s all compatible, we’re using the same repo format everywhere.
That’s FreeBSD, right? It works very well on FreeBSD, users reported