Saspus docker and Storj

[RHCPNG]

Hi All,

I’m planning to migrate from Duplicati to Duplicacy and Storj, but I need some guidance.

At this point I would like to use the @saspus docker and want to store my backups at Storj.

I’ve searched the forum and found some scattered info and could use some confirmation and extra info. It’s probably also useful to have the info in one thread.

If I understand it correctly, for Storj, I have to use the CLI for the chuck sizes. So I can’t configure Storj with only the GUI. Is this still correct?

Does the Saspus container also have the CLI I can use?

Another thing I read was that, for most people, it is better to use the S3 option in Storj instead of the native integration. Is this still the case and can this be done with the GUI and without the need of the CLI?

Thanks!

[saspus]

@RHCPNG

I have to use the CLI for the chuck sizes. So I can’t configure Storj with only the GUI. Is this still correct?

Yes. You need to initialize storage with CLI, can be done from any machine from some temporary empty repository. Then you add that storage in WebUI.

@RHCPNG

Does the Saspus container also have the CLI I can use?

You can download CLI from GitHub, for the platform that you will be running it on. It does not have to be on the same machine.

@RHCPNG

Another thing I read was that, for most people, it is better to use the S3 option in Storj instead of the native integration

@saspus

With storj you have two options:

1. Native integration:
   Pros: can achieve massive performance, limited only by your internet connection and hardware
   Cons: You will be limited by your internet connection and hardware; most consumer level routers and switches will experience stability issues. Your upstream will be 2.7x higher than actual data upload rate: native integration uploads directly to storage nodes after all the chunking, encrypting, and erasure encoding; this is a massive load at your CPU and internet channel.
2. S3 Gateway:
   Pros: Storj hosted gateway will handle all that processing. You won’t have upload amplification or any special hardware requirements. It will literally behave like any other S3 storage.
   Cons: you won’t reach performance possible with native integration.

For most users for backup scenarios I would suggest S3 gateway. If you suddenly need to restore at maximum possible performance – you can always configure native integration and do restore that way, you are not burning any bridges going with either approach.

@RHCPNG

Is this still the case and can this be done with the GUI and without the need of the CLI?

When you add storj storage in web UI, if you select “storj” you will configure native integration. To use S3 gateway you need to select “S3 → Amazon or compatible”.

[RHCPNG]

Thanks @saspus! This is very helpful.