Test restore from Wasabi from another server

[cchildress]

We've added Wasabi as a Direct backup repository and have completed a full backup to the bucket. We did some test restores and all seems to be working fine. We would like to test restore from a different server to somewhat simulate a DR scenario where we would be installing and configuring Veeam from scratch and connecting to Wasabi to recover data.

I have Veeam installed on this secondary server; is it safe to connect it to the Wasabi bucket or could this cause some problems? I saw others with similar questions being asked to turn on maintenance mode on the Wasabi bucket but I'm not configured as SOBR, we're backing up direct to Wasabi and I don't see a maintenance mode option.

Both are Windows Server 2019 running Veeam 12.0.0.1420.

[Gostev]

There's no clean way to do this currently as the DR backup server will then take ownership of the repository and your backups on the primary backup server will start failing. In theory you should be able to switch back and forth but this was not extensively tested. We're only testing DR scenario when primary backup server is completely lost.

If you want to test that this scenario works in principle, which it does as again we specifically test this being the main DR scenario, then my suggestion would be to create a dedicated test environment (separate VBR, separate bucket).

[cchildress]

Thanks! Glad I asked beforehand.

I'll try creating a separate environment and see if I can get data in and out successfully.

Thanks again!

[david.sole]

Maybe you could share your experience on this.

[cchildress]

Just closing the loop on this question.

I created a new Wasabi bucket and a new backup job on my primary backup server. I ran a file-level backup with about 20GB of data and pushed it to Wasabi. I restored a few files to make sure the backup was looking good.

On a separate server with the same build of Veeam installed, I added the new Wasabi bucket as a backup repository and asked it to import any backups it found. *As Gostev mentioned, Veeam popped up a warning saying this server will be taking ownership of the bucket and the other server's backup jobs may fail. I clicked Yes through the dialog and it discovered the backup I created earlier.

I right-clicked on the backup and ran a guest file restore and pulled down everything from the bucket. I used the Windows tool TreeComp to compare source directories to the restored directories and everything restored perfectly.

This first experiment seems to be successful! I'm going to run a few more experiments for practice and to documentation.

Do we know if there is any down side to transferring ownership of a bucket back and forth between servers? It sounds like it's not a recommended practice unless your really need your data back and your Veeam server is unavailable.

[tyler.jurgens]

Granted I haven't done this hundreds of times, but I have gone back and forth multiple times between VBR servers and haven't run into an issue. I wrote a blog post covering this scenario (albeit heavily geared towards a service provider, but valid nonetheless for a non-service provider environment). https://explosive.cloud/there-and-back- ... eeam-tale/

I could not find a way to cleanly map a new backup for a restored VM back to the existing backup. There may be a way to hack that together, but I didn't want to risk my existing chain, so I created a new backup job. Re-using the same bucket for both servers never caused me an issue, other than the mentioned issue about only one VBR server 'owning' the S3 bucket at one time. I also made sure the VBR version was the same on both sides to mitigate any risk there.