DR Test

[Daithi]

Hi all,

We use Veeam 12 and have a backup onsite and a capacity tier in Azure using Azure Blob storage.

We would like to start testing the restore of the VMs direct from Azure blob to an Azure VM. I.e. the scenario would be we have lost our onsite location.

Can I just verify these steps

Build a Azure server
Install Veeam (with SQL, as that's our current database)
Restore the Config file

I'm a bit stuck on the next steps.

I can see the backups from the Capacity tier. Can I just right click on it and restore to Azure? Or do I need to add the object storage separately and scan it as a "normal" repo.

Our existing Veeam server is working fine, so I don't want to mess up that configuration.

[Mildur]

Hi Daithi

It is not supported to connect the same object storage to two backup server simultaneously.
If you want to do restore testings, you can do the following:

1. Switch the Azure blob on your primary backup server to the maintenance mode
2. Connect Azure blob to a new backup server (don't restore the configuration)
3. Import the backups --> https://helpcenter.veeam.com/docs/backu ... ml?ver=120
4. run restore tests
5. remove Azure Blob from new backup server
6. Disable maintenance mode from the Azure blob on the primary backup server

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

IMPORTANT
Only one backup server must interact with an object storage repository. If you want to perform disaster recovery testing, you can add the object storage repository to another backup server. However, on the initial backup server, you must switch the object storage repository to the Maintenance mode. Otherwise, metadata on the object storage can get corrupted or out of sync, and you will not be able to restore data.

Best,
Fabian

[Daithi]

Hi,

Many thanks, that's exactly what I'm looking for.

Thanks
Dave

[keithlammers]

1. Switch the Azure blob on your primary backup server to the maintenance mode
2. Connect Azure blob to a new backup server (don't restore the configuration)
3. Import the backups --> https://helpcenter.veeam.com/docs/backu ... ml?ver=120
4. run restore tests
5. remove Azure Blob from new backup server
6. Disable maintenance mode from the Azure blob on the primary backup server

I've tried these steps, but after step 6, I do a rescan on my scale-out repository and it gives this error:

Code: Select all

6/1/2023 2:07:04 PM Warning    Failed to synchronize Wasabi Details: Data in the object storage is encrypted with a different password.

To make it work again, I have to fully remove the object storage from Veeam, then re-add it to the scale-out repository.

I used to do these exact steps on Veeam 11, so I'm curious to know what changed in Veeam 12 to cause this issue. Shouldn't it be possible to mount an object storage repository in a read-only state for testing restores on an isolated offsite test box?

[Mildur]

Have you connected a v11 capacity tier to a v12 server?
Or is the original and target backup server on the same build?

Best,
Fabian

[keithlammers]

Original and target are the same build number (12.0.0.1420 P20233023). On the original server it's a scale-out repository with object storage as the capacity tier. For DR testing, I put that into maintenance mode, then add the object storage to the DR test machine as object storage (not as a scale-out repository). Is that possibly where the issue is?

[Mildur]

Hi Keith

The process is supported and should also work with V12. Adding it as a object storage repository and then run the import is enough. A SOBR must not be used on the DR server.

Can you please open a case and upload the log files? This will help us to determine if it's a bug or not. Please provide me with the case number.

I also strongly recommend to update to our first big cumulative patch which has solved more then 100 known bugs:
https://www.veeam.com/kb4420
Maybe you can run the test again after you have updated to 12.0.0.1420 P20230412.

Best,
Fabian

[keithlammers]

Ok, I will try the patch and if I can still reproduce this, I'll open a ticket and let you know

Thanks!

[keithlammers]

Just re-tested with the latest patch and got the same issue. The issue doesn't happen if I add the bucket to the DR server but don't import the backups, it only happens after I've imported the backups on the DR server. I'll submit a ticket soon and send it over

Thanks!

[keithlammers]

I've submitted a case just now, case #06103914.

Thanks!

[claudiofolu]

This procedure is still valid if we are using inmutability in the bucket?

[Daithi]

Ah, I got the same issue. I'll try and re-add it

[Mildur]

@claudiofolu
Yes. Doesn't matter if you use immutability or not.

Best,
Fabian

[sykerzner]

Hi,

This can also come up when going from v12.1 to v12 or vice vera.

I had the same issue, but in my case, the production VBR was v12. and the one I was testing the restore from was v12.1

As is documented elsewhere, backups encrypted (touched?) by v12.1 can't be read by v12.
After updating to v12.1 - I was able to read and Import the backups.

Having trouble getting the Object Repo back as a Capacity Extent.. because during troubleshooting, I removed it... I have a ticket for that.

[sykerzner]

Update: I had the Repo still attached, so I could not add it as part of the SOBR. I detached the repo and then was able to add it to the SOBR again.