Skip to main content
  • EN

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!!!

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

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?

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.

 

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

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


Terms & Conditions