Reverse or forward incremental

[mikeyjm26]

Hi guys,

While doing my daily backup checks today I noticed that our cloud copy was still running a health check from the weekend and this, in turn, stopped the other copy jobs from running. This got me thinking that there must be a quicker and better way to do this. I have set up my backups for reverse incrementals to a NAS that is attached to our Veeam server via iSCSI but according to some this is wrong because of the high I/O required and that I should be probably be using forever forward or forward incrementals. We are only a small company with about 3Tb of data.

By switching to the forward incremental, I assume you can do this without having to delete/redo the backup, that it would cut down the amount of time for a health check as it would only be checking the change and not the full backup.

Would it be worthwhile changing or am I missing something?

Thanks

Mikey

[foggy]

Hi Michael, health check always verifies the latest restore point, so it's performance doesn't depend on the backup method. Backup itself though should complete faster with forward incremental due to less I/O load it puts on the target storage.

[Andreas Neufert]

The difference for backup processing.

Revers incremental always copies data to the incremental file during VM backup (1 write 1 read 1 write). During that time the Repository and Proxy task slot is reserved and the VM snapshot is as well present.

With Forward incremental you will have during backup 1 IO at the target, then you close the proxy/repo task slots and the VM snapshot. At the end you perform the merge ( additional 1 read 1 write).

So your backup window will be smaller (which gives you more time for healthcheck) with Forward Incremental as at backup more things can run parallel.

From health check there is no difference in speed.

[vmtech123]

Interesting. I was having issues with health checks taking a VERY long time. We have VM's over 10TB in many cases. With pretty fast storage and dedicated physical proxy, storage snaps etc it was still taking days.

I switched to reverse incremental and life has been wonderful. Health checks are much faster, Surebackup doesn't time out. Plus when I want to restore individual files things are much more snappy. With incremental doesn't it have to combine the chain to do all of these operations making it take longer, where as with reverse it just hast to check the latest file which will be the full backup?

[Andreas Neufert]

We build a matrix for any restore point that you use and this will take some time 2sec up to 30sec. But from there you should not see any performance differences.

[mikeyjm26]

Thanks for the input. So how do you speed up health checks and also merging of data. It is taking an age on our system. I am running our Veeam server 2012 R2 using a single core E3-1220 v3 cpu with 16Gb of RAM. The health check that was running yesterday was at 34% is now at 51%. No other copies are able to be done which means our off-site backup plan is not being adhered to.

[Andreas Neufert]

Our support has some options to check if the speed is related to the storage or software and we can work from there. Can you please open the ticket and share the ticket number here so that we can follow up in the backend?

[PetrM]

Hello!

Yes, it's a good idea to ask our support team to check if the speed is related to the storage or software.

However, let me please share a couple of ideas:

I switched to reverse incremental and life has been wonderful. Health checks are much faster,

Health check procedure verifies the latest restore point, latest state of VM and it does not always mean: latest backup file.
Data blocks which represent the VM latest state can be spread out across several backup files in case of forward incremental chains and health check needs to read blocks from several files.
On the other hand, when reversed chain is used, the latest VM state is always stored in full backup file so health check reads data from a single file.
That's why you could sometimes notice performance difference when health check verifies restore points from different chains.
But in most cases health check speed doesn't depend on backup method.

It's always better to make sure that the correct block size is selected at the level of backup job settings.
4096 KB (Local target (large blocks)) is recommended for backup files that are larger than 16 TB. One more benefit is that you need less blocks to check when large block
size is used so the total number of read and hash check operations is decreased and health check might be faster.

Thanks!

[mikeyjm26]

Thanks, case ref is 03836542.

[vmtech123]

On the other hand, when reversed chain is used, the latest VM state is always stored in full backup file so health check reads data from a single file.
That's why you could sometimes notice performance difference when health check verifies restore points from different chains.

The reverse was defiantly helping due to re hydrating. Restores and health checks seemed to improve on all jobs.

When I use large blocks the performance increase was significant also. I hit a record (for me) of 3GB/s. It's a balancing act however, as my dedupe will less with large blocks, and I require a longer retention. Guess I need to buy some disk

[PetrM]

Hi Scott!

Yes, that's true.
The probability to find identical blocks is lower when large block size is used and deduplication ratio is reduced as result.

Thanks!