v8 New Forward Incremental-Forever Backup confusion

[stormlight]

I learned about Forward Incremental-Forever Backup from Luca in the new V8 and I want to try it out.
Great post describing it here as well as the other modes. http://www.virtualtothecore.com/en/new- ... cation-v8/

It took my a while to figure out how to set it since its not clearly labeled on how to do it by looking at the Veeam interface. To set it you choose incremental but then uncheck create synthetic backup.(This could be improved by having a 3rd checkbox that says " Forward Incremental-Forever Backup")

My questions after understanding that Forward Incremental-Forever Backup is basically the same as reverse incremental in IOP usage and storage savings but is faster at committing the vm snapshot are:

1. Why would someone choose reverse incremental over Forward Incremental-Forever Backup ?
2. Both Forward Incremental-Forever Backup and Reverse incremental use 3 IOPS per byte. Why did Veeam decided to label reverse as "slower" in the interface when choosing the mode.
3. Why would someone want to check the box "create active full backup periodically" when using Forward Incremental? Doesn't that defeat the space savings and causing another read of the data on the SAN?

Thanks so much.

[tsightler]

1. Why would someone choose reverse incremental over Forward Incremental-Forever Backup ?

Properly designed, reverse incremental is still a great backup mode and includes that benefit the the most recent restore point is always the full VBK file which can be very beneficial and can be easier to recover from cases where a repository might run out of space (just copy off/delete old points). The biggest disadvantage to reverse incremental has always been it's I/O requirement during the backup, since it requires doing those 3 I/Os while the VM snapshot is open, but I work with many, many large clients that already use reverse incremental very successfully. Reverse incremental can also be a benefit when you have cases with very long backup chains (i.e. 100's of restore points).

2. Both Forward Incremental-Forever Backup and Reverse incremental use 3 IOPS per byte. Why did Veeam decided to label reverse as "slower" in the interface when choosing the mode.

Technically reverse incremental is "slower" during the backup process itself. With reverse incremental all 3 I/Os happen during the backup process itself as each changed block is written to the repository. With forever forward during the backup process itself there is only 1 I/O to the repository, a single write, which means the VM backup will complete much faster, the other 2 I/Os are performed "post-process" during a merge at the end of the job. The fact that it's a simple 2 I/O load can actually cause the overall process of "backup + merge" to be faster than only "backup" in reverse incremental, but in virtually (hah, a pun) all cases the backup portion itself will be faster.

3. Why would someone want to check the box "create active full backup periodically" when using Forward Incremental? Doesn't that defeat the space savings and causing another read of the data on the SAN?

Some customers have policies that require active full backups or sometimes things happen like a large VM being deleted and you want to eventually free the space to the filesystem. The only way to do that is to create a new active full backup, but indeed it will need additional space. It's important to keep in mind that selecting active the full backups option causes Veeam to revert to the traditional incremental retention and thus you will indeed need more space. That could even be another reason why some customers will choose reverse incremental.

[stormlight]

What a quality reply. Thank you!

[RGlintmeijer]

About freeing space with Reversed Incremental, does this also count for the Incremental-Forever? In other words, can the VBK get smaller after a Merge/Transformation? Or do you always need an active full backup to free te space of deleted VM's?

[veremin]

Or do you always need an active full backup to free te space of deleted VM's?

Correct. But we are considering to add full backup compact functionality (same as in Backup Copy job) for primary backup jobs in the following releases. Thanks.

[Gostev]

Technically reverse incremental is "slower" during the backup process itself. With reverse incremental all 3 I/Os happen during the backup process itself as each changed block is written to the repository. With forever forward during the backup process itself there is only 1 I/O to the repository, a single write, which means the VM backup will complete much faster, the other 2 I/Os are performed "post-process" during a merge at the end of the job. The fact that it's a simple 2 I/O load can actually cause the overall process of "backup + merge" to be faster than only "backup" in reverse incremental, but in virtually (hah, a pun) all cases the backup portion itself will be faster.

I'd like to expand on this answer, since I was the one who wrote the UI label in question anyway

Here is exactly what I had in mind. Reversed incremental mode is, for the fact, quite noticeably slower than forever forward incremental backup mode in terms of total job run time, because with reversed incremental jobs, VM snapshots grow 3 times larger, and thus take 3 times longer to commit. And snapshot commit time adds significant contribution to overall job execution time. Hope this makes sense!

[stormlight]

Yes, that makes sense now. I know a number of guys in my office were confused when reading the UI label also. Good luck with fitting that description into the label

As far as my other UI gripe I have also had 3 customers so far ask how to set Forward Incremental-Forever Backup up since it wasn't a new checkbox in the UI. When I tell them that they need to uncheck "Create synthetic full backups periodically" the first thing all 3 people have said was " I dont want to just back up incrementally for ever".

That UI may need some work

I noticed that Forward Incremental-Forever Backup is not always the default when you have upgraded from a previous version or have jobs already in Veeam.

[Gostev]

Correct, we never touch existing settings during the upgrade on purpose.

In our mind, ideal upgrade is when nothing changes in the way our product behaves.
Only when you are ready, you can go ahead and take advantage of the new features.

[stormlight]

I'm talking about new jobs, not touching existing ones.

We have noticed that when upgrading that we would expect newly created jobs post 8.0 upgrade should default to forever forward. However they don't.

[Gostev]

This is unexpected. Perhaps somebody clicked "Save as Default" with a different mode selected on the advanced job settings dialog after v8 was installed (while checking out this other new feature)

[averylarry]

... because with reversed incremental jobs, VM snapshots grow 3 times larger, and thus take 3 times longer to commit. ...

I think you misspoke (mis-typed?) there. Just because the snapshot is there for a longer period of time does not immediately mean the snapshot will be larger, nor does it mean the snapshot will take longer to commit. It's very likely for it to be larger and take longer. Could be 10% more, could be 20 times bigger.

A tangent for interesting math -- the snapshot size cannot have a linear relationship with time on a long-term average.

[Gostev]

Sure, I realize that. This was oversimplified on purpose just so that people can more easily get the idea. Plus, I really don't care about being scientifically correct in every detail now that I have to answer a few dozens of topics in a couple of hours every day (I only get a chance to do forums in my free time from home). Huge activity increase on our forums now that v8 has been released!

[scott.lundberg]

In regards to the Forward Incremental-Forever option:

Prior to v8, we were trying to do something similar with cloud backups so that we didn't have to upload synthetic fulls to the cloud. This obviously blew up at some point when the cloudberry app tried to copy the files to AWS while the Veeam server was trying to roll it into the synthetic backup.... Anyways, during that ensuing support call, I was told that forever incremental was extremely dangerous because if you ever had to do a full recovery say a year down the road, you would have one full + 365 incrementals. The time and processor expense to restore the full VM from that combination would be too much for today's hardware.
Is that still the case for v8? Does Veeam still recommend that we create Active Fulls at least once per month?

[Gostev]

if you ever had to do a full recovery say a year down the road, you would have one full + 365 incrementals

Primary jobs are not built for long retention. With such data retention requirements, you want to do Backup Copy jobs with GFS retention, as it ends up being both more space efficient than forever-incremental chain, and more reliable (GFS backups are separate, independent and self-sufficient restore points, which protects you from bit rot).

[dellock6]

And if you want to really optimize offsite backups and most of all restores, you should really look into Veeam Cloud Connect. its computing components deployed at service providers help to just move across the wire the least amount of needed blocks for any operation.

[florian.meier]

Hi guys

Sorry, im littlebit confused about the "active full backup". Please help me to understand:

reverse incremental backup:
if i create for example quarterly a active-full backup in this mode, this will not use any additional space.
so the active-full backup is integrated into my normal reverse incremental backup, right?

forward incremental-forever backup:
if i create here a quarterly active-full backup, this backup needs additionally space and cant get integrated into the forward incremental forever backup, like
it was in version 7 with the normal incremental backup, right?

thank you for clarification.

[foggy]

Active full backup always starts the backup chain anew and requires additional space, regardless of the backup mode. All previous restore points are subject to the specified retention settings.

[florian.meier]

Hi foggy, thank you for help. But that means, in a reverse incremental backup set, the space is not used twice, because the newest backup is then the active full backup and all ealier backups are increment backups which belong to this, right?

[foggy]

No. The newly created active full is a completely new file, which is independent of the previous backup chain. So you will have two full backups on disk after it is created.

[florian.meier]

Ok. But i cant understand why veeam is saying, that is recommented to create an active full to avoid corrupted chains, when it creates a new backup indipendend of existing chain?

source: http://forums.veeam.com/vmware-vsphere- ... 13479.html

[foggy]

This was recommended to protect from possible corruption being built into the vbk file and carried forward into subsequent restore points. Since active full re-starts the backup chain by copying the entire VM data from the source storage, it does not have that corruption anymore.

However those recommendations are not the case anymore, please see below for details.

[florian.meier]

Ok thank you for clarification.
If I click on your link the follow error message appears:

You are not authorised to read this forum.
Would be great if I could read this post..

[foggy]

Sorry for that, that was the link to internal forums. I'm quoting the entire Anton's post below:

While "We" indeed had this recommendation many years ago, it's no longer the case.

Now "We" recommend the ultimate VM backup architecture:
1. Short retention on fast primary storage.
2. SureBackup of backups on primary storage (recoverability testing).
3. Backup Copy to secondary backup storage to meet 3-2-1 rule (using GFS for data retention longer than a few monts).
4. Backup Copy job's health check to detect any backup file data corruptions that may have happened in-flight, or at rest on either side.

Specifically to Active Fulls: I don't recommend scheduled Active Fulls at all, but perhaps doing them manual only, as needed only in the following circumstances:
a) SureBackup detects unrecoverable backup, or backup file data corruption.
b) You want to reduce VBK size (after rearranging jobs or deleting lots of VMs), or its fragmentation.

And remember that Backup Copy jobs do recovery from (a) automatically, and can do (b) periodically with Compact functionality, which is the reason why we don't even provide the ability to perform Active Full on Backup Copy jobs.

[igarcia1]

This question probably best fits here. Veeam is currently running an incremental that is going to top out at about 6TB - not sure exactly why, some combination of invalid CBT data and other major shifts in data on some of these volumes. It got me thinking about the few cases where I've had a smaller vbk than the vib being committed/transformed. Would Veeam write the 6TB vib onto a 1TB vbk, or is it able to reverse the process to save time and commit 1TB file to the 6TB file, making it the new vbk (if that is even possible)?

[foggy]

When full backup reaches the day the corresponding VIB file is created, data blocks from VIB are injected into the full backup file (not the other way around).

[AlbieNorth]

Having read through this long thread, I have to say (as a newbie) that even though I mostly understand the various methods, I am still confused as to which is "the best" (which I realize is different based upon whether the goal is faster backups or less space). Is there a summary some place to bring me up to speed on the current status of the different methods under ver 8 so I can read that and try to decided on a change (the previous IT guy set these up as forward incrementals).

Thanks.

[Gostev]

There is one in the sticky FAQ topic, but here is the newer version updated for the v8 FAQ (feedback is welcome).

[JeremiahS]

I upgraded a few days ago and am converting all of our reverse incremental jobs to forever incremental followed by an initial Active Full. My question is around why the "Finalizing" process takes so long on an Active Full? I understand the 2 I/O conversion on subsequent incrementals is performed at this process, but why would Finalizing run for 1-3 hours on an Active Full? I don't have the fastest storage target, but my expectation is that any new Active Full is single I/O normal incremental workflow. Beyond the upgrade, no fundamental change in environment has occurred and this behavior wasn't happening previously. Needless to say, converting to the new backup mode is taking an exceedingly long time in a ~1000 VM environment.

[Gostev]

My question is around why the "Finalizing" process takes so long on an Active Full?

Please, open a support case if you'd like to troubleshoot this.

[cerede2000]

Hello everybody,

My consultant to install Veeam Backup V8 says that with the new functionality Incremental Forever each time the job run it's compile incremental with VBK.

This allows to have at the end of each job always a full file VBK.

My job are set in incremental with full backup weekly.

But I see no change between the operation of the V7 and V8.

I always have a VBK file and VIB chain and a new VBK then VIB chain ....

Is that normal ?
What does the new feature Forever ?

Thanks