Skip to main content
Solved

Configure AMI / timeout / retries for Veeam Proxy Appliance in AWS


Hello,

I’m trying to restore a Veeam backup from Capacity tier (S3) into an EC2 instance in AWS.

However, I’m facing a problem with the proxy instance. Once I start the restore process, the proxy instance is created, but after abou a minute I get an error:

“Preparing proxy appliance VM Error: The destination would not be a correct SSH server.”

I tried ssh to the proxy, but the connection gets rejected, while connections to other hosts in the same subnet with the same security groups are successful.

So I manually created an instance using the same settings Veeam uses for the proxy, same subnet, security groups, AMI, and found that connections are successful, but only a few minutes after instance creation with that particular AMI Veeam chooses for the proxy instance (aws-parallelcluster-3.1.4-ubuntu-2004-lts).

Now, the question is, is there a way to configure the AMI, the timeout or the number of SSH retries for the proxy appliance?

Thanks!!!

Best answer by pampelix

Ok, this seems to work better now, no idea why but I’m rarely getting timeouts now. Everything is exactly the same… Maybe was just AWS having a bad day.

 

View original
Did this topic help you find an answer to your question?

5 comments

MicoolPaul
Forum|alt.badge.img+23

Unsure, but check your logs, this could be a tenant configuration with AWS preventing connectivity, could have a firewall rule issue. What version of Veeam are you running as that’ll relate to how up to date it’s AWS integration is.

 

Logs are gonna help a lot, might find a strange IP issue here


  • Author
  • Not a newbie anymore
  • 5 comments
  • May 19, 2022

Hi @MicoolPaul , thanks for getting back to me.

It’s not firewall or stange IP, it’s purely the AMI that’s chosen by Veeam for the proxy instance. To test, I set the termination protection on the proxy instance, so Veeam couldn’t tear it down after trying 10 times, and after a few minutes I was actually able to ssh into the instance. So it’s really just that, takes some time for the ssh service to start.

In the logs I see:

Getting x86x64 images by name: 'ubuntu-bionic-18.04-amd64-server-20180522-dotnetcore-2018.07.11';
Getting x86x64 images by name: '*ubuntu-bionic-18.04-amd64-server*';
Getting x86x64 images by name: '*ubuntu*';
Chosen AMI for AWS proxy: 'ami-00e62671e21dc4aad'

 

The chosen AMI is this one: aws-parallelcluster-3.1.4-ubuntu-2004-lts-hvm-x86_64-202205121006 2022-05-12T10-09-32.380Z, and I wonder why that is. Can that be changed somehow? I tested running the exact same AMI in the same subnet, security group etc and it really takes 5 minutes until I can ssh.

Anyway, this AMI seems wildly inappropriate for this use case?? A “normal” Ubuntu installation should do, no? No need for parallelcluster?


  • Author
  • Not a newbie anymore
  • 5 comments
  • Answer
  • May 24, 2022

Ok, this seems to work better now, no idea why but I’m rarely getting timeouts now. Everything is exactly the same… Maybe was just AWS having a bad day.

 


MicoolPaul
Forum|alt.badge.img+23

Glad your problem is sorted, sucks we didn’t have anything definitive as a resolution, but as you say, likely a bad cloud day…


  • Author
  • Not a newbie anymore
  • 5 comments
  • May 24, 2022

I still think the queries to select the ubuntu AMI should be changed, they’re not gonna return anything ever:

Getting x86x64 images by name: 'ubuntu-bionic-18.04-amd64-server-20180522-dotnetcore-2018.07.11';
Getting x86x64 images by name: '*ubuntu-bionic-18.04-amd64-server*';
Getting x86x64 images by name: '*ubuntu*';

There’s just nothing for the first 2 queries, so it will always fall back to ANY image with ubuntu in the name.


Comment