Hi,
I'm surprised this hasn't got more press so thought I'd share it.
As of v12, it is possible to back up cloud servers (Azure VMs and AWS EC2 Instances) using Veeam Agent without Cloud Connect or direct network connectivity (Cloud Integrated Agents). In my testing it works well, the only limitation is having to use object storage local to the server (Azure Blob / Amazon S3), rather than cheaper third-party alternatives (Wasabi etc).
Few configuration guides:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
Might be useful for those smaller environments where you don't have Veeam for Azure/AWS and aren't using a multi-tenanted backup appliance.
-
- Service Provider
- Posts: 44
- Liked: 3 times
- Joined: Mar 24, 2015 11:32 pm
- Contact:
-
- Product Manager
- Posts: 10099
- Liked: 2693 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Cloud Integrated Agents
Hi Warnox
Correct, our implementation of our cloud native Agent backup requires object storage from the same platform.
May I ask, is this request for Service Provider environments or a general request to be able to use cloud native agents with different object storage provider?
Have you consider to just install a default Veeam Agent and configure object storage as the target?
Best,
Fabian
Correct, our implementation of our cloud native Agent backup requires object storage from the same platform.
May I ask, is this request for Service Provider environments or a general request to be able to use cloud native agents with different object storage provider?
Have you consider to just install a default Veeam Agent and configure object storage as the target?
Best,
Fabian
Product Management Analyst @ Veeam Software
-
- Service Provider
- Posts: 44
- Liked: 3 times
- Joined: Mar 24, 2015 11:32 pm
- Contact:
Re: Cloud Integrated Agents
Hi Fabian,
I was looking for a solution to back-up cloud VMs without an AWS/Azure appliance and without Cloud Connect, while still reporting back to VBR. The above meets this requirement, the only downside being the object storage limitation but that isn't a biggie.
Cheers.
I was looking for a solution to back-up cloud VMs without an AWS/Azure appliance and without Cloud Connect, while still reporting back to VBR. The above meets this requirement, the only downside being the object storage limitation but that isn't a biggie.
Cheers.
-
- Product Manager
- Posts: 10099
- Liked: 2693 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Cloud Integrated Agents
Hi Warnox
Thanks. In that case I suggest to use a regular protection group to deploy the agent.
Our Veeam Agent v6 allows you to use any object storage and it can be managed by a VBR server.
Only downside of this solution, you need to have a connection (VPN) between the Agent and the VBR server.
Installing our regular Veeam Agent on a Cloud VM is fully supported and was done by many of our customers before we had Veeam Backup for AWS/Azure.
Your request for additional supported object storage targets for cloud native agents is noted.
Best,
Fabian
PS:
I moved the topic to the Agent managed by VBR subforum.
Thanks. In that case I suggest to use a regular protection group to deploy the agent.
Our Veeam Agent v6 allows you to use any object storage and it can be managed by a VBR server.
Only downside of this solution, you need to have a connection (VPN) between the Agent and the VBR server.
Installing our regular Veeam Agent on a Cloud VM is fully supported and was done by many of our customers before we had Veeam Backup for AWS/Azure.
Your request for additional supported object storage targets for cloud native agents is noted.
Best,
Fabian
PS:
I moved the topic to the Agent managed by VBR subforum.
Product Management Analyst @ Veeam Software
-
- Veeam Software
- Posts: 245
- Liked: 68 times
- Joined: Jul 12, 2018 4:45 pm
- Full Name: Jim Lowry
- Location: California
- Contact:
Re: Cloud Integrated Agents
The biggest drawback I can see by using non-cloud native object solutions is cost. In the VCSP world, we see partners look at using VB for Azure/AWS/Google and IBM that want to target object storage outside of AWS, Azure, IBM, and Google respectively. It works from a technical standpoint, but you will incur large egress costs getting the data out of the hyperscaler cloud environments. It's pretty cost prohibitive.
If you are managing the machines via VCC or VBR, then external repositories can help with moving data around once you have it removed from the hyperscalers, but you'll still have the same cost limitations for egress data. If we do end up adding support for what you are looking to accomplish, protecting Azure/AWS/Google/IBM native machines and storing those backups off-platform to another/cheaper object platform, the egress costs will likely make up for any savings gained by storing the backups on a platform like Wasabi. There are also restore considerations that would need to be in place as well - which means ingress costs going back into the hyperscalers platforms.
In my experience, infrastructure design options for hyperscaler cloud providers like IBM, AWS, Azure, and Google is almost NEVER a technology problem. It is almost ALWAYS a cost problem.
If you are managing the machines via VCC or VBR, then external repositories can help with moving data around once you have it removed from the hyperscalers, but you'll still have the same cost limitations for egress data. If we do end up adding support for what you are looking to accomplish, protecting Azure/AWS/Google/IBM native machines and storing those backups off-platform to another/cheaper object platform, the egress costs will likely make up for any savings gained by storing the backups on a platform like Wasabi. There are also restore considerations that would need to be in place as well - which means ingress costs going back into the hyperscalers platforms.
In my experience, infrastructure design options for hyperscaler cloud providers like IBM, AWS, Azure, and Google is almost NEVER a technology problem. It is almost ALWAYS a cost problem.
Jim Lowry
Sr. Systems Engineer
VCSP North America West
VMCE, VMCA, VCP-DC
Sr. Systems Engineer
VCSP North America West
VMCE, VMCA, VCP-DC
Who is online
Users browsing this forum: No registered users and 14 guests