Verifying Dedup data taking a looooooonnnnnngggggg time

[burtos]

Is their anyway of increasing the speed of the verify process of a deduplication storage folder


At the moment we are testing the dedup option and backup  750gb of data which takes about 8.5 hrs than when it comes to the verify bit this takes 10.5 hrs to complete

Backup Speed is 1401 MB/Min
Verify Speed is 1158 MB/Min

Any suggestion if possible would be appreciated.

[CraigV]

Hi,

With a verify, the software checks that what you have on your backup media is in a consistent state with what was backed up. Generally a Verify operation takes as long as a backup.
There is no way to speed this up specifically, but you can look at creating a Verify job to run AFTER your backup. That way the backup completes, and the Verify runs separatelt.

Laters!

[teiva-boy]

You are not supposed to verify the dedupe storage folder!  By doing so, the data has to be rehydrated.

You only verify tape.

[burtos]

but you can look at creating a Verify job to run AFTER your backup. That way the backup completes, and the Verify runs separate lt.

This is what i have already have set up, the verify runs straight after the backup job


You are not supposed to verify the dedupe storage folder!  By doing so, the data has to be rehydrated.

I get mixed views on this, but looking on the symantec website, they actually state that you should always verify your backed up data after every job.

Also looking on a other post that you suggested the same as not to verify your backups

https://www-secure.symantec.com/connect/pt-br/forums/backup-exec-2010-deduplication-storage-folder...

I always verify the backups just to make sure the data is good and not bad in any way.

[teiva-boy]

Think about what the verify is doing.

It's looking at each block written to the media and comparing the hash of the block to make sure it's not corrupt.  It's not comparing the written data to what you backed up.  Oh we could only wish!

If you have an idea that data written to disk is in jeopardy, then yes you should do a verify, but also should buy better disk as a permanent fix.
Tape on the other hand is not reliable, thus a verify is a good idea.

Symantec's statement about verification is their CYA.  In the real world, and best practice you do not verify the dedupe folder, you optionally verify B2D, and you 100% verify tape.  Ask DataDomain, Quantum, Exagrid, they all tell you to turn off verify operations.

Also the PureDisk binaries that BackupExec uses for dedupe, already does numerous scheduled checks of the data twice a day as part of maintenance tasks.  So again, I stand by, you do not verify the dedupe foflder.

[Larry_Fine]

re:  but you can look at creating a Verify job to run AFTER your backup. That way the backup completes, and the Verify runs separate lt.

This is what i have already have set up, the verify runs straight after the backup job

I believe that Craig was referring to creating a policy backup, which allows you to schedule the verify X hours after the backup.  Therefore the verify doesn't run immediately as part of the backup and use up your backup window.

[Sean_smith1]

Hello, 

I couldn't create a new post because of a bug with Symantec site so thought I would tack it on the end of this one.

I am having a similar issue with performance of the dedupe folder on backupexec 2010 when performing a verify or replica to tape of a dedupe backupset.

Initially performance of these processes were good  1560Mb/min  over time these performance benchmarks bounced around but trended downward.  Then the performance dropped down dramatically and operates at between 12-15mb per minutes..

I have defragmented the drive and  read the best practices document without having any clues. Performance monitor does not indicate any issue with disk queue's, or cpu utilization. Memory utilization is quite high due to a couple of other applications on the server but there is no excessive paging

Any tips?