Tape labeling

You can, but I wouldn't recommend it as Networker increases the last value by 1 for each subsequent tape. This can cause the order to be mixed up or the wrong tape to be recycled.

What you can do is to use two different label templates, one for LTO7 and one for LTO8 tapes by setting the prefix (fields).

Hmm, with "label" I meant the volume name (usually Networker just uses the barcode on the tape as volume name).

There also the volume id (volid) which seems to be some integer.

I'm not sure where the label templates come in, probably also it's just sth written on the tape and as long as it is always incremented there probably isn't a problem.

The main question (I guess) is what is considered to be the volume name. Is it AB1234 or AB1234Lx? (in the latter case there shouldn't be a problem)

I beg to differ.

I'm pretty sure that the template sets the volume name. Imagine having over 100 tapes with cryptic barcodes as names, how are you supposed to know what kind of backup you have stored there?

Example:

Ok.. let's say we use this:

Which results in this:

So is there still a problem?

@fabian_o​ I consider that somehwat peculiar reasoning? If you have a barcode reader, you always want to use that, so that you can always be exactly sure that a tape is actually the tape you think it is, simply by looking at the label?

Whatever the label is, does not matter, as long as there are no duplicates. If you can control the label formatting, you might want to use specific ranges for example, something we did with VTL's, however if you don't have nor need that kind of control for physical tape, it would not have been an issue whatsoever.

What gives an idea about what might be on the tape, is what you can use the pool for, so that you have some logic and for example would be able to separate DB log backups from DB full backups, so that they would never end up on the same tape?

I am talking huger tape libraries here, where you don't want any hassle, when tapes are to be removed and store anywhere else (or even picked up and stored offsite). Referring to the actual barcode is the only way to properly identify tapes.

Anything else is what NW can report about, so what pool is tape with a specific label, labeled into? And what data is located on that tape (and maybe even spread over other tapes as well)?

Not using barcode matching is a recipe for disaster (even though NW also will write the label to the beginning of the tape, but you don't want to have to put a tape into a drive and read the label to find out which tape it is? resetting a tape library, without needing to actually load-no-mount tapes but making a quick inventory based on the barcodes is also way quicker).

But then again, I might have become somewhat rusty wrg to actually using tape, as we went all-in on Data Domain as backup target. I don't miss them days of old, having to deal with nearly daily hardware issues of tape drives, tapes and robotic arms, due to large environments we had. We don't even use VTL on DD anymore.

My bad I was actually wrong at this point and mixed things up, thanks for the clarification.

Happens if you only work with virtual tapes, barcodes (readers) are not involved.

So what does it mean for me.

In the example that I showed above, can I use XL2001L7 _and_ XL2001L8 at the same time?
Very simply in the same pool, no hassle?

I suppose the label is XL2001Lx and not just XL2001 (the latter would result in a conflict as it could not know if L7 or L8 is meant)?

I dunno, nobody is able to answer this question. I have asked support, they said yes, then no...

Probably I am asking it the wrong way...

if memory serves me right, you can select specific settings for the library (depending on the library) to show the type extension.

If it now shows tapes with L7, is that also actually mentioned as the physical barcode label? If the lto type is mentioned and if it would also do that for the L8 type tape, then I'd assume the tapes to be recognized as different entities. so if for example the sji tools like sjirdtag (so to talk with the tape library outside of NW itself, so to see if for example the output from nsrjb actually matches which tape is in what drive or slot? This comes in handy especially if something was the matter with the tape library, the robotics arm or tape drives, so I used sjirdtag and sjimm a lot at the time) also show that the actual tape label is being seen and would differ, then very likely that is not going to cause any issues.

However is this just a theoretical exercise or actual occurrence? This as I cannot recall ever having had the same tape label more than once? I can recall that we could state what ranges we wanted to have at the time for various tape types being delivered.

Yes the label and the barcode (when I can using my mobile phone) shows the L-something suffix.

Indeed it's about (re)using the different ranges as you already guessed. Since we're hitting a limit with one of the ranges I thought about just reusing the existing ones, if they don't jeopardy the existing volume. It's a purely organizational issue, either we reuse the same range with L8 instead of L7, or we just use a new range to stay out of harm's way.

Maybe just using a new range would have saved me a lot of time trying to figure this out :)

Thanks.