VBRcatalog sizing and clean up of compressed files

[Bredero]

From my veeam training I seem to remember that we should size 100MB per million files indexed on windows systems for the VBRcatalog. I think the best practice guide used to say the same.

We noticed that the VBRcatalog is growing at a much larger rate and was about 60GB after 2 days of indexing. Worried if we should plan for several TB of disk space on both VBR and EM for the VBRcatalog we investigated.

Seems like per machine we get .ifd files per volume and summary.txt which are then compressed into GuestIndexData.zip. What we noticed is that initially these .ifd files are not deleted after compression. Now at day 3 we see that for the older indexes these source files are deleted and only the GuestIndexData.zip remains and only for the last 2 days (restore points) all files are still stored on disk.

I've tried searching but haven't been able to exactly find this process described in the user guide or elsewhere.

Questions:
- Are we right in thinking by default veeam doesn't remove .ifd for the first 2 restore points even if they have already been compressed?

- If so, can anyone share the reason for this behavior? Is it performance related?

- Is there a registry setting that tweaks this behavior?

Thanks!

[PetrM]

Hello,

Basically, this is the behavior by design: we store non-archived data for last 48 hours and if I'm not mistaken the search engine performance is the main reason. You may try to change the value of parameter KeepUnpackedInHours (f.e. set 24) in this file: VBRCatalog\Index\Machines\unpacked_data.txt on both Veeam B&R and Enterprise Manager servers. You may also restart Veeam Guest Catalog Service on both servers to apply the change immediately.

Thanks!

[foggy]

A couple of topics for further reading regarding VBRCatalog size handling: cleaning up vbrcatalog folder and VBRCatalog folder growing in size.

[Bredero]

Thanks for the swift and clear responses. Appreciate it!