Backend for the Interplanetary File System (IPFS)


Hello everybody,

According to Wikipedia:

IPFS is a protocol and network designed to create a content-addressable, peer-to-peer method of storing and sharing hypermedia in a distributed file system.

It’s basically an immutable filesystem based on and Merkle-tree like DAG.
After thinking about it for a while, it seems to be a perfect candidate for a Restic backup. Both IPFS and the Restic repository format use content addressing and hashes to build a DAG.

Both Restic and the IPFS reference implementation are written in Go.
IPFS provides a Go library. Implementing a Restic backend could be pretty straight forward.
Or do I miss any major obstacles?

Have there been any efforts to backup to IPFS via Restic?


If rclone got support for IPFS, this would be possible (since restic supports storage via rclone).


Interesting. But I would prefer a dedicated restic backend:

There is one problem with the “immutability” of IPFS:
Everytime restic makes a change to an IPFS directory (such as adding a new snapshot), the content of the repo and therefore the hash of this IPFS directory will change.
As a consequence, the restic repo URL would need to change as well.
To avoid adjusting the restic repo URL after each modification, IPFS provides naming system called IPNS.

This PKI-based system can reference changing hashes by a fixed hash. This fixed IPNS hash can be used as the restic repository URL.

However, updating this IPNS has to be done by restic when closing the backend.
I dont this that it can be properly handled via the rclone backend.


Can’t think of it right now, but maybe on irc?!
I think before adding more backends, the plan is to move forward with the general core of restic - like with the new archiver code that was added fairly recently.
But in the end it’s up to the contributers if they want to work on a new backend.


While it’s a nice idea to add a backend for ipfs, I’m skeptical that it’s the right choice for restic. Besides, if it is added to rclone, I don’t see much value in duplicating the work again in restic.

Correct, we have plenty of other stuff to do, improving restore, optimizing prune, adding compression, …

While that’s true, it is a good idea to discuss an idea for a feature before spending serious time on it. It would be a shame to work on code which won’t be merged in the end :slight_smile: