Without any further info, this is hard to tell.

NW obviously wants/needs to verify the label but only you can tell.

Next time you clone you should start a manual clone job (from the command line) and use another debug level (for example "-D5") Then you should see more info in the daemon.raw file.

It might be bug (in some of recent patches I have seen fix for issue like that), but without knowing which version you run it is pretty much all guesswork...

It is guress work, and i know i have not given much information but i dont have any more. This has been happening for some time. Originaly version 8.1.1.2 and also on 8.2.1.

There is no information in the logs as to what its looking for on the tape it requests. It mounts the tape, reads it for a few seconds then ejects it and networker carries on the orignal clone as normal.

Take a look when it occurs and inspect the savesets in the new tape clonned, and the old tape. Some relation should exist.

Here is my 2 cents worth...

Most likely a corrupted database or so it is going back and searching an old tape.

Did you try running nsrck -L7 to repair the database?

When you restarted Networker it no doubt ran the nsrck command and cleaned up the indexes

It hasn't happened to me but that is probably where I would start

Thanks, i will give this a go.

Thats where there is a problem. A tape is mounted and has written its save sets, networker then decided it wants a tape that was written to 3 days ago, i insert this tape, it only reads off it, it does not write to it. And the same with the original tape, nothing further is written to it. Its extremely difficult to pinpoint what its looking for.

What do we talk about at all? - Right now there are too many unknown parameters:

  - A NW server with at least 2 tape drives attached. No jukebox - correct?

  - Which backup level? - Do you run a full every day?

  - Why can you be so precise with your "2 tapes per day" - Are these 2 backup tapes or 1 backup & 1 clone tape per day?

  - The process is a clone job. If so, only the media index is involved - the CFI does not matter at all.

       - Volume clone or save set clone?

       - Automatic or scheduled clone job?

       - Scripted cloning?

  - The tape NW demands is obviously a source tape - correct?

Why should NW ask for an older tape at all?

  - Wrong script command?

  - Wrong device configuration (AMM?)

  - Wrong driver?

This is all I can suggest right now. First we have to clarify the scenario.

If that's the case then it does sound like it is looking at the index on the tape

It makes sense then that it would have to go back and look at the tape just to see what was already backed up.

I would assume that it is a clone of an incremental and not a full backup

You probably won't have another issue with at particular tape/clone

@Larry

"If it is an incremental backup and the indexes are messed up it would make sense that it would go back and look at the index on the previous backup."

In general you are right - however, this does not apply to cloning. Cloning exclusively relies on media db information.

IMHO it looks to me more as NW would go and verify a volume label (for whatever reason). I just do not understand why it would interrupt/pause an active process.

If it is an incremental backup and the indexes are messed up it would make sense that it would go back and look at the index on the previous backup.

Bingo is right that without the answer to the variables we cannot know for sure what is going on.

When Networker was restarted and it fixed the problem then that lead me to the conclusion that (more than likely) the indexes were messed up.

If that is the case then the real question is how did they get messed up?

Was there a backup failure?

There isn't an index stored at the start of the tape (as indicated by this being in use for about 5 seconds) unless it's a bootstrap/index backup.  As others have said, cloning doesn't look in any way at the client file indexes.  It clones savesets, not files.

Personally I'd recommend 2 things as you put the "re-requested" tape into the drive:

- use "dbgcommand -p debug=9" to get an idea what the mmd is doing while reading this

- Run the source clone from a storage node and trace communication from there to the NetWorker Server using Wireshark (on either end) with a filter of "host ".  Start the packet capture as you mount

Once done, expand a "Transmission Control Protocol" section, right click on "Stream Index" and "Apply as Column".  See in the top window section which stream index sends the most data, right click on this, Follow, Follow TCP Stream, and see the conversation that goes on between backup server and storage node at this point.

@ stuart You are right, I must have been thinking of SSID, sorry for the confusion

Update: Whilst i have been unable to figure out why its happening, i seem to have made it stop happening.

I changed the staging policy to stage the whole AFTD daily following the daily job. This seems to have stopped it getting its knickers in a twist so far.