Is there a way (registry\Other) to limit the size of the backup file offloaded from the SOBR Performance to Capacity Tier? If not, it would be a great feature.
Thanks,
Jim
-
- Novice
- Posts: 5
- Liked: 2 times
- Joined: Feb 06, 2021 8:37 pm
- Full Name: Jim Hester
- Contact:
-
- Chief Product Officer
- Posts: 31713
- Liked: 7218 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Capacity Tier Backup File Offload Size
Hi, Jim. Can you clarify what are you trying to achieve?
Keep in mind that offloaded to the Capacity Tier are NOT backup files, but unique data blocks in the specific restore point. And because the offload engine is forever-incremental (some would call this source-side deduplication), offloading that periodic 10TB full backup file sitting in your Performance Tier may only require 10GB of data transferred to and stored in the Capacity Tier.
Thanks!
Keep in mind that offloaded to the Capacity Tier are NOT backup files, but unique data blocks in the specific restore point. And because the offload engine is forever-incremental (some would call this source-side deduplication), offloading that periodic 10TB full backup file sitting in your Performance Tier may only require 10GB of data transferred to and stored in the Capacity Tier.
Thanks!
-
- Novice
- Posts: 5
- Liked: 2 times
- Joined: Feb 06, 2021 8:37 pm
- Full Name: Jim Hester
- Contact:
Re: Capacity Tier Backup File Offload Size
Gostev,
Let me clarify.....in this SOBR (set to store VM by VM) some VM backup files (Forward Incremental with Weekly Fulls) are large and some are not. We would like to only send VMs to archive that are smaller than 1TB from example. We are already splitting the fulls and incrementals (Performance tier) between tow different devices due to speed and capacity.
So I was wondering if there is a registry key that I could set that would look at the backup file size before it was ingested into the offload engine and limit it?
Thanks,
Jim
Let me clarify.....in this SOBR (set to store VM by VM) some VM backup files (Forward Incremental with Weekly Fulls) are large and some are not. We would like to only send VMs to archive that are smaller than 1TB from example. We are already splitting the fulls and incrementals (Performance tier) between tow different devices due to speed and capacity.
So I was wondering if there is a registry key that I could set that would look at the backup file size before it was ingested into the offload engine and limit it?
Thanks,
Jim
-
- Chief Product Officer
- Posts: 31713
- Liked: 7218 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Capacity Tier Backup File Offload Size
No, there's no such setting.
What you can do is create a separate SOBR, using the same storage for a Performance Tier - but without a Capacity Tier. Then you move VMs you don't want to offload to a separate backup job, and point the job to this new SOBR.
For managing backup jobs, the easiest way is to populate backup job with vSphere tags. You can have a tag assigned to the VM at the creation time, or changed later. And two backup jobs, each populated with the respective tag and pointed to their respective SOBRs.
I'm curious though, why do you want to archive smaller VMs, but not larger ones? I mean, if it makes economical sense to do for small VMs, why does it not make sense for all VMs?
What you can do is create a separate SOBR, using the same storage for a Performance Tier - but without a Capacity Tier. Then you move VMs you don't want to offload to a separate backup job, and point the job to this new SOBR.
For managing backup jobs, the easiest way is to populate backup job with vSphere tags. You can have a tag assigned to the VM at the creation time, or changed later. And two backup jobs, each populated with the respective tag and pointed to their respective SOBRs.
I'm curious though, why do you want to archive smaller VMs, but not larger ones? I mean, if it makes economical sense to do for small VMs, why does it not make sense for all VMs?
Who is online
Users browsing this forum: Google [Bot] and 10 guests