Unsolved
This post is more than 5 years old
1.1K Posts
1
8548
Savesets not expiring - the retention time is invalid
Here is another strange one - I have one client which has a month browse/retention which has savesets that go back to February that have not expired - no dependency here and generally they are the only saveset on the tapes meaning they are holding up tape reuse - here is some mminfo data:
mminfo -q "client=s-cpp-cmfe01.net1.cec.eu.int,name=C:\\" -ot -r volume,savetime,ssretent,level,clretent,ssflags
...2B1517 02/02/09 03/02/09 full 03/02/09 vF
2B1538 02/03/09 03/03/09 full 03/03/09 vF
2B1541 02/03/09 03/03/09 full 03/03/09 vF
2B1535 02/04/09 03/06/09 full 03/04/09 vrEF
2B1624 02/05/09 03/06/09 full 03/05/09 vrEF
2B1587 02/06/09 03/07/09 full 03/06/09 vrEF
2B1571 02/06/09 03/07/09 full 03/06/09 CvrEF
2B1571 02/06/09 03/07/09 full 03/06/09 CvrEF
2B0011 02/07/09 03/08/09 full 03/07/09 vrF
2B0956 02/07/09 03/08/09 full 03/07/09 vrF
A93674 02/07/09 03/08/09 full 03/08/09 vrF
2B0257 02/08/09 03/09/09 full 03/08/09 vrF
A93582 02/08/09 03/09/09 full 03/09/09 vrF
2B0210 02/09/09 03/11/09 full 03/09/09 vrF
A92929 02/09/09 03/11/09 full 03/11/09 vrF
2B0202 02/09/09 03/11/09 full 03/09/09 vrF
A91516 02/09/09 03/11/09 full 03/11/09 vrF
2B0506 02/10/09 01/19/38 full 01/19/38 vKF
A91526 02/10/09 01/19/38 full 03/11/09 vKF
2B0217 02/10/09 03/12/09 full 03/10/09 vrF
A91077 02/10/09 03/12/09 full 03/12/09 vrF
2B1163 02/12/09 02/12/09 full 03/12/09 vrF
2B0685 02/23/09 03/24/09 full 03/23/09 vrF
A94073 02/23/09 03/24/09 full 03/24/09 vrF
T00602 02/24/09 05/01/09 full 05/01/09 vF
etc (from here the same all the way down)
I looked at a specific piece of media and ran nsrim -V volume to see if it marked the tape as recyclable - some of the messages which may be important are:
-----------------------
s-net1luxdc88:G:\, 6 browsable cycle(s)10066:nsrim: Failed updating continuation save set ssid `3707290228' as purged
39077:nsrim: error, Save set ssid `3707290228' the retention time is invalid
10067:nsrim: Failed updating continuation save set ssid `3707290228' as eligible
39077:nsrim: error, Save set ssid `3707290228' the retention time is invalid
9335:nsrck: WARNING: no valid save times for client 's-net1luxdc88' - cross check not performed
A93674: 308 GB used, 7 save sets, full, 1 recoverable save sets, 6 recyclable save sets
-----------------------
Note the saveset 3707290228 is not on this tape though the saveset name is and has been marked as recyclable; also all savesets for s-net1luxdc88 on this media are recyclable. These messages may therefore be red herrings?
Next I ran nsrck -L6 s-cpp-cmfe01.net1.cec.eu.int which went through as expected:
nsrck: checking index for 's-cpp-cmfe01.net1.cec.eu.int'
nsrck: /nsrsrv30/nsr/index/s-cpp-cmfe01.net1.cec.eu.int contains 3485803 records occupying 457 MB
nsrck: Completed checking 1 client(s)
And another nsrim with no effect:
A93674: 308 GB used, 7 save sets, full, 1 recoverable save sets, 6 recyclable save sets
The saveset in question here was taken 7 February with month browse and retention and with successful full backups taken afterwards so what could be preventing this saveset expiring?
mminfo -q "client=s-cpp-cmfe01.net1.cec.eu.int,name=C:\\" -ot -r volume,savetime,ssretent,level,clretent,ssflags
...2B1517 02/02/09 03/02/09 full 03/02/09 vF
2B1538 02/03/09 03/03/09 full 03/03/09 vF
2B1541 02/03/09 03/03/09 full 03/03/09 vF
2B1535 02/04/09 03/06/09 full 03/04/09 vrEF
2B1624 02/05/09 03/06/09 full 03/05/09 vrEF
2B1587 02/06/09 03/07/09 full 03/06/09 vrEF
2B1571 02/06/09 03/07/09 full 03/06/09 CvrEF
2B1571 02/06/09 03/07/09 full 03/06/09 CvrEF
2B0011 02/07/09 03/08/09 full 03/07/09 vrF
2B0956 02/07/09 03/08/09 full 03/07/09 vrF
A93674 02/07/09 03/08/09 full 03/08/09 vrF
2B0257 02/08/09 03/09/09 full 03/08/09 vrF
A93582 02/08/09 03/09/09 full 03/09/09 vrF
2B0210 02/09/09 03/11/09 full 03/09/09 vrF
A92929 02/09/09 03/11/09 full 03/11/09 vrF
2B0202 02/09/09 03/11/09 full 03/09/09 vrF
A91516 02/09/09 03/11/09 full 03/11/09 vrF
2B0506 02/10/09 01/19/38 full 01/19/38 vKF
A91526 02/10/09 01/19/38 full 03/11/09 vKF
2B0217 02/10/09 03/12/09 full 03/10/09 vrF
A91077 02/10/09 03/12/09 full 03/12/09 vrF
2B1163 02/12/09 02/12/09 full 03/12/09 vrF
2B0685 02/23/09 03/24/09 full 03/23/09 vrF
A94073 02/23/09 03/24/09 full 03/24/09 vrF
T00602 02/24/09 05/01/09 full 05/01/09 vF
etc (from here the same all the way down)
I looked at a specific piece of media and ran nsrim -V volume to see if it marked the tape as recyclable - some of the messages which may be important are:
-----------------------
s-net1luxdc88:G:\, 6 browsable cycle(s)10066:nsrim: Failed updating continuation save set ssid `3707290228' as purged
39077:nsrim: error, Save set ssid `3707290228' the retention time is invalid
10067:nsrim: Failed updating continuation save set ssid `3707290228' as eligible
39077:nsrim: error, Save set ssid `3707290228' the retention time is invalid
9335:nsrck: WARNING: no valid save times for client 's-net1luxdc88' - cross check not performed
A93674: 308 GB used, 7 save sets, full, 1 recoverable save sets, 6 recyclable save sets
-----------------------
Note the saveset 3707290228 is not on this tape though the saveset name is and has been marked as recyclable; also all savesets for s-net1luxdc88 on this media are recyclable. These messages may therefore be red herrings?
Next I ran nsrck -L6 s-cpp-cmfe01.net1.cec.eu.int which went through as expected:
nsrck: checking index for 's-cpp-cmfe01.net1.cec.eu.int'
nsrck: /nsrsrv30/nsr/index/s-cpp-cmfe01.net1.cec.eu.int contains 3485803 records occupying 457 MB
nsrck: Completed checking 1 client(s)
And another nsrim with no effect:
A93674: 308 GB used, 7 save sets, full, 1 recoverable save sets, 6 recyclable save sets
The saveset in question here was taken 7 February with month browse and retention and with successful full backups taken afterwards so what could be preventing this saveset expiring?
DavidHampson
1.1K Posts
0
July 31st, 2009 06:00
Phil_1
20 Posts
0
July 31st, 2009 09:00
I have loads of tapes that do not expire. I cannot run a delete on the cover savesets, well I can, but they do not work.
The part "This save set will be deleted when the associated data save set has expired and is removed from the media database." seems to be a chicken/ egg situation, as they are both on the same volume, and although they are expired, they are still in the media database until the volume has been recycled. Since the cover saveset is holding the tape from being recycled, the associated saveset cannot be removed from the media database.
What we have to do is manually do the work that NetWorker is supposed to do. We manually check the older volume that should have expired, and can only relabel the volume, as this seems to fix it and remove the ssid from the indexes, which I now understand is due to this 'design'.
We do not make use of VSS (we use VSS Save operations: VSS=*off), only PowerSnap for filesystems and SQL.
We are upgrading NW server and S/N from 7.3.3 to 7.5.1. We have done this in pre-prod (with a few issues left to fix), and plan in live for next month (18th Aug).
We are planning to upgrade NetWorker client software next week in pre-prod, for all clients and modules (NME/ NMS/ PowerSnap).
Unfortunately we are 100% Win 2003 SP1 (not SP2).
We followed the NetWorker procedure generator, however there were glaring mistakes in it.
Phil
DavidHampson
1.1K Posts
0
August 3rd, 2009 02:00
I'd be very cautious about manually deleting tapes unless you are hundred percent sure you can relabel them. Networker "should" manage everything, if you get to a point where it is not then chances are you have configured something wrong, you have a misunderstanding as to how it is working, or less likely some kind of bug!
I'd suggest first of all running nsrim -V volumename against a tape you believe should be recyclable - it will check the tape against the media database and give you a summary at the end on the state of all savesets - if all savesets are not recyclable your tape will not be - you then need to determine why those savesets are not recyclable - use the mminfo command to inspect retention times of the savesets where ssrecycle=false; if it has passed out of its recycle date check that all instances of that saveset up to the next full backup have also expired - if you have a dependency it will not expire until the dependency also expires; if you manually delete it then the dependent saveset becomes invalid before its expiry - assuming when you say "at Barclays" you are in a financial institution you may be opening yourself up to fines from a regulatory body if you cannot prove you can recover data within a certain period!
One other thing I'd suggest, if you are under a lot of pressure to produce backup media every day you may be trying to do too much with too little, or you have failed to take into account data growth. You need to check if this is the case and take action before it becomes a serious problem!
joka2
144 Posts
0
September 9th, 2009 21:00
"The retention time for the 'VSS:\' save set is, by design, set to 1/18/2038. This save set will be deleted when the associated data save set has expired and is removed from the media database"
We are seeing this and the VSS:/ save set from the NMM clients is holding our tapes. We need to manually relable them, and we're doing that weeks after the save set is supposed to be recycled.
So what is the solution to this problem? Manually labelling tapes? hardly!
Joe
ble1
14.3K Posts
0
September 10th, 2009 03:00
matej_felle
41 Posts
0
August 9th, 2013 00:00
Hello,
Suddenly we have the same problems with VSS:\ save sets which has retention time 1/18/2038.
Have you found solution for that?
Thanks
bingo.1
2.4K Posts
0
August 9th, 2013 01:00
This is most likely due to so-called 'cover' save sets. They are created when you use the NMM module and will not expire (this time stamp is the most far away a 32bit UNIX time stamp can offer).
Run something like "mminfo -q ... -r ... sumflags" or "mminfo -q ... -r ... ssflags". If you see the 'K' in your flags, you got one.
-------------------------------------------------------------
And for the next time ... please open a new thread and do not mix your request with this old one. There might not even be any relationship any longer because the NW versions are so much different.