DataDomain As a Primary and GFS Storage

[smurugun]

Hi,

Please find my below architecture and give me the advise for the recommended configuration.

1. Vshpere 6.0 with 2 VMs having 1 TB Data Each
2. Veeam B & R 9.0 U1
3. DataDomain 2200 with DD boost (there is no additional repository)
4. Primary storage DataDomain - Cifs, Secondary storage Datadomain - DDboost( for GFS retention )
5. Backup Policy,
Backup job - Forwarder Incremental - 7 restore points
Weekly - Thursday synthetic full
Monthly - Active full

Backup copy - Restore points 7
Weekly - 5
Monthly - 12
Yearly - 1

- Backup job is going fine with CIFS @ 260 Mb/S, but backup copy jobs are running very slow like 26 Mb/S

how to improve the Backup copy job speed. Please advise,

Thanks in advance.

[Gostev]

Hi, depends on the bottleneck statistics for backup copy job - basically you need to improve the weakest element it shows. Thanks!

[Shestakov]

Besides bottleneck statistics, what is the WAN link bandwidth the sites? Do you leverage WAN acceleration?
Thanks!

[jeremy.porter]

Hi Smurugun,
I have came across this too, and seen it a few times.
A flaw that you will find when doing a Backup Copy Job back to the same DataDomain for GFS is that it is NOT DDBoost'ed.
In fact is completely the opposite and the performance sucks, I'm guessing as it has to both read/re-hydrate and de-duplicate/write the data within itself at the same time as it is transferred from the primary repository to GFS copy.
We were hoping this would of been fixed when v9 came out, but wasn't maybe v9.5 or v10?
To get around this just ended up having three separate backup jobs for each of the retentions (daily-weekly / end of Month / end of Year) as running an Active Full which DOES use DDBoost takes only moments compared to many weeks that multi Terabyte Backup Copy takes dribbling along at around 10 to 20Mb/S.

[veremin]

A flaw that you will find when doing a Backup Copy Job back to the same DataDomain for GFS is that it is NOT DDBoost'ed.

Just to clarify - the same device is added twice to a backup console? As a repository for backup job and as a repository for backup copy job? Thanks.

[smurugun]

YES. the same device added twice.

because we don't have a storage space other than the Datadomain. with datadomain we need to store the data with GFS policy. we dont have any offsite storage or Tape loader.

Please let me know if there is any other way to have backup data with GFS on Data Domain as above explained my architechture.

FYI,

Backup Policy,
Backup job - Forwarder Incremental - 7 restore points
Weekly - Thursday synthetic full
Monthly - Active full

Backup copy - Restore points 7
Weekly - 5 Full Copies
Monthly - 12 Full Copies
Yearly - 1 Full Copy

Thanks.

[Gostev]

I don't see any other way if you literally don't have any other storage.

However, you have very little data to protect as far as total size, so really you should very easily be able to "do it right" instead of storing all your backups on the same storage device, which is a huge risk. I would recommend following our reference architecture and creating a primary backup repository by adding a couple of large hard drives to any server in your environment. Then you would have primary backup job backing up to this repository with a very short retention policy, and then perform a backup copy to Data Domain. This way, you will have 2 copies of your backups on different devices.

Thanks!

[AlexandreD]

Hello

I ask myself the same questions. We need to backup an increasing number of VMs, currently 1400VM, 600TB at source.
The use of datadomains often comes up in discussions around backup. but I read a lot of inconvenience on the forum. Poor performance when recovering VM. Poor performance on backup copy job.

It seems that the new datadomain models have SSD for the cache, that should help these operation.

I am interested if some have benchmarks around datadomain? (model, number of simultaneous tasks, number of proxy vm with ddboost, dedup / compression rate, time for an active full with the volume at source / read / transferred, recovery VM time)

Thank you for feedback
Alexandre