Incorrect retention date !!!

[emret]

Hi, 

I set the retention of the backup 1 day but after the completed job when we check the images from the catalog it shows retention 2038. 

are there anyone have an any idea about his problem ???

[Nicolai · Accepted solution]

Is because you use Storage Lifecycle Policy. A image not processed by the SLP will have a expiration of 2038, when processed the original date is set.

[Andy_Welburn]

Double-check the schedule & correct for subsequent backups.

You can use the bpexpdate command to correct the retention period of images if required:

e.g.

bpexpdate -d <dd/mm/yy hh:mm:ss> -backupid <client_12345678>

or

bpexpdate -recalculate -ret <retention_level> -backupid <client_12345678>

***EDIT*** Unless Nicolai is correct & you are using SLP??

[Marianne]

As per Nicolai's post, when using SLP the initial backup copy will be set to infinite. Only when duplication has successfully completed will retention level be applied.

[emret]

why it happens like this ? is the retention date the depend on the duplication process ?

[Andy_Welburn]

how you two guys (esp Nicolai) knew SLPs were involved?

I know you're both very good at what you do but there's no mention of SLPs in the OP!!!

[emret]

still duplication process waiting on the queue. when this process completed l will check the retention date of the image.

[Will_Restore]

but what happens to all these 'infinite' retentions in 2038? 

[Nicolai]

I used at lot of time working with SLP's. So when emret mention the incorrect retention of 2038 is guessed he/she was using SLP's.

Well it could be a simple schedule misconfiguration - But I guess emret would have figured that out ;)

[Nicolai]

I don't know why Symantec wrote the code to handle the images like this. It fooled me serious the first time I encountered this behavior.

My own guess it's a safety feature to prevent a backup images to be deleted without being processed by a SLP.

[Andy_Welburn]

[J_H_Is_gone]

Just like windows had a 2000 issue - unix is going to have a 2038 issue  and everything in unix will expire!

So unix has to fix the epoch date thing so we can note dates beyound 2038.