34 Posts
0
1742
issue scanning a tape volume
Hello,
I need to make an SSID browsable so to rebuilt the indexes I am using scanner -i command against the tape volume.
first problem I faced is LTO Ultrium version conflict (drives are LTO 7 and the tape is lTO 5) I fixed the issue by deleting the volume from mm DB (I kept a copy of old mm)using nsrmm -d command against the volume.
next I am receiving this error
[serviceBasis@SN~]$ sudo scanner -s lnxvib120 -i -S 1240990337 rd=SN:/dev/tape/by-id/scsi-35901b0e2223390d3-nst
8909:scanner: using 'rd=SN:/dev/tape/by-id/scsi-35901b0e2223390d3-nst' as the device name
8936:scanner: scanning LTO Ultrium-7 tape 102368L5 on rd=SN:/dev/tape/by-id/scsi-35901b0e2223390d3-nst
32350:scanner: adding LTO Ultrium-7 tape 102368L5 to pool MS Clone1
8753:scanner: unexpected file number, wanted 66 got 2
8761:scanner: done with LTO Ultrium-7 tape 102368L5
(I tried with all available drives of the library) I ve been reading answers on similar issue but it was back in 2010, that are mentioning that it could be a reset of the drive and data is probably lost.. I am concerned..
bingo.1
2.4K Posts
1
June 13th, 2021 07:00
First of all - you will only loose data if you (accidentally) relabel/recycle a volume. Hope you did not do that. To prevent this, you might also use the write-protect notch on the cartridge itself.
I wonder if you can use "scanner -i -S ssid..." right now because by deleting the volume from the media db you deleted the reference of that ssid and NW cannot directly resolve the ssid to a physical location on tape (file or tape mark and record number). So load the cartridge into the drive (NW will not be able to mount it yet) and run "scanner -m ..."
The block size should not matter - NW will adjust that by itself. The LTO drives will be able to read 2 versions back. Just make sure that the drivers will cover all versions.
bingo.1
2.4K Posts
0
June 16th, 2021 02:00
Of course, a save set could spread over more than one tape, indicated by
- h for "header"
- m for "middle part" (maybe more than one)
- t for "tail"
Unfortunately, if you delete the save set/volume info, you will loose this info as well.
hend_bs
34 Posts
0
June 14th, 2021 07:00
hello,
yes I figured it out so I tried to run scanner but I run it without options and against the whole volume and the same error appeared and the command stopped.
I will try to run it using -m switch and see
bingo.1
2.4K Posts
0
June 14th, 2021 08:00
Add ad least 2 "-v" for added verbosity and pipe the output to a text file.
hend_bs
34 Posts
0
June 16th, 2021 01:00
Hello again,
I have used " -im " switch, and the data became browsable.
Also I want to mention that apparently scanning the tapes in order of the flags "hr, mr, tr" is important. is it true?
hend_bs
34 Posts
0
June 19th, 2021 09:00
hello again,
In my case I marked needed tapes before deleting them from mm folder:
~]$ mminfo -avot -q "client=client" | grep "/vol001"
102348L5 LTO Ultrium-5 client 10/07/2016 10:16:01 PM 1700 GB 1240990337 mE full /srv/exports/vol001
102365L5 LTO Ultrium-5 client 10/07/2016 10:16:01 PM 2918 GB 1240990337 tE full /srv/exports/vol001
102368L5 LTO Ultrium-5 client 10/07/2016 10:16:01 PM 1033 GB 1240990337 hE full /srv/exports/vol001
right away after making the save set browsable, I was able to browse with the command "recover" from CLI , (but at that moment I did not resume the recover job because I had to ask again which folder to restore exactly):
but the good thing that I have copied the output before exiting:
recover> cd vol001
recover> changetime 10/07/16
6497:recover: time changed to Fri 07 Oct 2016 11:59:59 PM CEST
However next day I tried same command and the changetime returned:
recover> pwd
/srv/exports/vol001
recover> changetime 10/07/2016
6496:recover: cannot browse /srv/exports/vol001 as of `Fri 07 Oct 2016 11:59:59 PM CEST'
I have made no changes and the save set is still browsable:
[serviceBasis@lnxvib120 ~]$ mminfo -q ssid=1240990337 -r volume,cloneid,sumflags,ssretent
volume clone id fl retent
102348L5 1480640050 mb 09/18/2021
102365L5 1480640050 tb 09/18/2021
102368L5 1480640050 hb 09/18/2021
Can any one explain this behavior and how to solve this?
bingo.1
2.4K Posts
0
June 19th, 2021 19:00
Well - where shall I start? - It seems that you are caught by the different NW time formats...
Usually, "savetime" or "savetime(#)" is the format which is understandable/readable for the user/admin. Unfortunately, it is not precise enough.
"nsavetime" would be much better as it uses the UNIX/Epoch time, counting in seconds from 01/01/1970. This time stamp is precise but not 'understandable' for the user/admin.
Just as an example, run a command like "mminfo -q= -r ssid, savetime, savetime(25), nsavetime, cloneid " and compare the output. First thing what you will notice is that nsavetime and cloneid will show the same numbers Of course all parts of a save set will have the same time stamps.
Now, if you use "changetime date" to define a certain savetime, this is unprecise because NW does not know which exact time you want. Therefore it 'auto-corrects' your input and includes ALL seconds for that day. This results in "date ... 11:59:59PM" to cover the whole day. This is exactly what you see. Of course you could also say "changetime= " or "changetime= " which will set the pointer to the exact second.
btw - if you want to get rid of the (potentially huge) file index for a save set, you have 2 options:
- nsrmm -o recyclable -S ssid/cloneid .... but
- nsrmm -o recoverable -S ssid/cloneid .... simply does not exist. For that purpose, you must 'purge' the save set with the command "nsrmm -dP -S ssid" and wait until the index will be cleaned by NW automatically or just run "nsrim" for all/that specific client.
Clear as mud?
hend_bs
34 Posts
0
July 1st, 2021 03:00
Hello,
Thanks. Crystal clear !
However in my case nsavetime and cloneid have different values.
I managed to find the tape that contains the index and nsrck -L7 worked and made data browsable.