adv_file did not recover space

  - "written" is also a statistical parameter. Just because you have deleted a save set does not mean that this info will change right away.

  - The physical deletion of save sets could have a delay of one day, depending on the start of the appropriate processes.

  - NW treats the volumes individually. Just because you label a media should not affect other instances of the same save set.

  - Obviously, PB152101=DADV01.001 is your volume name. It seems to be valid. However, let me recommend that you only use characters/separators which are listed in the label templates. Others could be misinterpreted.

  - Let me suggest that you use "nsrim", not "nsrim -X". See example below.

########### NW 8.2.1.1 (Windows) ############

D:\>nsrmm -d -S 4285447855

Delete file and media index entries for save set `4285447855'? y

D:\>mminfo -avot -r "written"

5000 MB

D:\>mminfo -avot

6095:mminfo: no matches found for the query

D:\>nsrim

86069:nsrim: Processing 1 clients

86068:nsrim: Managing 1 volumes.

AFTD_1: 5000 MB used,     0 save sets, appendable

86073:nsrim: Compressing media database.

D:\>mminfo -avot -r "written"

   0 KB

D:\>

Having = in name is asking for trouble.

Used for years without problems ;-)

Thank you for the exploration of the filesystem, I've found some ssid but they seems fine...

#mminfo -avot -q "ssid=b8ee9670-00000006-7559aa6d-5559aa6d-a28c2604-9a6ff402" -r "client,name,ssid,cloneid,totalsize(5),savetime,ssflags,volume"

client    name                          ssid          clone id total date  ssflags volume

client1   /dbs2/ISMM42ZE              1968810605  1431939693 40 GB 18.05.15 vF PB152101=DADV01.001

I'll try to delete some and see if I can get space.

As I said, deletions happens yesterday (and for some, before yesterday).

nsrim (with no parameters) shows me :

But volume seems to be still populated :

# mminfo -avot -r "written" PB152101=DADV01.001

4779 GB

NW treats the volumes individually. Just because you label a media should not affect other instances of the same save set.

First times I relabeled the volume, I lost my tape clones in the media database

deniscnqd wrote: Having = in name is asking for trouble. Used for years without problems ;-)

Some people have sex for years without problem too and then it happens

Your mminfo query doesn't show until when this is supposed to be kept, but bare in mind that it is backup made on 18th so if your retention is 1 month it should be there a bit more.  Also, you didn't include level information and you do not wish to break your backup cycle by removing something that is needed for full restore when doing PiT.

For why part you need debugging. One question, why clone to tape and not stage given that you remove it after that? Retention you can set on pool so when moved to tape pool it will get higher retention (ok, not sure if that works with staging, but with backup it does so I would assume same applies to staging).  I used to have similar setup in 2003 and I would usually stage via script by doing nsrstage (nowadays nsrclone -m) per device.  Back in those days you could not set retention on pool so I simply used same ssid list I previously generated and run something like:

for ssid in `cat ssid.lst`;do nsrmm -y -e '+1 month' -w '+1 month' -S $ssid;done

For debugging, I'll try the next century...

I don't stage because since clones tapes are externalized (for security), I want to keep saves online between two save sessions (2 times a month) for speed up recovery if needed.

I manually delete savesets the day before the new save.

Ah I see... I guess you have single tape/location... we had 2 so I would stage, reset policies and then clone from one PTL to another and if I had to export anything (which I had at the time) then secondary copy would be taken out.