backup retention involving local and S3

[Danh3]

Hello,


I'm trying to understand backup retention involving local and S3 . does Veeam V12 support different restore point/retention on S3 ?


F1 chain #1 full
I1 Chain #1 incr
F2 chain #2 full
I2 Chain #2 incr

"Forever forward incremental approach" for our primary backup, eliminating the need for active full or synthetic full backups
The primary backup store on a local repo with 4 restore points.
backup copy store on S3, which maintains 3 restore points.



on the 3rd day -

local repo:

Sun(04/Sep) F1
Mon(05/Sep) I1-1
Tues(06/Sep) I1-2

s3 bucket :

Sun(04/Sep) F1
Mon(05/Sep) I1-1
Tues(06/Sep) I1-2
*******************************************************************************************************************************************

What will the contents appear on the S3 bucket for the 4th and 5th days since no merging has taken place?

On 4th day , Instead of a full merge on S3, does incremental backup job on 07/Sep will be saved in the S3 bucket ?

s3 :

Sun(04/Sep) F1
Mon(05/Sep) I1-1
Tues(06/Sep) I1-2
Wed(07/Sep) I1-3


on 5Th day, in the local repository, incremental job 'Mon(05/Sep) I1-1' is injected into 'Sunday (04/Sep) F1'. a new chain F2 created and I1-1 is removed from the local repository.

Local repo :
Mon(05/Sep) F2 - a new chain F2 created
###Mon(05/Sep) I1-1 is removed from the local repository.###
Tues(06/Sep) I2-1
Wed(07/Sep) I2-2
Thur(08/Sep) I2-3


what content will appear in S3 repo for 5th day ? thanks

[Mildur]

Hello Dan

Object storage doesn't have backup files (VBK, VIB) as you know it from your "local storage".
On day 5 we will upload new and changed data blocks as objects. Data blocks not used by any of the last 3 restore points will be deleted after +1 day.

I'm trying to understand backup retention involving local and S3 . does Veeam V12 support different restore point/retention on S3 ?

Veeam supports two types of object storage integration. SOBR and direct backup/copy to object storage.

SOBR:
The same backup retention is used for performance (your local storage) and capacity tier (your S3 storage). You configure it in the backup job setting.
When you configure copy policy for the capacity tier, restore points on performance and capacity tier will have the same retention period.
When you enable move policy, you can move restore points from the performance tier to the capacity tier after a specified time (setting in SOBR properties. On capacity tier, the restore points are still following the job retention period.

Direct backup or backup copy to object storage
You will use a backup copy job to copy backups from your local storage to the S3 storage. The backup copy job will have it's own retention settings.

The primary backup store on a local repo with 4 restore points. backup copy store on S3, which maintains 3 restore points.

Allow me a question regarding your retention. Do you have longer retention times on any other repository? I'm just thinking that 3-4 restore points may be to low.
Imagine you get an infection on Friday afternoon. Then we have the weekend and your people are going to the office 3 days later. Healthy restore points may already be aged out.
Or think of public holidays such as Christmas. Probably 3-4 days nobody working. An attack happens this year on December 23th (Friday). People are out of office till the morning of December 27th.
The last healthy backup was Thursday (December 22nd) evening. 5 days ago. But retention already removed those restore points.

Best,
Fabian

[Danh3]

thanks @Mildur

apologize for the delayed response and you're absolutely correct - restore points that used in above example only for testing purpose.


In the past few days, I did some tests on an S3 bucket, both with and without immutable settings, to understand how retention of restore points behaves when it exceeds the maximum allowed number.

For both configurations, it retained the number of restore points as I had set in the backup copy. so instead of 'merging' backups the metadata is simply updated to point to the new data blocks that are required to create the backup.

Additionally, I attempted to delete blocks and backup data from the immutable s3 to confirm the immutability of the data. Any deletion just places a delete marker on the data, hiding it. the delete marker itself does not contain any data. When I toggled the version tab in the S3 console, the deleted items became visible.

Delete the delete marker file worked, but attempting to delete the actual data from either the AWS console or AWS CLI resulted in an "access denied" error and this serves as solid evidence - backup content within the retention lock window cannot be deleted!

I will wait until the lock retention period expires on September 25th and then attempt to delete the data to see if it works. While I have more tests to do for immutable bucket, I will create a new thread if I'm running into issue.

thanks

[Mildur]

Hi Dan

Thanks for the feedback.
I'm looking forward to more feedback if you like to share it.

Best,
Fabian