Hardened Repository

[storageguy]

Hi,

Can a hardened backup repository be part of a Scale-out Backup Repository (SOBR)?

Thanks

[Mildur]

Yes.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

For a scale-out backup repository:

You can add a hardened repository to your scale-out backup repository as a performance extent. For more information, see Scale-Out Backup Repository and Add Performance Extents.

If you use the capacity tier option, keep in mind that having a hardened repository with immutability as a performance extent will affect the capacity tier behavior. You will not be able to move immutable backup files, because they cannot be deleted from the performance extent. Veeam Backup & Replication will copy such backup files to the capacity tier. When the immutability time period is over, Veeam Backup & Replication will delete these files from the performance extent. For more information on copy and move policies, see Copying Backups to Capacity Tier and Moving Backups to Capacity Tier.

If you evacuate your backups from an immutable performance extent, Veeam Backup & Replication will copy them instead of moving. If the target extent is also immutable, then the immutability of the target extent will apply to copied backup files. For more information on evacuating backups, see Evacuating Backups from Performance Extents.

We recommend to avoid mixing mutable and immutable extents within one scale-out backup repository. You can mix them only during migration scenarios when you want to make a hardened repository from an existing Linux extent.

[storageguy]

Thanks Mildur

[storageguy]

I want to throw one more question.

What about the Backup Copy, will it become immutable as well if I will use a Linux hardened repository?

Thanks

[Origin 2000]

Yes, because the immutable flag will be configured on the (backup) repository configuration rather than on the job it self. Also the minimum immutable number of days is 7(one week).

Regards,
Joerg

[Mildur]

I want to throw one more question.

What about the Backup Copy, will it become immutable as well if I will use a Linux hardened repository?

Thanks

Yes, but you need to configure GFS (Long term retention).
Without it, immutability will not be applied.

[storageguy]

Great. Thanks

[Mildur]

Your welcome

[brucquat]

Hi,

If we configure an immutable Linux repository as performance extent and an Azure Blob Storage as Capacity Tier: can we combine the Copy and Move Operations?

"Combine both the Copy backups to object storage as soon as they are created option and the Move backups to object storage as they age out of the operational restores window option"

thanks.

[Mildur]

They cannot be moved, as long they are immutable. See the limitation guide.
Keep in mind, that GFS restore points are always be immutable their entire retention time on a Hardened Repo.

From the guide:
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

If you use the capacity tier option, keep in mind that having a hardened repository with immutability as a performance extent will affect the capacity tier behavior. You will not be able to move immutable backup files, because they cannot be deleted from the performance extent. Veeam Backup & Replication will copy such backup files to the capacity tier. When the immutability time period is over, Veeam Backup & Replication will delete these files from the performance extent. For more information on copy and move policies, see Copying Backups to Capacity Tier and Moving Backups to Capacity Tier.

[brucquat]

Thanks. But let me rephrase my question:
We would like to have the following configuration:
- an immutable Linux repository as performance extent and keeping the data 7 days
- an Azure Blob Storage as Capacity Tier and keeping the data 30 days
The goal is that when data is on performance extent, we would like to have an "immediate" copy to capacity tier (azure).
Is it possible?
Thanks

[brucquat]

Hello, can please someone have a look at my request?
We would like to have the following configuration:
- an immutable Linux repository as performance extent and keeping the data 7 days
- an Azure Blob Storage as Capacity Tier and keeping the data 30 days
The goal is that when data is on performance extent, we would like to have an "immediate" copy to capacity tier (azure) but keep data longer compared to performance tier.
Is it possible?
Thanks.

[Mildur]

- an immutable Linux repository as performance extent and keeping the data 7 days
- an Azure Blob Storage as Capacity Tier and keeping the data 30 days

Copy and Move can be used together.

But I see an issue with the immutable Linux Repo.
For the Move Policy, you need to configure GFS. If you configure GFS to keep the weeklies for 4 weeks, they will be immutable on the performance extend for their entire retention (4weeks). They cannot be removed from the performance tier before this 4 weeks are over.

[brucquat]

Hi,
Sorry, but does it mean that we can never have a different retention policy in the Linux immutable repository (performance extent) and in the Azure Blob storage (capacity extent)?
thanks.

[Mildur]

The retention Policy from a Job is used for both tiers.
Move Policy helps you to free up space in the performance tier.
But with an linux hardened repo, there are this limitation. Each gfs restore point is immutable their entire retention time. It can not be removed from a hardened repo.

Don‘t use a hardened repo for the moment. Or size the storage accordingly to store all gfs (xfs or refs with FastClone)
Azure doesn‘t support immutability yet, but it could be next year.

[Gostev]

Move Policy helps you to free up space in the performance tier.
But with an linux hardened repo, there are this limitation. Each gfs restore point is immutable their entire retention time. It can not be removed from a hardened repo.

Except when Move policy is enabled. In this case, GFS points are also only locked according to the "number of days" immutability setting of the hardened repository extent (specifically so that they could be offloaded to Capacity Tier and removed from Performance Tier to free up disk space).

[Mildur]

Thanks Anton, i wasn‘t aware of that.

[brucquat]

Hi,
Thanks for your involvement.

Should I understand that if GFS points have 7 days set for the immutable setting of the hardened repository (performance tier) but 30 days for retention period, then the GFS points will stay 7 days on performance tier (Linux hardened repo) but 30 days in capacity tier (Azure Blob Storage)?

Thanks

[veremin]

Almost, with monthly retention period it will be 23 days on capacity tier:

7 days (performance) + 23 days (capacity) = 30 days (retention)

Thanks!

[brucquat]

Thanks for your answer.
But if I use "Combined Copy-Move" mode, could I have 7 days on performance Tier & 30 days on capacity by putting 7 days as immutable setting and 30 days for retention period?
The goal is that we have an "immediate" copy to the capacity Tier and retaining the data longer w/r the performance tier which is immutable.
Many thanks

[Gostev]

Such scenario requires:
1. Backup job with 30 days retention to immutable repository.
2. Backup copy job with 7 days retention to SOBR with Capacity Tier in Copy mode.

[brucquat]

Thanks for your feedback.
And with such scenario:
1. The data will only stay 7 days in performance tier (which is the immutable Linux repository)
2. The data will stay 30 days in the Capacity Tier (Azure Blob)
3. The data will be "immediately" copy from performance tier to capacity tier as of the first day

Correct?
Thanks

[Gostev]

No, it would be the opposite and just like you wanted in the previous post: longer 30 days retention on-prem and shorter 7 days in the cloud.

Longer retention on-prem is not typical, which is why to achieve this you need to use this workaround with 2 jobs and 2 repositories.

1. The data will only stay 7 days in performance tier (which is the immutable Linux repository)
2. The data will stay 30 days in the Capacity Tier (Azure Blob)
3. The data will be "immediately" copy from performance tier to capacity tier as of the first day

This is the most classic deployment scenario which only requires a single backup job with 30 days retention pointed to SOBR with Copy + Move (7 days) policies enabled for the Capacity Tier.