Veeam.Backup.Validator.exe & SOBR

[ysukhov]

Hi,

Any plans to remove the limitation of Veeam.Backup.Validator.exe and allow it to wok with SOBRs?

[falkob]

Hi ysukhov,
the Veeam.Backup.Validator.exe will work if you specify a .vbm or .vbk directly from an SOBR extent.
I tried this myself in my lab which went fine. The lab had 4 direct attached SAN LUNs which are extents from 1 SOBR.
I successfully verified a .vbk and .vbm directly out of 1 extent.

Due to my understanding the limitation, that the Validator utility does not work with backups stored on scale-out backup repositories is only if you go for validating a backup job.

Maybe someone else can further approve this.

Hope this helps !

[falkob]

I made a screenshot from validating a .vbk file directly out of an SOBR extent.

[torteflo]

Hi,
I used it a few times on a SOBR, and then find the statement that it cannot work for SOBR
https://helpcenter.veeam.com/archive/ba ... idate.html
> Veeam Backup Validator utility does not work with backups stored on scale-out backup repositories.

In fact I run it with success on backup job pointing to SOBR, with validation check success and/or failed
Also when I got a failure on the check, if I do a robocopy on the specified VBK file it fails too with integrity error

So IMHO it seems to work fine on SOBR
Maybe Veeam cannot garantuee it will always work on SOBR, if some backup files of a job are stored on different extents ?

Could someone give some details or this please ?
Because I am in a middle of a backup corruption detected since a few days, and I today would love to trust the check I am running

[ysukhov]

I haven't looked back at this problem for a while, but as far as I remember, it depends on what extents do you have in your SOBR, or - more precisely - if these extents point to the same VB&R server.

Look at the Falco's response in this thread. For him everything works because all his extents point to the same machine - his backup server. The validator resides on that machine and has direct access to the backup files. No issues here.

Now, try to add an extent to your SOBR, which resides on a different machine, and then try to validate the backups on this extent. It won't work, or, at least, it didn't work that time I wrote the post.

The thing is, the validator is not a simple standalone executable, which directly checks the archives. It uses Veeam services to verify them. Thus, those services should support remote verification, when you have a separate SOBR extent. And this is not implemented.

[ysukhov]

Since this thread has been resurrected, I would like to ask Veeam folks about adding a real SOBR support for the validator one more time, and throw a use case explaining why it's so important:

For a MSP it is crucial to assure the clients that their backups are consistent. While logical consistency is a separate important topic, physical archive consistency is something a service provider has to verify and monitor.

When you deal with petabytes/hundreds of terabytes of tenant backups, most likely, you do work with SOBRs, and not simple repositories.

Additionally, to deal with such amounts of data, validation performance should definitely be optimized. This means that validation from the client side (in case of Cloud Connect) through the Internet is not a real option. It should run on the SP side, moreover it should be local to the repository.

We have high-performance interfaces to our storage devices, which are way faster than usual 10G LAN. So the best, and only real, option for tenant backup verification on the SP side is executing the validator on the SOBR extent, utilizing fast storage interfaces, and not going through the network.

[foggy]

Hi Yuri, thanks for the feedback and detailed use case description. You're correct in your assumptions that there's no logic allowing the proper communication between remote components in this case. Let's keep this thread open to collect more requests for this functionality.

[jordi-simtec]

+1

[torteflo]

Hi,

Yuri, as I said 2months ago I think I had validator working at least a few times with SOBR, giving success on healthy backup and failure on corrupted ones
But I suppose it won't work with backup files of same job on multiple SOBR extents, maybe that was your case
For me the backup server and repositories are different machines
And yes I fully agree that validator should not have to go along the network from Veeam server to repositories servers to check files