It's certainly nice to hear it is in development, but hoping it will come sooner rather than later.
Regarding the frequency of reclamation, as I said in my original post, we have space constraints to deal with. Our old backup application was scheduled to back up VMs weekly, but we would backup SQL databases nightly. Since Nakivo has no "agent", we have to back up the entire VM nightly; yeah we could create a job for the drives containing SQL, but that is where most of the change occurs anyway, so we keep it simple. We actually prefer the simplicity of the scheduling now and the nightly backups of entire VMs, but the testing of Nakivo in our lab didn't accurately predict the dedupe ratio's we would see in production. Separate backup storage is not available in some of our smaller, shall we say fiscally-challenged, environments so the repo is placed on local SAN and then replicated off-site. The amount of available SAN storage is limited, and with the slightly lower than expected dedupe ratios, we get close to running out of repo space after a few days if we don't run reclamation after our backups. We have SLAs around retention, so I'm keeping the bare minimum.
As was mentioned in a diffent thread, the reclamation process reclaims a good portion of the available space early on in the process. Thus, with my current scheduling, I get a very good return on my reclamation period even if it gets interrupted by the next day's backup scheduling.