Data Domain design questions

[ori]

Hello, (v8 patch1)
I currently use two physical FC connected proxies that also act as repositories, each connected (also via fiber) to a separate storage as target. With this design I enjoy good bandwidth when running 2 jobs in parallel and using parallel disk processing.

Now I am migrating to Data Domain as repository (ddboost over fiber) and I have questions regarding the design, currently my 2 physical proxies "see" the data domain:
1. I have configured 2 ddboost repositories each one with a different proxy as gateway server, does it make sense to use both of them now with a single DD unit, is it even possible to write to the DD from 2 gateways at a time? Maybe it makes sense for proxy redundancy but jobs cannot be configured to automatically choose a repository.... Let's ask it shortly - what would be the best jobs design with my current environment?

2. I have read about the great synthetic fulls duration improvement now with the Virtual Synthetics feature. Does it also apply to the new v8 Forever Forward Incremental backup mode or should I stick with the periodic synthetic fulls with the Data Domain?

3. Now that the deduplication is global, what would be the considerations for choosing VMs for a job (I used to aggregate them based on OS for better dedup ratio). Apart from forming some sort of consistency groups with backup schedules, are there any other considerations for choosing VMs for a job?

Thanks!

[foggy]

1. I have configured 2 ddboost repositories each one with a different proxy as gateway server, does it make sense to use both of them now with a single DD unit, is it even possible to write to the DD from 2 gateways at a time?

This is possible provided those repositories located in different storage units.

2. I have read about the great synthetic fulls duration improvement now with the Virtual Synthetics feature. Does it also apply to the new v8 Forever Forward Incremental backup mode or should I stick with the periodic synthetic fulls with the Data Domain?

Yes, this applies to forever forward incremental mode, though I recommend to wait for update 2 as it will bring a lot of optimizations in this area.

3. Now that the deduplication is global, what would be the considerations for choosing VMs for a job (I used to aggregate them based on OS for better dedup ratio). Apart from forming some sort of consistency groups with backup schedules, are there any other considerations for choosing VMs for a job?

Typically VMs are grouped based on either similar OS for better dedupe, or similar SLA to have the same RPO/RTO values. Also legal requirements for storing data (if applicable) can be considered as a criterion.

[ori]

Thanks foggy.
Regarding 3, my considerations are performance/compression wise, are there any limitations / best practice / field experience regarding how many VMs to put in a job or maximum backup file size?

[veremin]

No limitations whatsoever. It's still worth keeping backup files smaller than several TB; should be helpful in cases when you have to move backup files from one location to the other.

[ori]

One last clarification, since dedup is now global there is no advantage in grouping similar OS VMs in a job, am I correct?

[foggy]

Do you mean Data Domain deduplication (since Veeam B&R inline deduplication is still per-job)?

[ori]

Yes, but veeam inline deduplication checkbox is turned off in the job because the repository is Data Domain (actually the software uncheck it automatically when choosing the dd repository)

[veremin]

Software automatically sets the recommended setting for this type of repository. Since software deduplication won't be used, you don't necessarily have to group VMs based on OS similarity. Thanks.