Slow Backup to Dedupe Device

[deduplicat3d]

Hi,

I worked with support for a long time on a problem I have (case 5168243). Ultimately they said there was nothing they could do and recommended I go to the forums for information about future versions.

So my problem is that the config files (vmx, vmxf, nvram) take forever to backup (2-5 minutes), each hard drive also takes several minutes before it begins to back up. Once it starts backing up the vdisk, it is very quick. Rustam from R&D finally explained that this is due to the fact that before the agent puts anything in the backup file, it reads ALL metadata in the chain. He said that metadata is written in 2MB chunks throughout the file causing a lot of random I/O which is hard on my dedupe device. (I have a Quantum DXi 7500).

My problem persists with CIFS and NFS (I do not have the option for iSCSI).

I split my jobs up which helped, but it's still bad.

I am running active fulls weekly with increments every day between.

Has Veeam considered writing this metadata in a separate file to prevent so much random I/O. Do you have any other suggestions, as this is becoming a real big pain. I am required to use the dedupe device for investment reasons as well as the fact that I am writing to tapes so I need to do incremental.


Thanks,
Corey

[tsightler]

Is this with V6? With V6 the metadata is kept in a separate file.

One option is to use a "staging" method for backups, i.e. write backups to a non-deduplicated store, and then use a post job script to copy them to the dedupe appliance.

[deduplicat3d]

It is v6 and the metadata you are referring to is different than what I am.

I've considered a staging area, but it has severe limitations such as extra time taken and the inability to reference the old chains automatically in Veeam.

Thanks!

[tsightler]

Certainly the stating area does cause some extra time, but there's no reason you can't still reference the old chains in Veeam, although it does require some manual setup. You can simply create a repository that references the "archive" location and use a PowerShell script to rescan the repository each day (or every hour, or however often you like). This way the archive backups are still available directly in Veeam.

[deduplicat3d]

So the powershell script would import the vbm (bringing in the whole chain)? Do you have a sample script for this?

I would still appreciate an official response from Gostev or the likes.

Thanks
Corey

[deduplicat3d]

I hate to be naggy but could I get a mod to please reply to my original question.

Thanks
Corey

[foggy]

Corey, please look through this topic discussing the similar problem. Have you maybe upgraded recently to v6?

[deduplicat3d]

Foggy,

Thanks for the response. I have actually already seen that forum post as it was the only other post I could find on the issue. I installed v6 as a fresh install on a new server with new jobs.

Thanks
Corey

[cdickerson]

Was seeing the exact same thing with a Data Domain. I created a NEW job and disabled compression and deduplication and choose a Incremental job type (not reverse). Accessing via CIFS share.

-Craig

[deduplicat3d]

I am using incremental. In previous posts, Gostev recommended using Low compression and leaving deduplication on. I am using those settings. How long does it take to back up your config files now?

[cdickerson]

It now takes seconds (2-5) where it was taking a couple of minutes before.

[gvinpin]

Using Data Domain.
Incremental with weekly full.
Very fast over 10GB network.
Compression and de-duplication are disabled, Storage Optimisation set to LAN Target.
Backing up to CIFS share.