cancel
Showing results for 
Search instead for 
Did you mean: 

Verify job speed varies on data type in backup job?

PiotrB
Level 2

SBE 15 (version 14.2, backup server on separate machine, Windows 2012 R2, 64GB RAM, DD used capacity 6TB)

All my backups goes to deduplication store and are verified in separate jobs to mimimize backup windows. Backups are working fine. But Verify speed vary:

  • 4GB/min (verify of virtual machine with Linux backup, GRT disabled in backup),
  • 5,3GB/min (verify of physical file serverbackup)
  • 1,5-2,5GB/min (verify of virtual host backup with large VMs with MSSQL inside, GRT enabled in backup job)

(no another jobs running when verify is working, results are repeatable in time)

IMO verify jobs should run at constant speed - this is read process in dedupe store. But above results are varied (GRT is looking inside VM/SQL in verify job?). How can I speed up slow jobs? Is something wrong with my jobs setup or DD store?

Thanks for any suggesion.

2 REPLIES 2

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

Well the data types will result in verify performance differences (mainly but not exclusively because of the differences in average file sizes that go with the data types)

 

Verifying from deduplication would typically also be slower then verifying from Backup-to-disk (B2D)  due to rehydration prior to checksum validation

 

There is one other parameter that is probably affecting you

For non-GRT backups the verify read is done directly from the Deduplication Store itself, for GRT backups the verify will probably use the PDVFS 'filter' driver to access the VDMK/VMX/EDB/MDB object from the 'virtual' \\.PDVFS share (which then rehydrates in the background)  but means another layer of read processing is taking place.

It might be even worse for application GRT inside virtual GRT as, the actual process might be use PDVFS filter driver to access the VMDK, then use the VFF filter driver to access the VMDK content, then use VFF again to access the Exchange/SQL content (note I am not sure all these layers are used for a verify, they are all used for an individual file restore so may be used before a verify and at least mentioning them does explain that GRT has a lot of extra layers of processing)

Hello! Thanks for Your comprehensive answer!

But when I move systems (with SQL, Exchange - with GRT) from physical to virtual (and from tapes to DD store) the overall backup+verify+catalog time grows. Especially verify process is slower then from tape, although my DD store is fast. This is an undesired effect.