Where is NFS load in a split architecture?

[pkelly_sts]

I think I know the answer but wanted to check.
We currently have a physical B&R server with all roles, plus a number of VM proxies.
As we can't upgrade our physical to 2012 (replacement being planned) and are backing up a de-duped 2012 VM I'm planning migrating the B&R Server role to a VM, leaving the (SAN-connected) physical server as proxy & repository server.
However, I just wanted to check that, in the event of an guest files recovery taking place am I right in believing that all the "load" would still be on the physical server (the one with the repository hosting the backup files) & so the B&R VM won't be overly taxed & only relegated to orchestration/logging processes?

Actually, another thought has just occurred to me whilst writing, in this scenario, where is the 2012 de-dupe capability required, will the repos server, the one hosting the backup files, /still/ need to be the one that's 2012 to read the files? Otherwise I'm thinking that the B&R server /has/ to be managing de-dupe tasks??

[PTide]

Hi

in the event of an guest files recovery taking place am I right in believing that all the "load" would still be on the physical server (the one with the repository hosting the backup files

Depends on what kind of "load" you are talking about. If it's storage IO load then "yes". In case of Windows guest file recovery backup file from repository is mounted directly to VBR by without getting transferred. If you mean CPU and RAM load then "no" - VBR server still takes part in FLR operations.

NFS load occurs only in case vPower is being utilized - please check this article for details.

will the repos server, the one hosting the backup files, /still/ need to be the one that's 2012 to read the files?

Not sure what you mean here. Please elaborate.

Thank you.

[pkelly_sts]

Thanks, I started typing another reply and, as often happens think I've found my own answer whilst going through it

"Not sure what you mean here. Please elaborate."

Sorry, what I mean is, the whole driver for this upgrade from my POV is because we are backing up a 2012 VM that has de-dupe enabled whereas all our B&R infrastructure is currently 2008 R2.
So, I'm aware that if I wanted to do a guest file recovery of the de-duped 2012 VM then I need a 2012 server (with de-dupe also enabled). In my current scenario that simply means I upgrade my (physical) 2008 B&R server to 2012, enable de-dupe & I'm done.
However, as I want to move to a B&R server VM (for resilience) that I can replicate to our other site, but will still be keeping the repository/proxy server (as 2008 R2) I'm not sure where the Veeam 2012 de-dupe capability is required - on the B&R server to read the backup files, or on the repository server to "serve" the files?

Again, having typed all that out, I think it /has/ to be the B&R server that is required to be 2012/de-dupe enabled as that's the server (for guest file recovery) that is reading the backup files (from the repository server) and offering them up for restore via the appropriate explorer?

I've done plenty of Instant & file restores from Veeam over the few years I've used it, just haven't bumped into a 2012/de-dupe restore yet as we only relatively recently deployed de-dupe here...

[PTide]

However, as I want to move to a B&R server VM (for resilience) that I can replicate to our other site, but will still be keeping the repository/proxy server (as 2008 R2) I'm not sure where the Veeam 2012 de-dupe capability is required - on the B&R server to read the backup files, or on the repository server to "serve" the files?

If you're on v8 then you can keep your repo on 2008R2 as it just provides B&R with an access to backup files - all reading job is done on B&R side. However things differ a bit in v9 - if backup infrastructure gets upgraded from 8 to 9 then mount server will be moved to your default repository, so that repository has to be dedupe-ready as well for sucessfull FLR.

[pkelly_sts]

Ah, we're on v8 at the moment but will obviously move to v9 after a while so that's a useful heads-up. Thanks for the info...