Forum Discussion

Symctec's avatar
Symctec
Level 5
10 years ago

BE verify operation slower if backed up to disk than to tape

Hello All,

BE verify operation slower if backed up to disk than to tape. The target disk is a Deduplication appliance.

Any suggestions as it take almost 3 times more time for the verification to complete.

 

Regards..

  • This will not help because the appliance would still need to rehydrate the files before any verification can begin. In fact, a bigger file size will make it worse because you would need more disk space to hold the rehydrated file.

    By using the appliance this way, you get a double performance hit.  The .bkf files will dedup badly because there is no stream handler and you have to spend time doing the dedup.  It would be better to turn off the dedup and use it as a plain disk drive.  Otherwise, if the appliance is supported as an OST device, buy the BE dedup option and use it as an OST device.

9 Replies

  • It could be that the dedup'ed data are rehydrated before the verify begins
  • I see that there are thousands of files checked for during the verification process when backed up to disk, but when backed up to tape only 1 file is verified. I guess only a single backup image is created when backup to tape.

    Is there away I can reduce the number of files that are verified by increasing the max file size from 4 GB to a higher value?

    What is the recomended max value for the file size? Any thing to be careful of when increasing this value?

    Regards

  • A dedup folder does not have any file size parameter
  • The Backupexec just uses the appliance as CIFS mounted storage, the dedupe is done only internally on the appliance. So its basically a backup to disk configuration. I saw the default file size was 2 GB, we have increased it to a TB and monitoring the performance.

  • This will not help because the appliance would still need to rehydrate the files before any verification can begin. In fact, a bigger file size will make it worse because you would need more disk space to hold the rehydrated file.

    By using the appliance this way, you get a double performance hit.  The .bkf files will dedup badly because there is no stream handler and you have to spend time doing the dedup.  It would be better to turn off the dedup and use it as a plain disk drive.  Otherwise, if the appliance is supported as an OST device, buy the BE dedup option and use it as an OST device.

  • Stepping back from the question to a different question, what benefit do you feel that you are receiving from verifying the on-disk backups.  The original point of the verification process was to verify that the data written to the tape could be read.  Tapes have a much higher probability of read failures than disks.  And the disk subsystem has redundancy built in to it.

    I would offer that you skip the verify step for disk-based backups.  The rehydration process is extremely I/O intensive as the data needs to be read from scattered places on the disks (random read) and re-assembled.  By comparison, the deduplication process is streamlined because it deals with hash values stored in memory.

  • From my understanding, if you do not verify your backup and later find that you cannot read the data, you would not get any help from Symantec
  • Apart from PKH who highlighted tech support issues may come up if verify operation is not done, the customers are sometimes not very technical. Ofcourse we can try to make them understand the impacts of verify oepration in a deduped appliance, but they just question the previous performance to the current one and dont bother about what technology you put in. As of now they agreed to run verify as a seperate job during office hours to stop any degradation in bkp performance. This I see more as the appliance issue than BE. Would have been really happy if Symantec officilly says no need to run verify if backing up to disk :)

  • Veeam does this too and their primary target is disk. All vendors do a verify, or recommend this, as it protects the client and themselves! Thanks!