Indexing guest file system - enhancement idea?

[ianbutton1]

Indexing the GFS (guest file system) is often the last stage to finish, taking several times the amount of time that actual backup takes, while the guest is stuck on 99%.
I know that indexing isn't vital - I think it can be switched off if slower access is Ok when restoring individual files.
But it occurs to me that an index of the GFS is already available, in the form of the File Allocation Tables on the guest. Why not just copy the blocks containing the FAT, instead of re-indexing the whole guest? Would that provide the required information?
Thanks

[PTide]

Hi,

In fact, that's exactly how indexing works (at least with NTFS and ReFS) - the process gathers file metadata by reading the MFT data of the filesystem. Would you provide some numbers (how many files do you have on the filesystem, how long does it take to index it), please?

Thanks!

[ianbutton1]

Hi,
1 million files, 75K folders. Just a C: drive, 85GB used, 35GB free. CPU about 10%, so not overstretched.
19 servers in this job, indexing this one has taken >4.5 hrs out of 5+ hrs total
I didn't really want to start a case - it does finish eventually. I just wanted confirmation that it wasn't trying to read & recreate 1 million file entries in the MFT every time - it only needs to do that (using the MFT blocks) if we want a file-level restore.
Thanks

[PTide]

Given the amount of data 4-5 hours is certainly not OK. I would appreciate if you could provide logs so our team can take a look and figure out why is taking that long to index.

Thank you!