4 weeks later you deduplication database has grown in comparison to the time you've started using dedup. So when a chunk is hased it might take longer to look up the database if it is already present in the storage.
Do you have the deduplication DB on the same physical disks as the storage? That might decrease performance when the DB grows larger.
During the backup you should check the CPU usage on the BE Server (be advised: dedup only uses one core!) and the disk queue length of the volume of the storage and the database. You should be able to spot the bottleneck.
1 Million total fragments sounds large, but you should also check how many files are present and what are the highest fragmentation count for one item (you could check with JkDefrag -a 1 for example.
Also keep in mind: Fragmentation is the problem where the disk drive can not read/write a file sequentially because larger files are written into smaller gaps of free space in the filesystem. No matter how much you defrag your dedup volume: You will always have the situation that the drive has to perform many seeks to read/write data and can not perform standard sequential reading/writing as for B2D! This is because even when writing one single sequential file to the dedup folder the folder itself results in writing data scattered all over the DB and Storage volume, because parts of the file could already be known (e.g. have to be referenced in the DB at a certain location), or new data is written to the dedup container files (at locations where space is available inside these containers [which again is no sequential operation]).
What I am trying to explain: Even if you defrag your dedup folder on a regular basis you always will have the situation that there are no sequential write operations to it, but only changes in certain (different) places where the HDD heads have to seek to (which will take some ms and thus increase the backup duration). If you start over with a new dedup folder almost all data can be written sequentially (as it is new , unique content) which of course will work faster against the above described mixture of small changes at certain locations).
Hope this wall of text is understandable.
However as pointed out before you can give it a try by defragging it, but you should be sure to stop all Backup exec services (and also the BE Pure Disk services and the PostgreSQL Database which is not automatically stopped via the BE Services Manager) and observe the results.
In case you should do so please report the results as the situation described above is mainly theory ;)
