Discussions related to using object storage as a backup target.
Post Reply
clbow23
Novice
Posts: 6
Liked: never
Joined: Jan 09, 2024 2:28 am
Contact:

SOBR Retention Policy

Post by clbow23 »

Forgive me if this has been asked thousands of times, but I have been researching the best approach to a new backup policy and would like to confirm that this is a good one.

I would like to backup my servers and retain 7 dailies on a NAS repository, 12 weekly in AWS S3 Infrequent Access, and finally 10 years of monthly in AWS S3 Glacier.

I have configured a SOBR with the NAS as the performance tier, S3 as capacity, and S3 Glacier as archive. In the "Capacity Tier" section of the SOBR setup, I configured it to move backup files older than 7 days. In the archive tier, I configured it to archive GFS backups older than 60 days.

In the actual backup job, I set the retention policy to 7 days (I understood this as how many I would like to keep on the NAS), then configured GFS to keep 12 weekly and 120 monthly.

Any guidance or advice is much appreciated!
Mildur
Product Manager
Posts: 9588
Liked: 2539 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: SOBR Retention Policy

Post by Mildur » 1 person likes this post

Hello Clbow23

Welcome to the forum.
I would like to backup my servers and retain 7 dailies on a NAS repository
...
I set the retention policy to 7 days (I understood this as how many I would like to keep on the NAS)
Please be aware, with weekly full backups and 7 days retention, there can be backups between 7-14 days on your performance tier. That's how forward incremental works.
In the "Capacity Tier" section of the SOBR setup, I configured it to move backup files older than 7 days.
I recommend to use the copy and move policy together. That way, you will have a immediate copy of the daily backups to Amazon S3. If copy is not configured, your restore point on Capacity Tier will always be 1-7 days behind. In case you got attacked by ransomware, you would need to restore from an older backup. And loosing data can be expensive.
12 weekly in AWS S3 Infrequent Access, and finally 10 years of monthly in AWS S3 Glacier
...
In the archive tier, I configured it to archive GFS backups older than 60 days.
Sounds good. Make sure that "Archive backups only if the remaining retention time is above minimal storage period" is enabled (should be by default). If disabled, your weekly backups would also be moved to S3 Glacier.
In the actual backup job, I set the retention policy to 7 days (I understood this as how many I would like to keep on the NAS), then configured GFS to keep 12 weekly and 120 monthly.
Correct. The backup job specifies the retention for each backup.

Additional recommendation:
- Consider to use immutable S3 bucket. On capacity tier, backups will be immutable according to the specified value. On Archive Tier, backups will be immutable for the entire GFS lifetime (10 years in your case). Please consider that, if you enable immutable backups on your archive tier. You need to pay Amazon 10 years or let them delete your entire Amazon account.

Best,
Fabian
Product Management Analyst @ Veeam Software
clbow23
Novice
Posts: 6
Liked: never
Joined: Jan 09, 2024 2:28 am
Contact:

Re: SOBR Retention Policy

Post by clbow23 »

Hi Fabian,

Thanks so much for the helpful information! I have some follow up questions if you don't mind.
Please be aware, with weekly full backups and 7 days retention, there can be backups between 7-14 days on your performance tier. That's how forward incremental works.
Since my SOBR is set to move the full backups at 7 days, should I set the retention period on the job to a higher number such as 14 days to avoid them being deleted before they can be offloaded?
I recommend to use the copy and move policy together. That way, you will have a immediate copy of the daily backups to Amazon S3. If copy is not configured, your restore point on Capacity Tier will always be 1-7 days behind. In case you got attacked by ransomware, you would need to restore from an older backup. And loosing data can be expensive.
This makes sense! I am using an immutable Linux hardened repository on the performance tier. Would you still recommend in that case? I should be fairly covered from ransomware in that case? I am concerned that over time the incremental backups will increase my storage and payment even more.
Consider to use immutable S3 bucket. On capacity tier, backups will be immutable according to the specified value. On Archive Tier, backups will be immutable for the entire GFS lifetime (10 years in your case). Please consider that, if you enable immutable backups on your archive tier. You need to pay Amazon 10 years or let them delete your entire Amazon account.
Are you saying that you recommend using this "Encrypt data uploaded to object storage" option in the SOBR settings? Would this allow me more control of the data in the event I wanted to remove it before the 10 year period? My understanding was that GFS backups in both the Capacity and Archive tiers are immutable.

Final question: What would you recommend doing to encrypt the backups in transit? Would the "Encrypt data uploaded to object storage" accomplish this?
tyler.jurgens
Veeam Legend
Posts: 385
Liked: 215 times
Joined: Apr 11, 2023 1:18 pm
Full Name: Tyler Jurgens
Contact:

Re: SOBR Retention Policy

Post by tyler.jurgens »

Veeam by default encrypts data in transit. You'd have to hunt to find a way to actually turn that off.

"Encrypt data uploaded to object storage" will encrypt the backups on your object storage repositories (data at rest encryption). That's up to you, but I would definitely suggest enabling that as long as you make absolutely sure you have recorded that encryption key.
Tyler Jurgens
Veeam Legend x3 | vExpert ** | VMCE | VCP 2020 | Tanzu Vanguard | VUG Canada Leader | VMUG Calgary Leader
Blog: https://explosive.cloud
Twitter: @Tyler_Jurgens BlueSky: @tylerjurgens.bsky.social
Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests