VEB and MS SQL backup?

[EugeneK]

You may want to check this thread.

Thanks!

[iversa]

Thanks for the link! That helps

[rreed]

Morning, all. Similar story for us, VEB is breaking our SQL Log Shipping. We have the VSSForceCopyOnly key in place but it's still reaching in and backing up SQL logs (to disk 'NUL' but still backing up logs). Process is VeeamVssSupport\VeeamGuestHelper.exe.

How do we get VEB to leave SQL alone completely and entirely please?

[rreed]

Ah, may have found it. We've done a test restore of our SQL server into a sandbox, and setup a typical VBR job for the test restore. Veeam or VMware seems to be confusing the test server and live one and is backing up the live one via the test job (possibly via same UUID or IP address). Looking into this further...

[Dima P.]

Hi rreed,

When VSSForceCopyOnly is set VEB should not touch the transaction logs, so maybe your guess it right and you observing the behavior of VBR. You are using VEB and VBR on the same test machine with SQL, right?

[rreed]

We use VEB on our live SQL servers, VBR on our test SQL servers - that are restores of our VEB covered servers. Apparently since the restore of course has the original's IP address, regardless of being on an isolated, disconnected network, VBR gets confused and backs up the logs on our live servers. I would call that a bug but not sure if that's by design.

Changed the IP of the test server and the problem went away. Odd, since it's on an isolated/disconnected vSwitch.

[Dima P.]

Thanks for the heads up! It looks like VBR injected the component for SQL transaction log backup to the wrong machine since IP address were identical. Can you clarify how the test SQL was restored (was that an export to virtual disk or BMR to VM)?

[rreed]

BMR to VM.

[Dima P.]

Got it, thanks. BMR restores the network adapter in original state, so that’s why you got the IP address duplicated and that confused the VBR’s transaction log backup utility.

[rreed]

Very good. Would this be something to fix? Perhaps go by VM name, or UUID if the restored VM gets a different one since for VEB into VMware, we create a new VM from scratch and do a BMR?

[Mike Resseler]

The problem with BMR to VM means we don't know that it is a VM, we are performing a Bare Metal Restore and that could be physical and virtual... So we literally restore every setting. I would suggest that if you do a test BMR (and sandbox it) that you still change the IP address if you are going to do specific tests like that. (I personally would also even change the name of the server to something like <originalname>-test)

[rreed]

Very good. If it helps, I was thinking of this as more of a Veeam issue than VBR, since it's a typical Veeam backup job that gets confused. VEB is doing its job perfectly. We'll make it a note to change IP's when we do test restores and go from there.