Forever forward Incremental Backup Job and Immuability

Move mode will not work with the capacity tier for forever forward because the entire chain is always active.

Copy mode will copy new incrementals as they appear and remain for the number of days defined as immutable and in your retention policy.

Yes I did not specify that I am talking about Copy mode. Imagine I have a set up my job with a retention of 7 days.
Day 1 Full backup ==> the full backup is copied to my object storage
Day 2 Incremental ==> only new data blocks are copied to my object storage
Same process for the next Days

What will happen in day 8? Normally the oldest incremantal files is merged with the full backup, but in this case we have immuability set in the object storage.

Hmm ok ! It’s really abstract for me 😂.

I was thinking this because in v12 we will be able to save directly to object storage and the backup modes "disappear". 

What's the reason that you use forever forward incremental instead of forward incremental with synthetic fulls? With ReFS/XFS the storage consumption won't change that much. The only real advantage, in my opinion, is that you can create virtual full backups to tape.

Hello
Even if ReFS/XFS are more and more democratized, not all compagny have the ressources to implement it. In a NAS with poor performance I prefer to use forever incremental or active full if there is enough space.
And like you said if you need to make some export to tape, with a forever incremental chain you could make a virtual full every day.

But I came to this cause in Veeam v12 you ll have the possibilites to backup directly to S3 and the “synthetic full” doesn’t exist anymore for this kind of job.
 

@Stabz: Are you saying you will change your job to backup direct to object storage as soon as v12 comes out?

The active fulls can take a lot of time and if you are not using ReFS/XFS then synthetic operations can take forever as well, but yeah on a poor NAS I get it. Folks by the way I am wondering about incrementals and merges on V12 going direct to S3 and performance implications as I have not had time to test that with the Beta.

@Stabz Ok, on a NAS it's a different situation. I wasn't thinking about that as you were talking about hardened repository.

@Geoff Burke I think Rasmus has answered it above 😉

@regnor yup see that now :) 

That’s could be a topic question :D ! For the backup jobs, I will not change my jobs to object storage in the cloud cause the best practices recommend to have a backup near the production for best performance. But in the case where my customer have object storage appliance onpremise that could be a new option in the reflexion of the global architecture. I m waiting to have some feedbacks about the backup/restore performances.

Another use case to backup directly to object storage and this time in the cloud would be to archive a backup of one vm quickly.

On the other hand, I ll probably review for some of my customer the externalization to object storage with backup copy jobs. With a SOBR it's not possible to change the retention configured in the backup job so if you have a long retention on-premise you will have the same in S3. Backup copy job direct to S3 will simplify some architecture and in bonus the GFS points ll be normally protected for all their retention period.

Yes I agree that Active full can take a lot of time, but I saw a lot of configurations where the active was better in term of backup window than a synthetic full when the repository is not efficient.

I just start a new job in my lab to backup directly to Wasabi, I'll make a post about it and see how the performance evolve in the time :)

Yup, I talked about hardened repository cause in this case you can’t configure forever incremental job with this kind of repository :)