SOBR Retention and Storage Usage

[koilkonnect]

Guys,
I’m planning to deploy a SOBR and have a few questions regarding the storage usage of the repository. I have about 5 TB of data right now and probably increase 50 GB every month. My retention policy for backups to keep is listed below.

• Keep one per hour for 32 days.
• Then keep one per day for 60 days.
• Then keep one per week for 52 weeks.
• Then keep one per month for 24 months
• Then keep one per year for 4 years.

1. I will need to set the Short-Term Retention policy to 92 days and GFS to 52 weeks, 24 months, and 4 years to achieve this. Does this look right?

2. My performance tier is a hardened Linux server, and my current plan is to store all the full range of backups on there. I will need to set the “Make recent backups immutable for:” to 92 days, so that all my backups are immutable. I read that GFS is immutable already. Correct?

3. If I have an archive tier, how much data would it save me on the capacity tier. For instance, I have the full 7 years and 92 days backups in the capacity tier. Current data is 5 TB for the latest full backup and 100 GB differential backups. If I moved the GFS to archive, that would leave 92 days left on the capacity tier and at least a full backup on capacity tier? Would that full backup be the full 5 TB or is there some virtual cloning in the backend like how it works with full synthetic backup? What I want to know is do I have to pay 5 TB full backup + 100 GB differential backups on the capacity tier and another 5 TB for archive tier? I’m assuming I just need to pay for 100GB differential backups for capacity tier and 5 TB for archive tier, but just want to confirm.

Thanks!!

[Mildur]

Hello Kevin

• Keep one per hour for 32 days.
• Then keep one per day for 60 days.
• Then keep one per week for 52 weeks.
• Then keep one per month for 24 months
• Then keep one per year for 4 years.

A backup job only provides short term policies in days, and long term policies in weekly, monthly and yearly. A backup job can not have a retention of hours and daily.
Please also consider which servers needs hourly backups. Normally I see that a customer only have a few production systems with that requirement. For database servers such as MSSQL, you probably don't want to create hourly VM snapshots. A snapshot can freeze your application for a few milliseconds or seconds and your end-user will most likely see application issues on their side. For such systems, I would consider other backup methods such as transaction log backups.

1. I will need to set the Short-Term Retention policy to 92 days and GFS to 52 weeks, 24 months, and 4 years to achieve this. Does this look right?

I would create two backup jobs:
- Backup Job, which runs hourly for those servers you need an hourly backup. Retention: 32 days with weekly full
- Backup Job, which runs daily for those servers you need an daily backup. Retention: 32 days with weekly full

Create a single periodic backup copy job to the SOBR:
- Backup Copy Job, which runs once per day. Retention 90 days, 52 weekly, 24 monthly, 4 yearly
You can also create a second copy job, if you want to copy all hourly restore points to the SOBR and offload it to the capacity tier.

2. My performance tier is a hardened Linux server, and my current plan is to store all the full range of backups on there. I will need to set the “Make recent backups immutable for:” to 92 days, so that all my backups are immutable. I read that GFS is immutable already. Correct?

32 days, if you want to be able to delete restore points after the 32 days retention period of your hourly backup job. With 92 days, your hourly restore points cannot be removed after they are aged out. GFS is immutable for the entire immutable period if you don't enable the move policy on the capacity tier.

3. If I have an archive tier, how much data would it save me on the capacity tier. For instance, I have the full 7 years and 92 days backups in the capacity tier. Current data is 5 TB for the latest full backup and 100 GB differential backups. If I moved the GFS to archive, that would leave 92 days left on the capacity tier and at least a full backup on capacity tier? Would that full backup be the full 5 TB or is there some virtual cloning in the backend like how it works with full synthetic backup? What I want to know is do I have to pay 5 TB full backup + 100 GB differential backups on the capacity tier and another 5 TB for archive tier? I’m assuming I just need to pay for 100GB differential backups for capacity tier and 5 TB for archive tier, but just want to confirm.

Veeam doesn't have differential backups. We use incremental or full backups.
Capacity Tier is forever forward incremental. There will always be an entire full and all belonging incremental backups on the capacity tier. Or you won't be able to restore.
GFS backups can be moved to the archive tier. But still, one full backup will stay on the capacity tier.

We have a size estimator you can try out:
https://calculator.veeam.com/vse/

Best,
Fabian

[koilkonnect]

I would create two backup jobs:
- Backup Job, which runs hourly for those servers you need an hourly backup. Retention: 32 days with weekly full
- Backup Job, which runs daily for those servers you need an daily backup. Retention: 32 days with weekly full

Create a single periodic backup copy job to the SOBR:
- Backup Copy Job, which runs once per day. Retention 90 days, 52 weekly, 24 monthly, 4 yearly
You can also create a second copy job, if you want to copy all hourly restore points to the SOBR and offload it to the capacity tier.

My main concern regarding this post is for our main file server. The other servers will only get daily backups. I see now that in order to achieve both daily and hour retention I need 2 separate backup jobs. If I change the backup requirement to "Keep one per hour for 92 days" and remove "Then keep one per day for 60 days", then I can achieve what I want with one backup policy for this server. I will need to set the Short-Term Retention policy to 92 days and GFS to 52 weeks, 24 months, and 4 years and to run the job periodically every hour. This should keep hour backup for 92 days, correct?

32 days, if you want to be able to delete restore points after the 32 days retention period of your hourly backup job. With 92 days, your hourly restore points cannot be removed after they are aged out. GFS is immutable for the entire immutable period if you don't enable the move policy on the capacity tier.

With the changes above, what is the max number of days I can enter here without causing undesirable issue? Thanks.

[Mildur]

Yes, multiple jobs are required.

If I change the backup requirement to "Keep one per hour for 92 days" and remove "Then keep one per day for 60 days", then I can achieve what I want with one backup policy for this server. I will need to set the Short-Term Retention policy to 92 days and GFS to 52 weeks, 24 months, and 4 years and to run the job periodically every hour. This should keep hour backup for 92 days, correct?

Yes. That will work for this file server. Just to note, you will end up with backup chains of 168 restore points. There will be 15456 to 15624 restore points on your repository. Is this for archival purposes to restore every version of a file?
Going back hourly normally I see is only needed for a short time period (a few days).

With the changes above, what is the max number of days I can enter here without causing undesirable issue? Thanks.

Just one rule: Immutability must be lower than your shortest job retention.
When every backup job has a retention of 92 days, I would set immutability to not higher than 92 days.
If you have a job with 30 days retention and one job with 92 days retention, I would set immutability to 30 days if both jobs are using this same backup repository.


Best,
Fabian

[koilkonnect]

Yes. That will work for this file server. Just to note, you will end up with backup chains of 168 restore points. There will be 15456 to 15624 restore points on your repository. Is this for archival purposes to restore every version of a file?
Going back hourly normally I see is only needed for a short time period (a few days).

I'm not doing it 24/7, just 12 times for each workday and 1 time each for Sunday and Saturday. That would make the backup chains of 62 restore points. I'm not quite sure how you get 15456 to 15624 restore points even with 24/7 hourly backup, so maybe I'm missing something. This is how I think the number of restore points would be calculated. Thanks.

1 backup x 24 hours x 92 days = 2208
1 backup each week for 52 weeks = 52
1 backup each monthly for 24 months = 24
1 backup each yearly for 4 years = 4
Total is 2288

[Mildur]

Yes, you are correct. My calculation had a mistake.

Best,
Fabian