ddboost auto retention lock?

"Automatic Retention Lock" is a DD based mechanism to control backup data. It does not work with a specific (backup) application but in general with all kinds of data. You can also see that as a 'file repository' where the data will be automatically deleted just based on the preset timing criteria.

If you have your backup software, I am sure that it has its own (BU software driven) mechanism to control the retention period which uses a specific driver for ddboost devices. Both solutions should of course not work at the same time.

From the BU software point-of-view, I would never use a DD driven retention at all because you always would need to remember that you have two 'mechanisms' which would most likely confuse you.

I see the automatic retention as a solution that older files will not be forgotten to be deleted. But by such a short period as 7 days, there is no specific rule to follow.

If you are using NetWorker, you can define the "DD Retention Lock Time" at a workflow's backup/clone action. Note that this is a separate setting besides the usual "Retention" setting.

what backup product are you using that is uses ddboost?

Not even all Dell backup products can hook into DD retention lock. For example Avamar can't. So I wonder if any non-Dell products natively can hook into that? Having to do things outside of the backup product is undesired as it must be aware that data is locked and would therefor not try prematurely to delete it as it is still locked and wouldn't be able to delete data (yet).

Something similar also goes for data in flight encryption from DD. It is only set on DD end. Any backup product is even unaware it is being used, but having a much better granular approach, discoverable or settable on for example Networker end, would be preferred, also to prevent also setting encryption on NW end on top of that, in effect breaking the effectiveness of DD deduplication on top of that.

So even though there is some tight integration between NW and DD, still things left to be desired for...

I'm looking forward to have an option to set it on a higher level as well, so to use it for all backups for example, as having to set it on each and every workflow, when you would like ALL data to use retention lock for a datazone wide amount of days, would make for a much easier setup and a way to make sure all data gets immutability for at least an x-amount of days of whatever.

I was told to think outside the box... This thought is an attempt at home brew ransomware protection. Write the data immutable x7 days... /shrug  As long as the data you are writing is clean... you should be good. But running immutable everyday x7 days makes for a big block of "dont touch me" data.