- There's no way to specify the IP address. Ideally this should be prepopulated with the IP address of the original server.
- The user data from the original instance is not used on the startup of the new instance. In our case (on Ubuntu 20.04) that means cloud-init notices that it's on a new instance and the hostname gets re-written to a default using the IP address (which due to #1 is some new address). If the original user data was passed through, then at least cloud-init would assign the correct hostname.
- Ideally, once you've selected the account and region, you'd go out and find the VPCs and subnets and automatically pre-select the same-named VPCs/subnets, with of course an option to override them as need be.
- When doing tests, it's tedious to go through the process for every server. Ideally we'd select a number of instances (presumably from the same subnet, or even better let us select all the instances in a subnet with a single click) and then select parameters for all of those servers: i.e. we'd like them to go back to the same-named VPC/subnet/security group/etc. Allowing overrides of course, but if we need to move everything from one AZ to another, we generally would want it to all come back up the same way it was.
- Ideally we'd be able to save our recovery plan for later execution. Ideally that plan would be built generically not instance by instance. I.E. restore all instances from this subnet or with a particular tag, so that when we go to run that recovery plan, we don't have to update it for changes in the instance inventory. I would envision this ideally being a mapping from original to new VPC/subnet/etc. names that is then applied to all instances selected for restoration.
#3, #4, and #5 are at least partially done by competitors as well. Those also would be easier with VPC recovery which still isn't working for us on v4. (Yes we have a problem open for that.) But at least we can manually create the VPC structures needed.
The goal would be able to quickly and easily restore from one account, region, and/or az to another, which at the moment it's certainly not quick and easy.
We liked the design and usability of Veeam for AWS better than the competitors, but the recovery issues almost pushed us to a competing product. The closest competing product had it's own (less significant) recovery issues, but if it would have been a little bit better we probably would have chosen it. The saving grace at the moment is that we hope to not have to restore on a regular basis, although we do have a goal of performing regular DR tests.