@dtwiley
My understanding is you could do something like you describe, using SOBR, and SOBR move.
For the SOBR:
- create the performance tier with immutability. I would suggest on the bucket/repo set immutability 4-7 days.
- create your capacity tiers (and archive tiers if you need them) without immutability enabled on the bucket
- THIS WILL ENSURE THEY ARE NOT IMMUTABLE
- enable move or move+copy for the SOBR so that data is moved out of performance tier to capacity/archive as you see fit
- on your job, ensure you enable GFS weekly at least to 1 ie have it enabled, even if you think you do no want it.
- the reason for this is that it ensures the move could process sooner, as well as the actual removal of no longer needed backups (that already had retention done but are still in storage due to immutability settings)
So what should happen:
- performance tier will be operating effectively with immutability == retention, or until the move happens (whichever occurs first)
- the move cannot happen until the data is no longer in the active chain, and nothing depends on it. This is why we set weekly at least to 1 to ensure this happens sooner. Weekly > 1 is also fine if you want to keep more weekly's
- when the data moves to capacity or archive or waterfalls to both, it will not be immutable in these tiers
- if this is what you want, you have long term backups not immutable.
Another options you have is to enable immutability for only capacity tier. If you do this, set immutability on that bucket to 7 days
- no point in setting it higher as we set weekly >= 1 in the job
- the data in capacity tier with these settings will be immutable for 7 days.
- you can raise the bucket to make the data more than 7 days, but given you want to eventually flow into archive tier, I would not go too big on this repo setting vs. when you want the data to flow to archive tier and be deleted from capacity tier
My understanding is you could do something like you describe, using SOBR, and SOBR move.
For the SOBR:
- create the performance tier with immutability. I would suggest on the bucket/repo set immutability 4-7 days.
- create your capacity tiers (and archive tiers if you need them) without immutability enabled on the bucket
- THIS WILL ENSURE THEY ARE NOT IMMUTABLE
- enable move or move+copy for the SOBR so that data is moved out of performance tier to capacity/archive as you see fit
- on your job, ensure you enable GFS weekly at least to 1 ie have it enabled, even if you think you do no want it.
- the reason for this is that it ensures the move could process sooner, as well as the actual removal of no longer needed backups (that already had retention done but are still in storage due to immutability settings)
So what should happen:
- performance tier will be operating effectively with immutability == retention, or until the move happens (whichever occurs first)
- the move cannot happen until the data is no longer in the active chain, and nothing depends on it. This is why we set weekly at least to 1 to ensure this happens sooner. Weekly > 1 is also fine if you want to keep more weekly's
- when the data moves to capacity or archive or waterfalls to both, it will not be immutable in these tiers
- if this is what you want, you have long term backups not immutable.
Another options you have is to enable immutability for only capacity tier. If you do this, set immutability on that bucket to 7 days
- no point in setting it higher as we set weekly >= 1 in the job
- the data in capacity tier with these settings will be immutable for 7 days.
- you can raise the bucket to make the data more than 7 days, but given you want to eventually flow into archive tier, I would not go too big on this repo setting vs. when you want the data to flow to archive tier and be deleted from capacity tier
Statistics: Posted by ericschott_OF — Jan 13, 2024 2:25 pm
