Recommended Backup Job Settings for EMC Data Domain

[rnt-guy]

Hello,
I was going through the recommendations here and was curious if the answers change where Windows disk is the backup job destination and then it's the copy job that is a DD, not a DD first.

For example we store backup on Server 2012R2 dedupe disks first and then run a copy job out to a remote DD using the Cloud Connect product. I could see it making sense to enable inline data deduplication. Curious about other settings too.

Thanks

[foggy]

Will "Local target 16TB+" give it the best use of space on the local disks?

No.

or if I use something else that is better it will be worse for the DD's turn?

Yes, specifically for restore and synthetic operations performance.

[foggy]

I was going through the recommendations here and was curious if the answers change where Windows disk is the backup job destination and then it's the copy job that is a DD, not a DD first.

Recommendations are for DD, but in the described scenario your settings have to be a trade-off between both storages requirements.

[rnt-guy]

Thanks. Our customers aren't concerned with restore performance as they are quite rare, but rather disk space and window to get the backup job complete. So it would seem we should use the storage optimization size that results in the best dedupe performance on the backup job (win2012r2 w/ dedupe) with in-line dedupe enabled, then use optimal compression with decompress turned on for the copy job destination.

sound about right? I think the best dedupe rate for the windows server would be 'dedupe friendly', no? if it's not much different maybe I should leave it 'optimal' so that the copy job to dd can have that setting be best?

another question is about restarts: which of the settings in the recommendations require a reseed if we decide to change them? I remember storage optimization won't take effect until a new active full. are there others? We want to get the best dedupe ratio from DD without having to constantly test and redo active fulls. Sounds like DD won't care what settings we use as it will compress and dedupe on it's own.

[foggy]

Thanks. Our customers aren't concerned with restore performance as they are quite rare, but rather disk space and window to get the backup job complete. So it would seem we should use the storage optimization size that results in the best dedupe performance on the backup job (win2012r2 w/ dedupe) with in-line dedupe enabled, then use optimal compression with decompress turned on for the copy job destination.

sound about right? I think the best dedupe rate for the windows server would be 'dedupe friendly', no?

Yes, I'd go with these settings then.

another question is about restarts: which of the settings in the recommendations require a reseed if we decide to change them? I remember storage optimization won't take effect until a new active full. are there others?

Right, block size change requires active full, while compression will take effect right from the next incremental cycle.

[rnt-guy]

Thanks so much. Very appreciated.

[rnt-guy]

Last question - does in-line dedupe only affect backup jobs and not once we go offsite to the DD? Seems good to use it then?

[rnt-guy]

Sorry, I lied One more:

is there any value with Synthetic Fulls with a DD? Since all VBKs are deduped against each other any corruption on the actual disks would be ruined anyway right? Or do they still provide protection somehow? [EDIT:] - I heard SFs perform terribly without DDboost. We have it licensed and on, but apparently it doesn't work through the cloud gateway product. Not sure if that matters for SFs though.

[foggy]

Last question - does in-line dedupe only affect backup jobs and not once we go offsite to the DD? Seems good to use it then?

Both jobs have this setting, you can enable it for the backup and disable for the backup copy.

is there any value with Synthetic Fulls with a DD? Since all VBKs are deduped against each other any corruption on the actual disks would be ruined anyway right? Or do they still provide protection somehow?

Generally synthetic fulls are recommended, but could indeed be slow. There's a health check to ensure backups integrity.

[EDIT:] - I heard SFs perform terribly without DDboost. We have it licensed and on, but apparently it doesn't work through the cloud gateway product. Not sure if that matters for SFs though.

As far as I remember, DD Boost repositories can work in Cloud Connect, though not recommended due to inability to force recommended settings. Correct, without DD Boost all synthetic activity takes much longer.

[rnt-guy]

As far as I remember, DD Boost repositories can work in Cloud Connect, though not recommended due to inability to force recommended settings. Correct, without DD Boost all synthetic activity takes much longer.

if the time it takes for SF's to finish is too long, is it at all possible active fulls would be faster? The one thing I don't get is why a job holds up others from backing up while it finishing the SF process. I thought the idea is it backs up the latest changes and then builds a full on the backend. It's not copying all the data over again.

Kind of related, but is there any benefit/protection value in doing an active full every once in a while that a SF doesn't provide?

[foggy]

if the time it takes for SF's to finish is too long, is it at all possible active fulls would be faster?

Yes, this is possible and backup copy jobs can do active fulls, if required ('Read from source...' check box).

Kind of related, but is there any benefit/protection value in doing an active full every once in a while that a SF doesn't provide?

Yes, periodic active fulls are always a good practice, if applicable.

[rnt-guy]

Why are active fulls good practice if you're using SF's and health checks? What do they do that SFs run the danger of not doing?

[foggy]

For example, to avoid backup file fragmentation (can be done with the help of compact as well). Active full just reads the entire data from the source instead of synthesizing full from existing backups. Here's more on the need for active fulls.

[rntguy]

Regarding these settings with cloud connect using a dd ... as stated the goal is first best dedupe rate by the dd in the cloud (smallest size used gb after we does it's own management) Second it's fastest backup to the cloud. Restore speed and cpu hit is least important to the customer.

1. Shouldn't backup job and by consequence copy job be set to extreme compression? Or will that hinder dd's performance numbers for using least amount of space? Copy job set to automatic which would copy backup job. Backup goes to 2012. R2 with or without dedupe turned on. I could set backup job to one setting and copy job to another but then it would have to rebuild it before sending it offsite first which could delay it even more. But speed is secondary to bandwidth needs and space utilization at cloud.
2. Should I turn on inline dedupe on copy job so that it uses less bandwidth and then tell cloud dd to decompress upon arrival? Why is it bad to enable this according to article room 2014? https://www.veeam.com/kb1956

[foggy]

Irrespective of the source backup job, it is recommended to enable compression on the backup copy job, but configure the target repository to decompress data before writing it to DataDomain. In this case the data transfer will take less and dedupe rate will be best. Inline dedupe should be disabled for the backup copy job to DataDomain to avoid opening of the entire backup chain on target (less I/O).

[rntguy]

thanks. so i'll leave backup job at extreme, copy job at automatic (which will keep it as extreme), decompress upon arrival on cloud dd, and backup job storage optimization at Local 16TB+ for best dedupe rates by DD.

am I missing something?

[foggy]

Sounds fair.

[rntguy]

thanks foggy, once again

[mtso]

Good morning,
we have primary local backups and secondary backups to a remote Datadomain. We have a 1 Gbit pipe between the local datacenter and the offsite datacenter.

What are the suggested settings for backup to the remote Datadomain?

Type
- Backup job, "configure secondary destination for this job", or backup copy job?

Advanced settings, storage tab
- inline data deduplication: enabled or disabled?
- compression level ?
- storage optimization ?

Thanks in advance.

Tom

[veremin]

- Backup job, "configure secondary destination for this job", or backup copy job?

The first option points to backup copy job wizard, so these are just two (exactly same) ways to configure backup copy job.

Advanced settings, storage tab

Check this thread for recommended settings.

Thanks.

[kaithost]

Hi guys,

i think this fits in here: A customer has got 2 repositories. We are copy-jobbing from each repo to one DD 2500 by DDboost.
Everything looks fine and the data rates are about 400MB/s on 1Gbit links, which is astonishing.

anyway: the DDboost clients on the DD show only one entry for one repository (which is the management host).
I just wanted to make sure that both repositories are using DDboost to the DD. Mostly the copy jobs are running
simultaneously so it's hard to tell if both use DDboost. shouldn't there be two entries on the DD showing both
repositories? or is the client hostname there shown only an alias defined by the management host?

cheers
kai

[foggy]

Any chance the management host plays the gateway role for both?

[kaithost]

The gateway is set to automatic for the DD.
So I guessed it chooses the "nearest" gateway for each repository it's pulling data from.
repo1 should use repo1 as gateway and repo2 should use repo2 as gateway. both are windows hosts and
both are available options to choose from at the gateway config.

[kaithost]

hmmm ... did I hit something here? sounds as if automatic GW is not really automatic.
at least it doesn't choose the optimal path for the data?

[foggy]

If automatic gateway selection is enabled, then mount server specified for the repository should be used (and if the mount server is not accessible, Veeam B&R fails over to the backup server). You're saying DD Boost shows "only one entry for one repository (which is the management host)" - as I understand, the management host is the backup server, so looks like it is used for both repositories in your case.

Anyway, if repository is added as DD Boost and the job to this repository works fine, then it uses DD Boost, no doubts.

[kaithost]

Hi foggy,

just doing a backup copy from 2nd repo to DD. the data is definitely pushed to the first repo and then by DDboost to the DD.
Looks to me as if the veeam transport service is relaying this. but 100% the 2nd repository is not speaking DDboost to the DD directly.
So "automatic" is not choosing the best / optimal way to push data from multiple repos to a DD.

[foggy]

Hmm.. looks like both backup copy jobs are backing up to a single DD repository then. In this case, the same server (mount host specified in the target repository settings) should be selected as gateway. If you create two repositories on DataDomain and point jobs to them accordingly, each should select its own gateway.

[kaithost]

foggy, we can do that, but what is the point of "automatic gateway" setting? This doesn't seem to work as intended.
I'd suggest reviewing this on the product side and enable real "automatic gateway" based on the shortest path from
a repo to a DD. isn't that obvious?

[foggy]

I see your point, but due to some implementation specifics of the backup copy job, gateway cannot be selected the same way it is selected for the regular backup jobs.

[kaithost]

foggy, can you introduce this as a product improvement request? I think we agree on the value of this setting ...