The only place I have seen so far is in the configuration file for the store in /opt/omni/sdfs/etc/sdfs or Program Files\OmniBack\sdfs\etc. In the xml file you can find "immutabilityPeriod="10"". It looks like this is something that should be added to CLI and GUI. It may be worth a new post on Idea Exchange.

I'm checking further on this and also testing it. Obviously I need at least a day to see whether the modified immutability to 1 day has worked indeed. I'll come back here with results. Also if I can find a reason for which this is not possible in the GUI or with DPDUtils then I'll report it here.

I can confirm that changing the "immutabilityPeriod" in the store's xml file works and also it seems to be the only possible way. As said you could request an enhancement for this to get it implemented in DPDUtils and/or the GUI.

I also want to stress that this period is set store-wide. So for any object in the store, already existing or new ones, the period will be modified to the new value that is set.

Hi Koen,

Many thanks for checking on this for me. As this is a background task for me, I've not got back to it until today, before reading your response!

I did end up deleting the whole Dedupe Store to change the immutability setting, and found you can actually change it in the GUI when creating a store. I did end up setting the immutability to 0, hoping this will would allow me to expire backups in DP, and immediately allow me to run the DDelete Unprotected Media to get rid of the backups....but it did not! It gave no errors, or reasons, it just said 0 media out of 3 successfully erased. Weird behaviour. 

So next test, as per your explanation above I've changed the XML file to change the immutability from 0 to 1, and will check again on Monday to see what the state of play is with the backups I've expired, will they delete, will the automated media session actually delete the backups. 

Will update when I've tested some more.

Cheers, Andy

Hi Andy,

I was confused for a moment as I didn't see that message. But that's because I usually use the omnimm CLI command to erase expired media. When running it from the GUI, I was able to reproduce that popup message and most likely you see it because of this global parameter:

# DeleteUnprotectedMediaMinimumAge=seconds

# default: 86400
# Determines what is the minimum age of the medium to be deleted
# by omnimm -delete_unprotected_media.
# If a medium age is lower than this value (from time of
# creation), then it is skipped by omnimm.

While it's a good idea to keep some delay here, it doesn't need to be a full day. Maybe you can set it to 3600 seconds or something like that. For testing purposes, I typically set it to 10 seconds in my test environment.

I also wrote a document about this some time ago:

Support Tip: Why is my B2D medium not deleted while it is unprotected?

And yet another one which you may find interesting:

Support Tip: Why are immutable media purged from the Internal DataBase?

Hi Koen,

Yes, that's it, those are the parameters which were stopping me deleting the media. To confirm after a day the media did get auto-deleted by the daily delete of unprotected media. I realise now I was trying to do something that in reality I would not normally do, run a backup and then delete it immediately. I would normally set of oneoff test backup to retention of 1 day in DP and it would auto-delete the next day. Immutability would stop it if I'd set the immutability to more than 1 day.

So I've set the immutability to 1 day, left the MinimumAge option as 1 day, which is good enough for me. I've hit another issue, but I'll write that up in a new thread as it's unrelated. 

Cheers, Andy