Restore Points and forward Incremental ?

[Wad4iPod]

1)Select 14 or 45 roll back points.
2)Then use forward incremental.
3)Perform Active full backup on the first of each month,or select every Friday.

How are the rollback points maintained?

Thanks in advance.

[Gostev]

Any backup files which are not required to restore from previous 14 or 45 restore points are automatically deleted by the job.

[Wad4iPod]

Thank you Gostev. Read that in the Manual recently. Thanks for not referencing .... RTM

[Wad4iPod]

Hi Gostev,
Woudl you clarify/recommend for me?

Two scenarios both using forward incrementals.

For both scenarios - When the next Full occurs I would like all the previous backups - .vbk and vib to be removed from the target destination. Leaving a fresh .vbk and the follwing vib's until the next Full - when the cycle clears and begins again.

First Scenario:

For a Monthly Incremental (A full backup runs on the First Friday on the Month) - How many rollback points should I choose?
31?

Second Scenario:
For a weekly Incremental (A full backup runs on each Friday) - How many rollback points should I choose?
6?

[Vitaliy S.]

Kevin,

Your requirement to remove all previous restore points immidiately after the new VBK file is created can't be met until you create a third VBK file, meaning that you would have at least 2X number of restore points with Forward Incremental backup mode.

Please have a look at these informative posts from Tom for more info:
http://www.veeam.com/forums/viewtopic.p ... 29&p=21782
http://www.veeam.com/forums/viewtopic.p ... 21&p=25468

Thanks!

[tsightler]

Actually, if he simply told Veeam to keep "1" restore point, wouldn't that work? I.E., the Full backup would be run on Friday, every other day would create an incremental, which wouldn't actually delete the full since that wouldn't meet the requirement for keeping "1" restore point. When the next Full ran on Friday, it would delete the previous full and all incrementals, wouldn't it?

I would think he could meet the requirements for both of his scenarios by simply setting the number of restore points to 1, but I have not tested this.

[tsightler]

BTW, there's so much confusion to this that it's obvious Veeam needs to work on some different wording for this option as it doesn't really apply as well to incrementals as to reverse incrementals (the only type available prior to Veeam 5). When using incrementals, it should probably be termed "Number of Full Backups to keep on disk" since deleting a full backup will always force the deletion of it's child incrementals. This would make the option less confusing.

[Vitaliy S.]

Actually, if he simply told Veeam to keep "1" restore point, wouldn't that work? I.E., the Full backup would be run on Friday, every other day would create an incremental, which wouldn't actually delete the full since that wouldn't meet the requirement for keeping "1" restore point. When the next Full ran on Friday, it would delete the previous full and all incrementals, wouldn't it?

Tom, I haven't thought about that! Nice one

We've just checked that scenario in our labs and it works. That might be a good option to choose, though this scenario wouldn't cover malware/virus corruption of the Guest OS. In other words, when day "X" comes and you create a Full backup, all restore points you had previously will be deleted by the retention policy. That said, if you have a Guest OS corruption on the Full run, there is no sense in having this restore point (which will be the only restore point!), and in case a real disaster that might be a nightmare.

Assuming that there is a monthly incremental scenario, I would consider choosing Reversed Incremental backup mode because of the simplicity of a restore to the most recent state procedure in case of a disaster.

BTW, there's so much confusion to this that it's obvious Veeam needs to work on some different wording for this option as it doesn't really apply as well to incrementals as to reverse incrementals (the only type available prior to Veeam 5). When using incrementals, it should probably be termed "Number of Full Backups to keep on disk" since deleting a full backup will always force the deletion of it's child incrementals. This would make the option less confusing.

I cannot disagree with this. Sometimes these wordings and the retention policy settings, indeed, might cause a confusion. Thank you for helping us with explaning all the details

[tsightler]

I assumed that he was perhaps replicating or perhaps copying and physically taking the files offsite for safe archival and he just didn't want to waste the space with restore points on the local backup storage. In that case, his scenario might make sense.

Reversed incrementals do have ease of retention as an advantage, but they have many disadvantages as well. It's always a balancing act. In our environment forward incrementals are 3-4 times faster than reverse incrementals (a pretty big deal when it's 3 hours instead of 12 hours) and we're big proponents of not touching your backup files once they've been written. We actually use a script that marks the backup files with the "immutable" flag so they can't be accidentally deleted or modified in any way. With reverse incrementals your good backup is changed every night which means every night is a potential for that backup to be damaged (not likely I know, but even a small chance is too high for us).

[Wad4iPod]

Hi again.

I believe I had tested setting the rollbacks to 1 in both scenarios. What I believe happened was some VRB's were created rather than removing the previous VBK and VIB's.
I'll test it again.
I also have a 2nd job that runs a Full /RI job on the weekends. I thought about it this am and wanted to ask, "Will this 2nd side-by-side full cause and loss in what's backed up in the second job". I am hoping that they're independent?

[tsightler]

I believe I had set the rollbacks to 1 in both scenarios. What I believe happened was some VRB's were created rather than removing the previous VBK and VIB's.

Well, VRB's would be created if you had selected Synthetic fulls with the "transform to rollback" option since this would tell Veeam to take the previous full backups, and all subsequent incrementals, create a new full backup, and transform previous incrementals to rollbackups. If you don't want the rollbacks then you should not enable the "transform to rollbacks" option.

I also have a 2nd job that runs a Full /RI job on the weekends. I thought about it this am and wanted to ask, "Will this 2nd side-by-side full cause and loss in what's backed up in the second job". I am hoping that they're independent?

They would be independent.

[Wad4iPod]

Nope. Didn't have transform enabled.

[tsightler]

Nope. Didn't have transform enabled.

Did you change the job from forward to reverse incremental at some point? That's pretty much the only things that would cause a job to have both VIB and VBR files.

[Wad4iPod]

I believe I did. I have since deleted and recreated the job. Current rollback is set for 1 day. We'll see in a few weeks how it behaves

[Wad4iPod]

Well, VRB's would be created if you had selected Synthetic fulls with the "transform to rollback" option since this would tell Veeam to take the previous full backups, and all subsequent incrementals, create a new full backup, and transform previous incrementals to rollbackups. If you don't want the rollbacks then you should not enable the "transform to rollbacks" option.
They would be independent.

- Great. Thanks