Is it possible to set retention for Azure?

[sandroalves]

Hi,

when i enable copy to send backups to azure it takes all recovery points to azure as well.

Is it possible for me to define that it should maintain a smaller amount of recovery points in Azure?

Thanks.

[Mildur]

No.
Object Storage offload use the retention of the Backup or Backup Copy Job.
If you need a lower retention, you can create a new backup copy Job with a lower job retention and target the job to the sobr.

Your primary job with the longer retention should be targeted to a backup repo without offloading.

[dalbertson]

As Mildur said you cant really shrink the points. But can you explain what your reasoning is? You could use the new archive tier in v11 to send any GFS point from capacity tier to archive tier in Azure to lower costs on the older points.

[sandroalves]

Hi,

in other tools I can define a higher or lower retention according to the end user's needs leaving, for example, the oldest backups in the Cloud and the newest in onpremises.

When I set up Veeam's I didn't see this possibility to set it more or less in Azure and depending on the client it is restricted to what is configured in Onpremises always.

I saw this option from GFS at the end of configuring the scale out for Azure, but it asks to set up another storage account and I didn't understand how this function would work.

Thanks.

[dalbertson]

The move mode of the capacity tier is what you are wanting then. You can set a period of time before they move. For example you can say anything older than 14 days is moved from on prem to azure. This will keep the most local backups on performance tier and then older backups will move to azure.

For backups to move they will need to be a part of a closed chain. You can read more here https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[sandroalves]

Hi,

I am returning to this question now.

I see the same amount of recovery points from my local repository as I have in Azure.

Example:

- Recovery points are 7
- Option move backup 14 days

Simulation:

- Backup age (Day 1, 2, 3...) kept in place.
- On the 14th, the backups of the days (1, 2 and 3 to 13) will be deleted from the place, because I already make a copy as soon as a new backup is created.

Doubt:

- If I have 7 days then it won't move any backups, because no files will be 14 days old.

That's it?

I wanted for example to keep the 7 days locally and keep the other 24 days in the azure blob.





Thanks.

[veremin]

- If I have 7 days then it won't move any backups, because no files will be 14 days old.

Correct.

I wanted for example to keep the 7 days locally and keep the other 24 days in the azure blob.

Then you need to increase backup job retention to one month, enable weekly full backups (needed to seal the obsolete part of the chain), enable move policy (instead of copy) and decrease operational restore window to one week.

Thanks!

[sandroalves]

Hi,

are weekly backups necessary so that there is a chain (.vbk and vibs) in the Azure Blob for the need for restore and also locally?

I understand that if I have 31 days on hold, days (1 to 24) will be on the Azure Blob (Day 1 ".vbk" and Days 2, 3, 4...".vibs").

This means that if I need to restore in onpremises I won't have the (.vbk) because it went to Azure Blob. Why is the weekly full required?

I could the full Synthetic? I don't think so, because I can only choose one day of the week and in that case I need full weekly.

The full ones are very big...

I don't understand: (..decrease operational restore window to one week.)


Thanks.

[veremin]

Kindly, check the links provided above as they direct you to the corresponding sections of the User Guide where all of those concepts are explained in detail: weekly full backup (either active or synthetic) is needed to make a certain portion of the chain inactive and suitable for offload to object storage, operational restore window is the settings that controls period of time after which inactive chains are moved to capacity tier. Thanks!

[sandroalves]

Hi,

I read the document with the explanations.

In my case, as I use increment forever, it uses the active or synthetic full as equals.

I configured it like this to test:

- 15 days of retention
- 7 days to move
- Full synthetic every Saturday.

Thanks.

[veremin]

Actually you have switched from forever forward incremental mode to forward incremental one, as soon as you have enabled synthetic full backup - it's just a matter of terminology though, your current setup looks valid. Just make sure that Performance Tier can handle two full backups at a time, since there will be times when new synthetic full backup has been just created, but previous chain (that has just become inactive) and has not been moved to object storage yet. Thanks!