unable to read tape before restore session

[Masternet]

Hi:

Ia have a problem to read Label of a tape when this is unloaded from drive.
This problem appear after read data from de same tape (recovery session).

In daemon.log exist the following message:
11/20/07 12:19:54 nsrlcpd #1: MOVE MEDIA INFO
11/20/07 12:19:54 nsrlcpd #1: source : D:000257
11/20/07 12:19:54 nsrlcpd #1: source attrlist : NULL
11/20/07 12:19:54 nsrlcpd #1: dest : S:004105
11/20/07 12:19:54 nsrlcpd #1: dest attrlist : NULL
11/20/07 12:20:06 nsrlcpd #1: LCPD_HDR: server:dfmcautin.difarma.cl vers:1 jbid:ML6010_S1 cmdid:2330 is_master=yes cmdop:UNLOAD.
11/20/07 12:20:06 nsrlcpd #1:
complete :no
11/20/07 12:20:06 nsrlcpd #1: offset:0 tag:S:004105 ok:yes full:yes barcode:000027L3 dest: ? bay:?
11/20/07 12:20:06 nsrlcpd #1: offset:0 tag:S:004105 ok:yes full:yes barcode:000027L3 dest: ? bay:?
11/20/07 12:20:06 nsrlcpd #1: offset:0 tag:S:004105 ok:yes full:yes barcode:000027L3 dest: ? bay:?
11/20/07 12:20:06 nsrlcpd #1:
11/20/07 12:20:06 nsrlcpd #1: offset:0 tag:000257 ok:yes full: no barcode: ? source:? serial#:? bay:?
11/20/07 12:20:06 nsrlcpd #1:

11/20/07 12:21:11 nsrd: [Jukebox `ML6010_S1', operation # 116]. Finished with status: failed
11/20/07 12:21:11 nsrmmgd: RAP error: Invalid resource data.
11/20/07 12:21:11 nsrmmgd: Cannot update operation status resource (instance 116).

My NW eviroment is Network edition for Linux 7.3.3

Thank's

Gabriel.

 

[605]

I do not exactly know what NW will do when unloading a media after a read session. However, why should it reread the label?

Let me suggest you run nsrjb from the command line with added verbosity to receive more details.

 

[Rif123]

You can configure the jukebox resource to reread the label before unmounting. That was added as a precaution that could be used for a shared environment that uses DDS drives. So if a SCSI bus reset makes a tape drive rewind and overwrite the label, it will be spotted before the tape is unmounted.

But, judging from the messagese in your daemon log, is it really the reading the label that is a problem? I think it looks more like the media cant be moved over to the right slot during the unload. Something a nsrjb -EH might take care of?

 

[Masternet]

Hi, Rif123: finally The tape was put in the right slot, but my problem is that:
NetWorker backup data.
I can recovery data.
When unload the tape, Networker mark the Save Set as suspect.
Verify label is enable.
On the message log file of OS I don't see SCSI Reset or LIP messages.....

My enviroment:
NW Server for Linux 7.3.3 on Redhat ES 3.0
10 Storage Node, same OS.
DDS for 2 drives
Dell ML6010 with 2 drive IBM LTO3, last firmware.

Thank's

 

[605]

Hmm, if NW can read/recover the save set, why should it be marked as suspect (usually due to read errors).

Look at the daemon.fog file for more details.
Try to use other programs (tar) to check whether you have a hardware problem.

 

[Masternet]

Hi:
I have this messagen on daemon.log

11/22/07 23:54:16 savegrp: Aborting inactive job (23328) admcorcovado:C:\
11/22/07 23:54:16 savegrp: Aborting inactive job (23329) admcorcovado:\
11/22/07 23:54:16 savegrp: job (23328) host: admcorcovado savepoint: C:\ had WARNING indication(s) at completion.
11/22/07 23:54:16 savegrp: Log file /nsr/tmp/sg.FULL_CLIENTE.admcorcovado.t6ZfFF is empty.
* admcorcovado:C:\ Cannot determine status of backup process. Use mminfo to determine job status.
11/22/07 23:54:16 savegrp: admcorcovado:C:\ unexpectedly exited.
11/22/07 23:54:16 savegrp: admcorcovado:C:\ will retry 1 more time(s)
11/22/07 23:54:16 savegrp: Log file /nsr/tmp/sg.FULL_CLIENTE.admcorcovado.iSiMGV is empty.
* admcorcovado:\ Cannot determine status of backup process. Use mminfo to determine job status.
11/22/07 23:54:16 savegrp: admcorcovado:\ unexpectedly exited.
11/22/07 23:54:16 savegrp: admcorcovado:\ will retry 1 more time(s)
11/22/07 23:54:19 nsrd: admcorcovado:\ saving to pool 'FS Semana 2 Sitio 1' (000027L3)
11/22/07 23:54:20 nsrd: admcorcovado:C:\ saving to pool 'FS Semana 2 Sitio 1' (000027L3)
11/23/07 00:00:56 nsrd: media notice: Save set (3930470477) admcorcovado:\ volume 000027L3 on /dev/nst1 is being terminated because: inactivity timeout
11/23/07 00:00:56 nsrd: admcorcovado:\ done saving to pool 'FS Semana 2 Sitio 1' (000027L3) 3352 MB
11/23/07 00:00:56 nsrd: write completion notice: Writing to volume 000027L3 complete


Then, the restore operation of client named "CORCOVADO" can't be made, and the tape is marked as suspect.

 

[605]

Don't want to be picky but there is no status "suspect" for a tape - it is just valid for a save set.

It looks like
- the client does not respond any more
- the backup will be aborted due to this timeout
- due to the fact that it is incomplete, it is marked as suspect
- consequently, the save set status will be set to "suspect"

It seems that this is no problem with the hardware but with the "network connection". Sorry, but this can not be more specific. Look at the hardware configuration and especially the correct name resolution.

 

[Masternet]

Guru's

I recently conducted the following tests:
From NW Server start a DIRECTER RECOVER to retrieve data from a SNODE. Select a directory to recover and start the task. Then NetWorker mount the tape in SNODE and retrieves data to NW Server.

The same operation will be conducted before mounting the tape device in NW server. Upon starting the restore operation, NetWorker can not read the tape.

Can not decode block. Verify the device configuration. Tape record by positioning is disabled.

Both NW Server and SNODE sharing 2 devices on SAN.

Thanks

 

[605]

This might have to do with a conflict of the two parameters "recover storage node" (for the client) and "read hostname" (for the jukebox). Obviously the media will be mounted in one device but NW might read from the other one.

It is not so easy to explain that but please have a look in this direction.

 

[Masternet]

HI:

The Error message guide of NetWorker show that problem is data block size, with a example on SOLARIS to fix it.
How I fix this on LINUX REDHAT 3 ES????


Thank's.

 

[Rif123]

You probably want to check that you have configured the block size correctly on all storage nodes. You could have a look at the stinit.def file and also check out the parameters NSR_DEV_BLOCK_SIZE_???, both are documented in the admin and/or installation guide for NetWorker.