Veeam wasabi immutable - restore points

[anj]

We are using Veeam with local repositories. We are now testing Wasabi- object storage - s3.
We have created a Wasabi repository and chose 2 days immutable.
We are testing both scale-out repository and "Backup copy jobs".
It seems to work ok. When I try to delete files using Veeam it's denied - as it should.

My question is about restore points.
I have a backup job using forever incremental strategy. 3 restore points. The full backup is merged with the oldest incremental using the retention policy (no syntetic full..).
I have a "backup copy job"for the previous backup job using immediate copy and 3 restore points.
The wasabi repo has 2 days immutability.
If i run the backup job many times (more than 3) the same day I observe that the number of restore points in wasabi object storage is the same as the local repository.
Is this correct?
I had an idea that the number of restore points would be larger on the object storage in Wasabi - because of the immutable policy set on the Wasabi repository.
I thougt the restore points would be kept for 2 days (2 days immutable) in the Wasabi repository.

No it seems the number of restore points in wasabi repo always is the same as the local repository.

[sfirmes]

@anj We use a forever forward incremental methodology when we store backup data on the capacity tier. A great resource that explains this is here https://helpcenter.veeam.com/docs/backu ... ml?ver=110.

The immutability setting controls how long the object will be locked. This is separate from the backup job retention setting. So you could have backup data in the capacity tier locked longer than your retention policy, although this isn't recommended.

Also we have our block generation https://helpcenter.veeam.com/docs/backu ... ml?ver=110 to consider. So if you have immutability set to 2 days, the object may not be deleted for up to 12 days. 2 days immutability + 10 days block generation buffer.

Hope this helps.

Steve

[dalbertson]

Also mentioned here on the wasabi support site. It links back to our info on block gen.

https://wasabi-support.zendesk.com/hc/e ... ntegration

[Gostev]

If i run the backup job many times (more than 3) the same day I observe that the number of restore points in wasabi object storage is the same as the local repository.
Is this correct?

it seems the number of restore points in wasabi repo always is the same as the local repository.

Yes. The retention policy is always defined by the backup job and we won't show any restore points outside of the retention policy, even if their data may still be present in the repository due to being immutable for longer than the retention policy.

[anj]

Ok. How can we get access to the restore points outside of the retention policy if we want a restore?

[Gostev]

Honestly, I would recommend you instead fix your retention policy to make sure it adequately represent your restore needs because there's no smooth UI-driven way for doing this. Other than that, this has already been discussed here before, so please use search.

[anj]

Let's say we have an intruder with access to our Veeam server. What happenes if he just run a backup job many times until he reaches the set number of restore points. Will the backup just be overwritten? I thought the point was to have immutability? Sorry, but it could be I don't understand the whole concept.

[Gostev]

Well, in that case I can confirm you do actually have a full understanding of the whole concept. You're absolutely correct in thinking that the only scenario where you would need to leverage this functionality is following a cyber attack where you lost your entire environment to hackers (as opposed to just using this restore possibility "casually" so to speak).

By the way, here's the existing thread I referenced.