@hend_bs, A saveset (index or otherwise) goes into an expired state when it crosses its retention period and when there are no other savesets depend on it. For example: A full saveset does not expire even though its retention has crossed if there are any other level or incremental savesets that are depended on it.
Of course, crazyrov's answer is true and valid. But let me make another comment.
As you can easily verify, the index backups following the full are set to level 1 (which is correct) but they already expired . This is wrong unless you changed their status manually. Usually, their correct status should also be recoverable. So if you did not manipulate their status' this could point to a bug.
If there is a chain still depending on the full, it should indeed show for all ssid's depending the same state, not that all inc. made after it would have already expired as then there would no longer be a dependency on an already expired full.
Same for regular filesystem backups or NW NMM backup that knows about a backup chain and its dependencies, unlike many other module backups.
You did not use the option, introduced in nw19 of O recall correctly to always keep the last full?
This as your query does not state any index backups expiring after aug. 5th? Or wasn't it a current query? So were there backups of this client after may 5th?
Haven't looked into that always-keep-last-full-backup feature and its ins and outs yet to see if that also applies therefor to the corresponding index entry?
crazyrov
4 Operator
•
1.3K Posts
1
August 26th, 2021 23:00
@hend_bs, A saveset (index or otherwise) goes into an expired state when it crosses its retention period and when there are no other savesets depend on it. For example: A full saveset does not expire even though its retention has crossed if there are any other level or incremental savesets that are depended on it.
hend_bs
1 Rookie
•
34 Posts
0
August 27th, 2021 01:00
Aha got it. Thank you
bingo.1
2.4K Posts
0
August 27th, 2021 03:00
Of course, crazyrov's answer is true and valid. But let me make another comment.
As you can easily verify, the index backups following the full are set to level 1 (which is correct) but they already expired . This is wrong unless you changed their status manually. Usually, their correct status should also be recoverable. So if you did not manipulate their status' this could point to a bug.
barry_beckers
393 Posts
0
September 5th, 2021 09:00
If there is a chain still depending on the full, it should indeed show for all ssid's depending the same state, not that all inc. made after it would have already expired as then there would no longer be a dependency on an already expired full.
Same for regular filesystem backups or NW NMM backup that knows about a backup chain and its dependencies, unlike many other module backups.
You did not use the option, introduced in nw19 of O recall correctly to always keep the last full?
This as your query does not state any index backups expiring after aug. 5th? Or wasn't it a current query? So were there backups of this client after may 5th?
Haven't looked into that always-keep-last-full-backup feature and its ins and outs yet to see if that also applies therefor to the corresponding index entry?