change from Forward incremental forevert to Reverse

[IDATAAB]

Veeam v.8.0.0.2084 (Update 3)
I admit it. I thought the forward incremental forever was so cool I went and setup all of my jobs using it. Naturally, I am now running low on storage.

Can someone please advise me if I can change to Reverse incremental in version 8 U3 and if so, how to do it? So far I only see doc for version 9. Do I need to upgrade? Do I need to create a Synthetic full? does that mean I need space for 2 fulls to reside on my storage during the time I am converting? Any and all Help appreciated.

Jeff

[foggy]

Jeff, you just need to select reversed incremental mode in the job settings. The next job run will make a full backup, so yes, you need a space for it.

That said, reversed incremental requires similar space overall as forever forward, so I do not see how you're going to save space by switching only. Have you checked the repository, what backup files do you currently have there?

[IDATAAB]

Hi Foggy, thanks for the response.

I have cleaned house so any junk is gone. My problem is that I was dumb enough to set incremental forever on all jobs but I don't really need it for all of my VMs. A lot of them are static machines that I just need a few RP's in the event a machine tanks. Since I can revert to reverse incremental, that problem will be solved for most of my machines.

Actually I have two problems - I also have a couple of vm's that I need to store files on for a defined time period (19-24 months), and then they are deleted from the system and will never need to be recovered. I mistakenly configured IF which means that I'll never get rid of the files from my backup -right? That means over time the backup can become huge. Or maybe I don't fully understand the concept - If I set IF with 31 restore points, does that mean that on day 32 a full is taken and anything that has been deleted from the server is also now gone from the backup?

I'm trying to figure out how to handle this without having a lot of monthly or quarterly fulls because I don't have the space for that since we are talking about a full backup being around 2TB in size. Guide me guru!

Thanks

[foggy]

With forever forward incremental mode, the oldest increment is merged into the full backups once the number of restore points reaches the specified retention, so the full backup "moves forward" each day and you always have the specified number of restore points.

[IDATAAB]

Hi - I guess what I am confused about is this -
File on server.
Server gets backed up using FI, 31 restore points, no other GFS backup scheme. File gets deleted at sometime during the 31 days (Restore points).
On day 32 does this mean I can no longer recover the file or is it still in the backup?

[PTide]

On day 32 does this mean I can no longer recover the file or is it still in the backup?

In your example full backup that has been created on day 1 contains state of the VM on that day. The subsequent increment contains state of the VM on Day 2 and so on. When you delete the file and run another increment on Day 32 it triggers the retention so the full backup gets merged with a Day-2 increment so now the full backup contains the state of you VM on Day 2 when the file was still there. The datablocks that represent the deleted file in the backup will be replaced with new datablocks (or marked as free) on the day when your full backup gets merged with the increment that happened after the deletion, that will be the 32-nd day. If the guest OS hasn't overwritten blocks where the file was residing at with a new data yet, then the content might still be there because deletion does not actually delete anything but just updates an MFT record, leaving blocks untouched. In this case it might be possible to restore the file by using special tools. However, if you enable BitLooker feature (available in v9) dirty blocks will be cleaned up automatically during next incremental backup. In this case the file will become unrecoverable right after your full backup gets merged with the increment that has been created on the 32-nd day.

Thank you.