Transform previous backup chains into rollbacks

[HannesK]

Hello,
hard to say without case number and details about the hardware setup.

yes, that's just terminology. www.veeam.com/kb1799 shows how each backup mode works with animations.

This discussion is only about "Transform previous backup chains into rollbacks" for the "incremental" backup mode.




For any other discussion (like chain length, tape feature requests), it would be great to use extra topics. Otherwise it's hard to follow the original topic.

Best regards,
Hannes

[RubinCompServ]

Unfortunately, none of those animations explains how a Reverse Incremental is different from a Forward Incremental with daily transforms, as in both cases you end up with a VBK as the most recent backup and VRBs going backwards. And since, as has been posted, using a Forward Incremental with Transforms reduces the amount of time the VMware snapshot is in existence (Matt) and it decreases the amount of time that the source VM's virtual disks are attached to the proxy server when using HotAdd mode (jmacdaddy), why would you not want to use that?

[foggy]

Hi David, the difference between the two modes is explained in this thread in detail.

[cmaier]

For me the transform feature is absolutely brilliant and works perfectly for years in our environment. With ReFS block cloning it's pretty fast, too. I don't understand at all why you want to cancel it. Could you explain what your problem with this feature is, please? If I remember right Anton said you found out that too few people use this feature. And you found it out by analyzing the support case's log files.

Really? Should I open more support cases to be a more significant part of your statistics? Usually your product runs fine and I don't need to open support cases...

I think it is a very normal strategy to use the large time period of a weekend to handle huge full backups and the small time period of a weekday's night for small incremental (and differential) backups. What are your alternatives to the transform chains feature?

- Reverse incremental: Creates full backups every day and is not to handle in one night.
- Incremental forever: Yes, that's how your agents work and that's really annoying. There are new incrementals every day which is fine. But there are also new fulls every day because of the retention handling. So we have to write a new incremental AND a new full backup to tape every night. And we have to write the whole chain to tape on weekend. For this reason we have to keep the chains shorter than we would like. They are only 14 days long while the "synthetic transformed full" chains can easily have a length of 3 months. Luckily we have only two servers where we need an agent for.
- Incremental with active full every weekend: Could be the only real alternative but our repository storage would explode. Not an option, too.

So what are your alternatives? I don't see any.

[HannesK]

Hello,
there are two main reasons

1) amount of QA resources to test it with each release
2) usability. We have "simple" as core value at Veeam

I'm not sure I understand your second / third point: Agent's don't require incremental forever. Synthetic full with REFS is available to avoid high amount of disk space usage.

We are aware that there are some use cases that currently require transforms (as mentioned earlier for some tape scenarios). Will will not add that mode to agents and other virtual machine based platforms (Nutanix, Azure, AWS)


Best regards,
Hannes

[Gostev]

For me the transform feature is absolutely brilliant and works perfectly for years in our environment. With ReFS block cloning it's pretty fast, too.

This got my attention. Can you please share why are you using the transform to rollback feature on the ReFS repository? Because there is little benefit of doing transforms on ReFS, where synthetic full backup don't take any physical disk space regardless. However, there are certainly drawbacks in the form of much unneeded data processing (making changes to backup files), when any data processing means a potential of bugs and introducing data corruptions.

I don't understand at all why you want to cancel it. Could you explain what your problem with this feature is, please?

The main reason is that this mode is too prone to bugs, especially on intersections with other features. For example, I was just working on the release notes for 10a, and all the backup mode specific bugs that were fixed there was around this backup mode.

Also from general reliability considerations, you want to avoid changing your backups after they have been created. And ReFS/XFS allow you to achieve that without requiring additional disk storage comparing to what you're using today with this backup mode.

Finally, this backup mode will not be compatible with some future functionality, which we expect many customers will want to use, because it is pretty game changing.

If I remember right Anton said you found out that too few people use this feature. And you found it out by analyzing the support case's log files.
Really? Should I open more support cases to be a more significant part of your statistics? Usually your product runs fine and I don't need to open support cases...

No, opening more support cases will not make you a more significant part of your statistics, because they will all roll under the same unique installation ID. So, just one case is enough to have equal representation. And over the past 3 years, we had over 90% of customers open at least one support case, so we don't even need to approximate the usage of this feature.

I think it is a very normal strategy to use the large time period of a weekend to handle huge full backups and the small time period of a weekday's night for small incremental (and differential) backups. What are your alternatives to the transform chains feature?

Our recommendation is to use ReFS/XFS repository and don't do transforms at all, as they are largely pointless there. Just use the default backup mode with periodic synthetic fulls.

[mcz]

Hi everybody,

just wannted to add my thoughs to this topic. We were using the transformation since years, now I've switched to forever forward incremental to see how it goes and what the differences are. One little drawback is the usage of SureBackup jobs in combination of the option "keep the application group running after the job completes". I'm using that option for testing purposes and today I realized that my whole lab got shutdown by whatever reason. Now I've counted 1+1 together and understood that as soon as the merge process of the backup job kicks in, it stops your SureBackup job. The thing is that I was using my latest restore point in the SureBackup session and the backup job merged the oldest point in the chain.

Previously, when we used the transform option, the backup job just deleted the VRB and this had no affect on the SureBackup, as long as you don't run the restore point which would get deleted.

Did you veeam-guys consider that situation and what is the suggested approach? Thanks!

[HannesK]

Hello @mcz,
yes, the scenario should be no problem when using synthetic fulls (no disk space requirement with REFS / XFS).

Best regards,
Hannes

[mcz]

Sorry Hannes, I don't understand. You're talking about synthetic fulls, I'm talking about the "normal" incrementals when they get merged into the full.And this merge happens now after every backup job...

[Gostev]

Actually there are no merges with periodic synthetic fulls, backup files never change once they are created... so you must be using some other backup mode Michael.

[HannesK]

sure, forever forward incremental (your scenario) is not compatible with "keep application group running". That's why I suggested to switch to synthetic fulls.

[mcz]

ok, now I understand. Thanks Anton, thanks Hannes!

[cmaier]

@Anton

Ok, thanks for the clarification. I didn't realize that synthetic fulls are using fast clone on ReFS and therefore don't need additional space. I had NTFS too long.

This could be a working alternative for me, I guess. But I definitely need this barcode LTO generation handling in the future.