Synology Hyperbackup settings for optimal Storj

I have a couple questions for any Synology Hyperbackup users on Storj. The first is re: Hyperbackup’s “Signature Version” setting for S3 custom servers. The options are V2 or V4. The Synology documentation reads:

Backing up files to the path-style buckets is supported only when you select Custom Server URL for the S3 server and the signature version is V4.

But I can find nothing to explain to me what a path-style bucket is other than some info on AWS re: buckets that have path-style URL access. Backblaze guides tell the user to select V4, but offer no further explanation. Can anyone “splain” this to me? What is the difference? Are there advantages/disadvantages? Is there absolutely one I should choose for Storj & Why?? Are their any risks to changing this at any point?

The second question relates to Hyperbackup’s “Multipart Upload part size”. Options range from 8MB up to 512MB. I understand that Storj is optimized for 64MB segments and the uploads will be broken down or compiled into into 64MB chunks on arrival. Ordinarily, I would use the highest “Multipart Upload part size” the network could handle and adjust down if I was experiencing instability in the network connection. But, I’m curious about how/if this setting has any impact on Storj server-side processing. Should I set it to 64MB to match Storj or should I set it to whatever I want and not worry about Storj?

Thanks in advance.

1 Like

This is a good question. When initially stetting this up I used th 512MB. At a later date, when I was redoing my backups, I set it to 64MB. You can’t change it after the fact. Storj will break it down into 64MB segments regardless.

I think it comes down to the same reason you might want a smaller cluster size on your HD. For example, as I understand it, if you have 512MB of data at 512MB parts, this becomes (8) 64MB segments, but if you have 513MB of data at 512MB blocks, this becomes (16) 64MB segments. If you were using the 64MB part size, this would only be (9) 64MB segments.

Since we pay by segment, in addition to data, you might pay more for Storj at 512MB part size. Granted, the cost per segment is low, but it adds up quickly.

If I’m wrong, I’m sure someone will point it out and correct me.

Why is this? Why is 513MB not 9x64MB segments?


Nope. You pay per segment. The segment is equal or less than 64MiB, so it should use 8-9 segments (overhead on erasure coding and encryption). I would say that using 64MiB part size could use more segments (because there is also overhead on erasure coding after encryption). Roughly 1 more segment after all 64MiB of data (so actually you need to use something about 60MiB of data before encryption and erasure coding). For the 512MiB chunk size there likely would be only one additional segment.

1 Like

Thanks. That make more sense.

Great, I stand corrected. :slight_smile:

What block size would you recommend then? You seem to suggest 60, but that’s likely not an option. These are what are allowed by Hyperbackup:

it was shortly discussed here Upload via various Apps make different results - #7 by xsys

And from my further testing, I tested multiple settings and found the final number of MB and segments used is the same for part size 64 MB and any higher. Maybe things have changed since then either on Synology side or Storj side.

Btw. I have set it like this

but in the bucket I can see all files are reported 52 MB size, so who know how Synology is calculating megabytes:

1 Like

Curious, if Storj is encrypted by it’s very nature, why include client side encryption?

Good question.

  1. Using s3 it makes use of server side encryption, hence user has no full control over it.
  2. I tested both - on and off, and it took the same time to upload and same amount of storj space.

For lack of any further recommendations I opted for turning it on, just for the heck of having it :smile:


Because when you use Storj-hosted S3-compatible Gateway (Gateway-MT) it uses a server-side encryption.
However, you may also configure the HyperBackup to use your own Self-hosted S3-compatible Gateway (Gateway-ST), in this case it will use end-to-end encryption, but this gateway must be in your secured private network segment or better on the same host (i.e. listen only localhost), because it uses only http by default.

Anything greater or equal 64MiB should be good.