Relationship Between Performance and Number of Incrementals?

[brupnick]

When I received the email notifications that my backups had finished the last two days, I was very pleasantly surprised to see that these jobs were running 3-4 times faster than they were last week. Nothing has changed on the hosts, vSphere server, VBR servers, storage, etc. The only change that comes to mind is the fact that I ran a full last Friday, so these were the first two runs since that full.

So my question, which might be very basic, is this: Is there a relationship between performance and the number of incremental backups? I'm using traditional incrementals with scheduled full backups once a month, so will I see my performance degrade as the number of incremental files increases?

[foggy]

If there was such a relationship, forever incremental backups would take really forever. Seems like your VMs just produced less changes than they did last week. Thanks.

[brupnick]

Thanks foggy. I wish I could say that was the case, but the resulting data files are only a few gig smaller than those of the previous weeks. And I had the same thought about the forever incrementals, but thought that maybe Veeam had a sense of humor.

[Gostev]

Actually, you may indeed see some degradation as the number of incremental backups in chain grow, as the job needs to read metadata from each backup file in chain. However, this is typically unnoticeable - unless you are backing up to deduplicating storage device (it takes the storage some time to "rehydrate" the data before returning it).

[tsightler]

Yep, I see it fairly often. If you have a very long incremental chain (not recommended) it can get to be very noticeable. The most common scenarios I've seen where it gets to be an issue is with dedupe storage (exactly as Anton said), or a couple of cases of running a full once a week, but then performing hourly incrementals, which obviously creates a very long incremental chain by the end of the week.

[brupnick]

Yep, I see it fairly often. If you have a very long incremental chain (not recommended) it can get to be very noticeable. The most common scenarios I've seen where it gets to be an issue is with dedupe storage (exactly as Anton said), or a couple of cases of running a full once a week, but then performing hourly incrementals, which obviously creates a very long incremental chain by the end of the week.

Tom, what do you consider a "very long" incremental chain? As I mentioned, I'm doing daily incrementals with monthly fulls, so I only have about 20 incrementals before my next full.

[tsightler]

I think the difference is measurable with 30 incrementals, but I've rarely seen it become an actual issue (exception might be a backup job with a high change rate) and I would say it's pretty common for people that are performing active fulls to have a 30 day incremental chain, assuming one backup a day. Chains like the one I mentioned above (100+) can be a performance issue however, but I wouldn't recommend more than 30 or so anyway just from a data integrity perspective.

[brupnick]

Thanks for all the responses. I'll see how it goes for the rest of this week and next.