We are facing slowness during merge operations.
Same results with all jobs, proportional to the size of the job.
We use a physical proxy/repository connected to a SAN.
- Proxy reads vmdk files in Direct Storage Access mode.
- Repository uses SAN Storage allowing more than 250 MB/s
Jobs are configured as Forever Incremental, with 30 restore points kept.
Let's have an example of a job result :
- Full VBK file is 2,5 To large
- Incremental VIB file has an average of 185 GB
- Incremental backup itself (without merge) needs 70 minutes
- The Merge operation needs 400 minutes, 5 times more than the backup itself.
I tested a VIB file copy on same volume (generating both read and write I/O), and it took less than 10 minutes.
Then it is not due to the storage performaces.
How could we explain such slowness during merge ?
I have detected 2 amelioration points :
- Reformat the storage volumes with a 64 K cluster (currently 4 K)
- Enable the "Defragment an compact full backup file" option
First point will be complicated, as we need to find space to move backup files during the operation.
However I have no idea about the expected savings : 5% (which won't solve our problem) or 80% (which will reduce the merge duration to the backup duration) ?
Any idea about the cause of such slowness and the way to reduce is is welcome.