This post is more than 5 years old
5 Posts
0
2937
January 24th, 2010 17:00
Infinite loop requesting tape
There are some old Networker tapes I need to get files from, and so I set up a system and installed the version of Networker - well the Sun-rebranded Solstice Backup - version 6.1, patched with their patch 111962-10.
I believe I have the indexes restored right, though that was its own adventure. What I see now is that Networker wants the right tape, but somehow doesn't accept it when it's in the drive. This feels like a bug to me, but maybe someone can point me in the right direction. Here's what nsrwatch reports:
Device type volume
/dev/rmt/0ubn 8mm 5GB GS1-086 verifying label, moving backward 2 file(s)
Sessions:
rsys:root browsing
cyrus:/export/home (5/16/01) starting read of 653 MB
Messages:
Thu 12:12:29 PM /dev/rmt/0ubn mounted 8mm 5GB tape GS1-086 (write protected)
Thu 12:12:29 PM media info event: 8mm tape GS1-086 will be needed
Thu 12:12:43 PM media event cleared: confirmed mount of GS1-086 on /dev/rmt/0ubn
Thu 12:12:44 PM /dev/rmt/0ubn mounted 8mm 5GB tape GS1-086 (write protected)
Thu 12:12:44 PM media info event: 8mm tape GS1-086 will be needed
Thu 12:12:59 PM media event cleared: confirmed mount of GS1-086 on /dev/rmt/0ubn
Thu 12:12:59 PM /dev/rmt/0ubn mounted 8mm 5GB tape GS1-086 (write protected)
Thu 12:12:59 PM media info event: 8mm tape GS1-086 will be needed
Thu 12:13:14 PM media event cleared: confirmed mount of GS1-086 on /dev/rmt/0ubn
Thu 12:13:15 PM /dev/rmt/0ubn mounted 8mm 5GB tape GS1-086 (write protected)
Thu 12:13:15 PM media info event: 8mm tape GS1-086 will be needed
Thu 12:13:30 PM media event cleared: confirmed mount of GS1-086 on /dev/rmt/0ubn
Thu 12:13:30 PM /dev/rmt/0ubn mounted 8mm 5GB tape GS1-086 (write protected)
Thu 12:13:30 PM media info event: 8mm tape GS1-086 will be needed
Pending:
Thu 12:13:30 PM media info: 8mm tape GS1-086 will be needed
For a while I thought it was the write-protection, that somehow it wanted the tape writable - but apart from not making sense, un-protecting it doesn't change anything, and it seems like full tapes may be considered "write protected" to Networker... Any ideas?
Thanks!
0 events found
Hakan_Engman
57 Posts
0
January 28th, 2010 06:00
Ok, make sense.
mminfo -avq "volume=GS1-086" -r "volume,volid"
Should give you the information, but in some rare cases you need to filter the output from mminfo as
you are not supposed to have two volumes with the same name...
Run mminfo -avr "volume,volid" | grep "GS1-086" if you run into such a situvation.
To delete the ghost volume run:
nsrmm -d -V <volid>
Cheers,
Håkan
Hakan_Engman
57 Posts
0
January 25th, 2010 01:00
Hi,
What about the storage node field in the client definition of client cyrus ? Did cyrus run backup to the backup server or to a storage node.
Secondly what about pool restrictions, should give you another error message but, version 6.1 was a while ago.
regards
Håkan
artk2
5 Posts
0
January 25th, 2010 12:00
The storage node field just says "nsrserverhost" - from what little I know, that makes sense for the original setup. Since the original client isn't around anymore, there shouldn't be a problem restoring selected files to the local filesystem right?
How do I see about pool restrictions? I don't think there are any, but I'm not sure I'm looking in the right places. By the way, this server doesn't have X libraries so I'm doing it all command-line (nsradmin, etc...)
Hakan_Engman
57 Posts
0
January 26th, 2010 02:00
Hi,
It certanly looks like you didn't have any other storagenodes except for the backup server for that client, but if
nsradmin doesn't support visual mode.
nsradmin << EOF
print type:NSR pool
quit
EOF
Look for the devices attribute, but one other thing.
Did you set up remote access for root @ your restore machine on the source client?
regards
Håkan
artk2
5 Posts
0
January 26th, 2010 09:00
All the devices lines are empty (apart from the semicolon). Does that mean "no restrictions for this pool" or "no devices are allowed for this pool"?
I'm just trying to restore the files on the local filesystem on the backup server as the original client node doesn't exist any more (all we have from back then are these old tapes), so I wouldn't think there'd be any permissions issues - am I right about that?
Thanks for the help - this has been a long journey...
Hakan_Engman
57 Posts
0
January 26th, 2010 23:00
Hi,
Are you able to resolv the client then? Put "bogus" IP and orginal name inte hosts file of the backup server if it's not in DNS anymore.
Well permissions, you need to give the user on the backup server restore permissions to the data backed up from the orignal client, but I think
that should be ok as you are able to browse index of the client.
And the client is the same flavour as the backup server, UNIX to UNIX.
Do you get anything in the logs ? /nsr/logs/daemon.log ?
regards
Håkan
artk2
5 Posts
0
January 27th, 2010 11:00
The host does have an IP (though everything at that domain appears to be wildcarded for some reason)... I've tried putting it in hosts too and that doesn't get me anywhere.
Looking in that daemon log is useful though - I see the message: nsrmmdbd: WARNING: clients file missing from /usr/local/nsr/mm/mmvolume6 - seems like that could be a problem.
I did a few searches on cleaning up that situation, and it led me to trying "mminfo -mv" which shows me this very interesting bit of information:
GS1-086 23 MB 0.4% undef 0 KB 14 5000 MB 15185 3 8mm 5GB
E GS1-086 9375 MB full expired 0 KB 7 9500 MB 441 136 8mm
So it thinks there are two copies of the tape. This makes some sense because I tried a few things before I got the media indexes restored, some part of which could easily have made it think this tape was new somehow. The 0.4% is a little worrisome, but I've had the write protect tab on most of this time and don't think it's been written to. Is there a way to make it forget about that second version of the tape?
artk2
5 Posts
0
January 31st, 2010 07:00
That did it.
Thanks so much for helping me out - I couldn't have done it without you.
It seems like I must have messed up something earlier, though I can see how I got two versions of the tape - the media indexes I recovered were actually older than the tapes themselves (or at least older than the files that were subsequently saved on them). I guess scanning first and then recovering the media indexes might be bad practice (or perhaps I messed up an option).
Again, thanks!