# Slow upload throughput - Using Veeam backup - Brazil

**URL:** <https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668>\
**Category:** Product Discussions\
**Created:** [September 4, 2023, 7:57am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668 "2023-09-04T07:57:18Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 4, 2023, 7:57am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/1 "2023-09-04T07:57:18Z")

</div>

I am getting very slow speeds to upload data. No mode than 20mb/s. As I am using the bucket to store backups made from veeam and I have around 4Tb that should be send everyday, how can I improve this performance ?

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/9/99be8b889c2b3f6d65e383b26a2edde41168f261.png)

---

<div class="post-metadata">

**Author:** ![ACarneiro](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/acarneiro/32/1129_2.png) [@ACarneiro](https://forum.storj.io/u/ACarneiro)\
**Post date:** [September 4, 2023, 8:29am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/2 "2023-09-04T08:29:43Z")

</div>

Could you give us some more details of your setup?

- Available bandwidth
- Router (Consumer grade? Enterprise grade?)
- CPU usage

(I am sure other, cleverer people like @Alexey will be able to ask more relevant questions) 🙂

(E bem-vindo a esta comunidade, espero que consigamos resolver os seus problemas!) 😉

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 4, 2023, 9:49am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/3 "2023-09-04T09:49:31Z")

</div>

We are an ISP, so the server is connected to a 10Gb interface adaptaer and our backbone to the internet have 200Gb.We are an ASN 28132.

Router is a Hua Wei NE8000 (two routers) enterprise grade. Our CPU usage is less than 20%, as you can see (ti’s a dedicated Dell R410 with 96Gb only the veeam).

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/e/e35799ddf02df4934469c22e367610a7caa04b9f.png)

---

<div class="post-metadata">

**Author:** ![ACarneiro](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/acarneiro/32/1129_2.png) [@ACarneiro](https://forum.storj.io/u/ACarneiro)\
**Post date:** [September 4, 2023, 11:56am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/4 "2023-09-04T11:56:35Z")

</div>

OK, definitely one for the “big guys” to help you with 🙂

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 4, 2023, 2:18pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/5 "2023-09-04T14:18:37Z")

</div>

Thanks for the eforts !!

---

<div class="post-metadata">

**Author:** ![nerdatwork](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/nerdatwork/32/1135_2.png) [@nerdatwork](https://forum.storj.io/u/nerdatwork)\
**Post date:** [September 4, 2023, 3:22pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/6 "2023-09-04T15:22:07Z")

</div>

Welcome to the **forum** @rcarvalhaes !

Did you follow this guide ?

> **[Guide to Veeam and Storj Integration - Storj Docs](https://docs.storj.io/dcs/third-party-tools/veeam)**
>
> A comprehensive guide to integrating Veeam backup and replication with Storj, detailing its advantages and step-by-step integration instructions.

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [September 5, 2023, 3:12am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/7 "2023-09-05T03:12:38Z")

</div>

To increase speed for a Veeam Backup with configured objects storage you need to increase chunk size and parallelism.  
By default it uses 1MiB block size, this is a very small object size and thus speed is suboptimal. It also produce a lot of small objects and increases your costs due to a big amount of segments (see [Pricing - Storj Docs](https://docs.storj.io/dcs/pricing#per-segment-fee)) and slows down almost any operation, include deletions.

However, the Veeam Backup doesn’t have a separate option to change neither S3 chunk size, nor parallelism, it uses the same Storage option for both backup and for the object storage.  
So you may increase the chunk size only by increasing the storage block size ([Data Compression and Deduplication - User Guide for VMware vSphere](https://helpcenter.veeam.com/docs/backup/vsphere/compression_deduplication.html?ver=120#storage-optimization)), but it will increase the size of diff backups.  
For the Storj DCS objects storage the best option is to have 64MiB chunk size.

To increase parallelism you may change a General Network option to **Use multiple upload streams per job** in [Managing Upload Streams - User Guide for VMware vSphere](https://helpcenter.veeam.com/docs/backup/vsphere/enabling_multithreaded_transfer.html?ver=120).

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 5, 2023, 10:49am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/9 "2023-09-05T10:49:32Z")

</div>

This guide is just to setup the service, there is no troubleshooting information about performance, so, it doesn’t help.

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 5, 2023, 11:59am UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/10 "2023-09-05T11:59:07Z")

</div>

Thanks for the detailed answer @Alexey . I have some questions on your points:

1. You recommended 64 MiB chunk size but Veeam seems to have a maximum of 4mb (image bellow). It’s too far from 64, that’s relly 64 your number ?  
 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/3/3f7cb7b5553f476cf807124bb4f5362586ca010f.png)

2. How can I test the network bandwidth with the Storj gateway?

---

<div class="post-metadata">

**Author:** ![Ottetal](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ottetal/32/18876_2.png) [@Ottetal](https://forum.storj.io/u/Ottetal)\
**Post date:** [September 5, 2023, 12:22pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/11 "2023-09-05T12:22:09Z")

</div>

Interesting, why are you (still) running an e5530 from 2009 in active production?

---

<div class="post-metadata">

**Author:** ![ray.bull](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ray.bull/32/7825_2.png) [@ray.bull](https://forum.storj.io/u/ray.bull)\
**Post date:** [September 5, 2023, 1:29pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/12 "2023-09-05T13:29:51Z")

</div>

The largest blocksize Veeam will allow is 8MB, but requires editing Windows Registry to get it to show up. (This is mentioned in Veeam’s [KB4215](https://www.veeam.com/kb4215) under “Object Storage Compatibility”)

‘HKLM\SOFTWARE\Veeam\Veeam Backup and Replication’

add:

UIShowLegacyBlockSize (DWORD, 1)

After restarting the Veeam server once after adding this regkey, you will now see 8MB as an option.

---

<div class="post-metadata">

**Author:** ![Dominick](https://storj.bcdn.literatehosting.com/letter_avatar/dominick/32/5_5575768a8748004e209b776fc1b2916d.png) [@Dominick](https://forum.storj.io/u/Dominick)\
**Post date:** [September 5, 2023, 2:07pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/13 "2023-09-05T14:07:23Z")

</div>

Given your performant setup lets move right to tuning and testing. What block size you are using? If 1MB or smaller please stop the backup and restart it with 4MB and if you have time 8MB which should give you the best throughput.

> **[Object Storage: Impact of Job Storage Optimization Settings (in v11) | Veeam...](https://community.veeam.com/blogs-and-podcasts-57/object-storage-impact-of-job-storage-optimization-settings-in-v11-2601)**
>
> IntroductionObject storage vendors all have configuration considerations that must be accounted for as part of the process of designing Veeam backup repositories. Some of these considerations can be limiting, while others simply help dictate...

20MB/s is 160Mb/s but we should be able to see better speeds. Feel free to also run multiple jobs at the same time to Storj as the additional parallelism should be advantageous.

-Dominick

---

<div class="post-metadata">

**Author:** ![sembeth](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/sembeth/32/63_2.png) [@sembeth](https://forum.storj.io/u/sembeth)\
**Post date:** [September 5, 2023, 3:08pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/14 "2023-09-05T15:08:10Z")

</div>

Hello,  
I would assume that there is a performance improvement when using Gateway-ST ([GitHub - storj/gateway-st: Single-tenant, S3-compatible server to interact with the Storj network](https://github.com/storj/gateway-st)) or Gateway-MT ([GitHub - storj/edge: Storj edge services (including multi-tenant, S3-compatible server to interact with the Storj network)](https://github.com/storj/gateway-mt))?

Gateway-ST is probably sufficient for your needs and easier to set up.

> **[Setting Up a Self-Hosted S3 Compatible Gateway - Storj Docs](https://docs.storj.io/learn/self-host/gateway-st)**
>
> Steps to set up a self-hosted S3 Compatible Gateway including requirements, dependencies, download and installation, and configuration. Also covers cost-saving techniques and performance improvements.

If you want to make a speedtest I would recomment Storj/Uplink. Its a CLI tool where you can upload / download files.

> **[Uploading Your First Object CLI - Storj Docs](https://docs.storj.io/learn/tutorials/quickstart-uplink-cli/uploading-your-first-object)**
>
> Make the world your data center

Be aware that the default settings are not ideal. Please see for a 8 core CPU:

> [@Hotrodding Decentralized Storage](https://forum.storj.io/t/hotrodding-decentralized-storage/15228/1):
>
> These settings on a test 100GB file with adequate compute and a supporting network connection resulted in an observed transfer speed of 1839.2Mb/s (229.9MB/s).
> 
> uplink cp sj:/bucket/bighugefile.zip ~/Downloads/bighugefile.zip --parallelism 8

If you have a more powerful server, you can go even faster.

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 5, 2023, 3:40pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/15 "2023-09-05T15:40:32Z")

</div>

Still a very good machine, dedicated only for veeam, works like a charm!

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 5, 2023, 4:12pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/16 "2023-09-05T16:12:53Z")

</div>

I tested and worked the 8mb Chunk Size, but it seems too faraway from the ideal 64MiB recommented. Even if the troughtput be better now I am still on the point of cost. With 1MiB I already have around 10Tb of data with 10MM of segments, so just the price for segments it’s already 8USD agains 4USD for the 10Tb. Total 12USD.

Wasabi would be USD 7.00 and with lower chunk sizes I will have I will consume less space on incremental backups and deduplication algoritm from Veeam. Bigger chunk sizes means a lot of aditional data transfered for daily incremental backups and less eficience on the deduplication. I have a demand for more than 100TB so I am really thinking if it will make sense.  
Anyway I will run more test for throughtput this night having more parallels connections and this new block.

Another point is concerning the immutability on Wasabi. I didn’t found a way to create a bucked already with "X"days os immutability, that will be very usefull for any stolled access key (someone could just access and delete everything). There is no security protection for that.

There is something that I am missing?

---

<div class="post-metadata">

**Author:** ![jammerdan](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jammerdan/32/1121_2.png) [@jammerdan](https://forum.storj.io/u/jammerdan)\
**Post date:** [September 5, 2023, 4:55pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/17 "2023-09-05T16:55:50Z")

</div>

> [@rcarvalhaes](#):
>
> Another point is concerning the immutability on Wasabi. I didn’t found a way to create a bucked already with "X"days os immutability, that will be very usefull for any stolled access key (someone could just access and delete everything). There is no security protection for that.
> 
> There is something that I am missing?

> <https://github.com/storj/roadmap/issues/47>
>
> \### Description:
> Implement S3 compatible object lock and retention features in S…torj. This includes the ability to get and put object lock configurations, get and put object retention settings, and get and put object legal hold status.
> 
> \### What is the problem/pain point?
> Currently, Storj does not support object lock and retention features that are compatible with S3. This means that users migrating from S3 to Storj may miss out on these features, which are important for data governance and compliance.
> 
> \### What is the impact?
> Implementing these features will enhance Storj's compatibility with S3, making it easier for users to migrate from S3 to Storj. It will also improve Storj's data governance capabilities, as users will be able to apply retention policies and legal holds to their objects.
> 
> \### Why now?
> As more and more organizations are looking for cost-effective and secure alternatives to S3, it's important for Storj to offer feature parity with S3. Implementing these features now will help Storj attract more users and meet their data governance needs.
> 
> \### Links:
> \*\*S3 Methods\*\*
> 
> \- \[GetObjectLockConfiguration\](https://docs.aws.amazon.com/AmazonS3/latest/API/API\_GetObjectLockConfiguration.html)
> \- \[PutObjectLockConfiguration\](https://docs.aws.amazon.com/AmazonS3/latest/API/API\_PutObjectLockConfiguration.html)
> \- \[GetObjectRetention\](https://docs.aws.amazon.com/AmazonS3/latest/API/API\_GetObjectRetention.html)
> \- \[PutObjectRetention\](https://docs.aws.amazon.com/AmazonS3/latest/API/API\_PutObjectRetention.html)
> \- \[GetObjectLegalHold\](https://docs.aws.amazon.com/AmazonS3/latest/API/API\_GetObjectLegalHold.html)
> \- \[PutObjectLegalHold\](https://docs.aws.amazon.com/AmazonS3/latest/API/API\_PutObjectLegalHold.html)
> 
> \### Acceptance Criteria:
> 1. Users can get and put object lock configurations.
> 2. Users can get and put object retention settings.
> 3. Users can get and put object legal hold status.
> 4. The implemented features are compatible with S3.
> 5. The implemented features pass all relevant tests.

---

<div class="post-metadata">

**Author:** ![Dominick](https://storj.bcdn.literatehosting.com/letter_avatar/dominick/32/5_5575768a8748004e209b776fc1b2916d.png) [@Dominick](https://forum.storj.io/u/Dominick)\
**Post date:** [September 5, 2023, 5:58pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/18 "2023-09-05T17:58:52Z")

</div>

We have updated our documentation to advise the use of **large** and ideally **extra large blocks**.

> **[Guide to Veeam and Storj Integration - Storj Docs](https://docs.storj.io/dcs/third-party-tools/veeam#job-configuration)**
>
> A comprehensive guide to integrating Veeam backup and replication with Storj, detailing its advantages and step-by-step integration instructions.

@rcarvalhaes thanks for testing and reporting on throughput.

---

<div class="post-metadata">

**Author:** ![ray.bull](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ray.bull/32/7825_2.png) [@ray.bull](https://forum.storj.io/u/ray.bull)\
**Post date:** [September 5, 2023, 6:23pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/19 "2023-09-05T18:23:41Z")

</div>

> With 1MiB I already have around 10Tb of data with 10MM of segments…so just the price for segments it’s already 8USD

With your change to a 8MiB blocksize, your segment costs will be cut by a factor of x8. So for 1TB of Veeam backup, your Storj cost will be ~$5/TB ($4/TB stored, $1/TB segments)

> Wasabi would be USD 7.00

A hidden cost with Wasabi for backup use-cases is their [90-day minimum storage duration](https://knowledgebase.wasabi.com/hc/en-us/articles/360058734492-How-does-Wasabi-s-minimum-storage-retention-policy-work-) policy. Depending on how often you are purging daily incremental backups, on Wasabi you are required to pay for that used storage for a full 90-days. So if you only keep 30-days worth of daily backups available, with Wasabi you are paying for that used capacity an additional 60-days.

Also, $7/TB is for single-region storage. If you want to ensure your backups are always available and are never offline due to a regional-outage, your Wasabi costs would be USD 14.00 (using Wasabi Cloud Sync to copy your bucket from one region to a second region), plus any additional fees from their 90-day minimum usage policy.

With Storj, there is no 90-day minimum policy and your uploads to Storj DCS are globally distributed, eliminating the risk of downtime associated with regional outages.

> Another point is concerning the immutability

As @jammerdan highlighted, object versioning/immutability (Object Lock & Retention) is on the Storj roadmap.

---

<div class="post-metadata">

**Author:** ![rcarvalhaes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/rcarvalhaes/32/1126_2.png) [@rcarvalhaes](https://forum.storj.io/u/rcarvalhaes)\
**Post date:** [September 5, 2023, 8:56pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/20 "2023-09-05T20:56:58Z")

</div>

> [@ray.bull](#):
>
> on Wasabi you are required to pay for that used storage for a full 90-days.

Hi @ray.bull , thanks for the detailed answer.

@Dominick , what about the point that I wrote concerning the protection agains stolen access key? What alternatives to prevent someone to access with the key and delete the bucket or files inside ?

---

<div class="post-metadata">

**Author:** ![Dominick](https://storj.bcdn.literatehosting.com/letter_avatar/dominick/32/5_5575768a8748004e209b776fc1b2916d.png) [@Dominick](https://forum.storj.io/u/Dominick)\
**Post date:** [September 5, 2023, 9:57pm UTC](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668/21 "2023-09-05T21:57:04Z")

</div>

First off, thanks for this. I reached out to a few principal engineers to make sure I got this perfect.

**Basics…** We follow best practices, have strict access control, and have security as a first principles theme. That being said here is the answer.

**Details…** The access key is the encryption key for decrypting your access grant.

If you want total control **never share the access key** with us. Again we don’t log or record it but thats your answer.

We are only exposed to your access keys during two scenarios

1. When you create them initially on [storj.io](http://storj.io)
2. When you send them to us during an api call to the Hosted Gateway

As an alternative to exposing these credentials to us you can use our network as originally envisioned and run the endpoint yourself as well as client side generate the Access Key and Secret Keys.

1. Use **Uplink CLI** client side to create your access via `uplink register` after importing an _Access Grant_
2. Then run **Gateway ST** and never expose us to the _Access Key_ or the _Secret Key_

-Dominick

[Next page](https://forum.storj.io/t/slow-upload-throughput-using-veeam-backup-brazil/23668.md?page=2)
