We have a SOBR that uses our on-prem Exagrid as the performance tier, and then backups are archived to AWS Glacier Deep Archive (no capacity tier).
Our upload speeds on our 1GB/s internet has been limited to 40MB/s, which is concerning as we have some larger servers that are over 30TB. We're currently set our Amazon Glacier Backup Repository Connection Type to "Through a gateway server", using our Veeam Management server to perform the upload.
We are wondering if we switch to Direct instead, if we would expect improved network speed. If so, do we then need to allow our Exagrid appliance direct access to the AWS URL's/ports? Or does the upload go through our Backup Proxies instead?
I tried researching this, but all the results I got were related to AWS Direct Connect, which I know is completely different (and not something we have). Thank you in advance!
-
- Novice
- Posts: 5
- Liked: never
- Joined: Aug 03, 2024 10:47 pm
- Full Name: Brandon Hofmann
- Contact:
-
- Veeam Software
- Posts: 2590
- Liked: 606 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: AWS Glacier Backup Repository - "Direct" vs "Through a gateway server" Connection Type
Hi Brandon,
Thanks for the details on the situation.
I'm not as confident that switching to direct will matter -- the details are outlined a bit more here, but a gateway server is simply acting as the final exit point from your backup infrastructure for the data, so while potentially you might see some improvements depending on the environment, I'm not confident you will see a significant change, but it's worth testing at least.
What is the bottleneck listed during the offload job? You should be able to check it in the History tab of the console. Given that it's a deduplication appliance as a source, my immediate thought is that the Exagrid is the bottleneck, but would be best to confirm it there. If it's source bottleneck, then very likely changing the gateway won't help much, as we're waiting on the Exagrid to serve up the data. You could similarly isolate it to the exagrid by doing a test restore and seeing if the speeds are similar during the restore with bottleneck as source.
Thanks for the details on the situation.
I'm not as confident that switching to direct will matter -- the details are outlined a bit more here, but a gateway server is simply acting as the final exit point from your backup infrastructure for the data, so while potentially you might see some improvements depending on the environment, I'm not confident you will see a significant change, but it's worth testing at least.
What is the bottleneck listed during the offload job? You should be able to check it in the History tab of the console. Given that it's a deduplication appliance as a source, my immediate thought is that the Exagrid is the bottleneck, but would be best to confirm it there. If it's source bottleneck, then very likely changing the gateway won't help much, as we're waiting on the Exagrid to serve up the data. You could similarly isolate it to the exagrid by doing a test restore and seeing if the speeds are similar during the restore with bottleneck as source.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: No registered users and 12 guests