Proxy Chaining with vSAN to NAS

[vlad_diverse]

Hi All,
I have a vSAN with 5 hosts and as I get it, I need 5 virtual proxies, one per host. I want to backup to a NAS device and want to de-duplicate.
Is it possible to have a hardware proxy for compression/deduplication?
Will Veeam use virtual proxy with hot-add and then pass it to hardware based proxy for compression and deduplication?

[HannesK]

Hello,
and welcome to the forums.

and as I get it, I need 5 virtual proxies, one per host

that's an option. But no hard requirement. I would go for one physical server with internal disks. That avoids potential chicken-egg issues and keeps the whole setup simple.

I don't know what you mean with hardware-based proxy-deduplication. With NAS, you decided for the slowest repository option available. So deduplication is the smallest concern you might have. With NAS, the chances are high that you need to do active-full backup to avoid merges.

There are NAS devices that have deduplication features. But it looks like you are asking for something else.

I recommend to design by "required speed" and "costs" instead of "space savings". I repeat my recommendation for a standalone server with internal disks and REFS
https://www.veeam.com/blog/advanced-ref ... suite.html
post368298.html


Best regards,
Hannes

[vlad_diverse]

Thanks for reply Hannes, I have a physical server, which is using iSCSI to mount a 240TB ReFS volume as a repository. This server has plenty of RAM/CPU, unlike my 5 virtual proxies. I was thinking to offload dedup/compression to this server somehow.

[HannesK]

sounds good. just keep it simple

My rule of thumb is up to 1000 VMs with one physical server... I'm sure you have less on your five ESXi hosts...

[vlad_diverse]

Hi Hannes, do you understand what proxy chaining is?

[HannesK]

No.

But you already posted that you have a good setup. So I'm not really worried about it. The software also does not support it, because it makes no sense.

[vlad_diverse]

Thanks Hannes, got it. It is not possible. No problems.

[soncscy]

Just to chime in, per the user guide, for Veeam, dedupe is done by the source side (your proxies), compression is done by the target (repository or gateway there).

So in your set up you get the benefit of the strong repository server with regard to compression.

But the Veeam dedup operations are handled by the hotadd proxies.

From my experience, any vm on a host built in the last couple of years will handle the dedup just fine.

To he honest, not sure which service you're wanting the dedup done by -- you're talking Veeam internal dedup or how does your set up handle it?

[vlad_diverse]

Hi soncscy,
Thanks a lot for dedup/compression explanation, it makes sense. I am talking about Veeam backup. My storage is connected via iSCSI to a Windows host, as ReFS volume.

[soncscy]

Understood.

Frankly speaking then, I'm not sure that there's much value to either if you're using block cloning in the end as the block cloning will likely be your biggest amount of savings and performance. We keep most of our clients at the defaults for the backup (though we kick the storage block size up to 4096 as the overall performance seems better), and almost never are proxy actions really the set up.

You can probably kick compression up with your repository server specs, but I personally would be surprised if you saw significant savings on the increments. Instead, you should be expecting to see a normally sized first full backup, moderately sized increments, then with Synthetic Fulls, fast performance with the size of increments due to block cloning. Compression won't hurt this at all, but I'm not sure it will help either.

But, give it a shot! Also, if you're not too deeply committed with a Windows repository, XFS and reflinks also do block cloning and it's showing very good results. There's another thread on this with some frankly amazing numbers for XFS. You might want to give it some testing first and see if it meets your needs.