Veritas and tapes

[jawaner]

Aloha,

Does anyone know the process/steps that NetBackup uses when it decides to use a tape?  Does it just check the  Media database for the barcode and if it sees that it is listed as "available" it figures it's free to be used?  Or does it check the tape itself for some sort of header information?  My management is concerned of any undesirables being introduced to our systems and are about to implement a rule that all new tapes put into the tape library will have to be erased before being used.  I'm looking for information that would back me up as to why this is an unnecessary step.

Thanks.

[Darren_Dunham]

Netbackup volumes have a NBU header.  This is just text and you can easily read it yourself from a machine with something like 'dd'.  This is the RVSN (recorded volume serial number.  The EVSN (External...) is the barcode.

When a tape is needed, it confirms that the RVSN matches what it expects to find.  It can freeze a tape that has a mismatch.

What is the concern that they are trying to overcome by suggesting that tapes be erased?

-- 

Darren

[jawaner]

So, even if the tape is brand new (as in out of the box with an unused barcode attached to it), NetBackup still performs a scan on the RVSN?  Just wanted to clarify.

They are afraid that a virus can be introduced to the system from a tape.

[Stumpr2]

Everytime a tape is mounted in NetBackup an attempt is made to read the header.

NetBackup has its own header format. if a header is read and is not in netbackup format then the tape by default, will not be used and the media manager will freeze the tape. This can be overridden in the properties definition for the media server.

If the tape has a NetBackup header then it could be either a catalog header or data header. If it is a catalog header and if the tape is attempted to be used as a data tape, then the tape will be frozen. If it is a data tape and an attempt is made to use it as a catalog tape then the operation will fail.

If the RVSN does not match the EVSN then the tape is frozen.

Note:  Only new media will not have a label.  Upon first use, a NetBackup label is automatically written to the header of the tape.  Once written, the bplabel will not need to be repeated.

Standalone tape drives and its tapes are handled similiar but the bplabel process is done manually. makes sense since there is no robot to scan the external label :)

Message Edited by Stumpr on 01-29-2009 03:07 AM

[Darren_Dunham]

---

@jawaner wrote:

So, even if the tape is brand new (as in out of the box with an unused barcode attached to it), NetBackup still performs a scan on the RVSN?  Just wanted to clarify.

---

Yes.  Of course it won't find one if the tape is blank, and it will simply label the tape.

---

They are afraid that a virus can be introduced to the system from a tape.

---

Through the label checking procedure, or through some other mechanism?

Viruses require some path for data to be introduced and then executed.  You could get data onto a tape, but it's difficult for me to see how you'd get it executed.  The label isn't very large, and is probably handled with a simple string match.  With tapes where you read explicit blocks, it's even difficult for me to imagine a buffer overflow attack.

I won't go so far as to say such an attack is impossible, but because tapes are usually read explicitly rather than via any automated mount or filesystem methods, the points of attack are extremely limited.

-- 

Darren

Message Edited by Darren Dunham on 01-29-2009 09:01 AM

[Omar_Villa]

regarding your question of how NBU decides or pick's a tape I think is still a mistery because is not based on the space available under the tape or how many times is been use, normaly selects a media based on if is the fastest tape that can be accessed, like when they are already mounted on a drive, it will give preference to those medias than the ones that are just in the slot even if the one mounted is almost full, out of this how it selects the first media when nothing is mounted is not clear, at least for me.

regards.