Long incremental-forever backup chain

[Moebius]

I used to backup the main file server of a company (about 1.5 TB) using reverse incremental backup type, once a day, keeping 10 restore points, with a specific job that has this vm only in it.
With v8 I changed the backup type to forward incremental forever and I'm happy wwith the outcome. (I monitored the overall backup times once the merge started occurring and on the average it's slightly less than with v7 reverse incremental mode.)

Now I've been asked to change the backup schedule from once a day to every hour, and to keep 10 days worth of restore points. That would make, of course, 120 restore points.
Should I worry about the time and/or memory needed for an instant recovery or guest file restore of the latest backup run (which means that the server has to go through 120 files to put everything together) or this is nothing to worry about?

In case such a long chain is not recommended, an option could be to shorten the backup job chain to, say, 3 days and use a daily backup copy job to go 10 days back. Not the same thing but maybe a viable workaround.

What do the Gurus recommend?

[veremin]

Should I worry about the time and/or memory needed for an instant recovery or guest file restore of the latest backup run (which means that the server has to go through 120 files to put everything together) or this is nothing to worry about?

You're likely to face some issue with extremely long incremental chain, which doesn't seem to be the case in your situation. Thanks.

[Shestakov]

Lucio,
One possible trick to significantly reduce the number of restore points (hence restore time) in a chain is to split them to 2 backup jobs using backup window opportunity.
It will cost an additional full backup, but shorten a number of restore points in a chain from 120 to 60.
Thanks!

[Gostev]

Hi, Lucio.

1. Large amounts of increments with reversed incremental backup is basically "tried and proven", this works excellent.

2. To be honest, there is simply not enough statistics yet for forever forward incremental backup, because this backup mode is so new. Long chains are definitely NOT "not recommended", but it may have potential performance impacts for both backups and restore (for example, due to metadata handling mentioned above). It does not mean that YOU will necessarily run into the issues though.

We have tested large chains internally and this worked fine, but there seem to be corner cases when large amount of VMs with huge metadata blobs (for example, when most VMs have apps installed supported by Veeam Explorers, and application-aware processing is enabled). They especially impact slow storage (such as dedupe storage), but may have some impact on raw storage as well. We've build some optimizations for metadata handling that were essential for dedupe storage, and in the end decided to apply them to all storage types in the next update.

Thanks!