Forum Discussion

MariusD's avatar
MariusD
Level 6
14 years ago

Full Multiplexed Tapes

Hi,

I noticed  something in my backup enviroment.

We have just LTO4 Tapes (800GB/1.6TB) for backup.

Many tapes are with 430-480GB Full Multiplexed. How can be a LTO4 Tape with 430GB Full???

 

 

Regards

Marius Demeter

  • NetBackup only marks a tape as full when it is 'told' to do so by the operating system, which is told by the tape driver, which in turn is told by the drive.

    If there is an issue, the most likely cause will be one of those.

     

    Kindest regards,

     

    Martin

16 Replies

  • What i have to do? I have fireware updated to the last version (for library und drivers).

    Can I do something to solve this problem?

    TKS.

  • The latest firmware is not always the best !!!

    I'm always happy to be proved wrong ;0) - you could run the same backup data that is on the tape (this is important) to another tape using the os tar command, then the same again using the netbackup tar command - how much data is written ?

    I would chat with the driver suppliers, see what they say, the problem you might face though is that they may just point the finger at NBU ...  However, as I mentioned, NBU only marks a tape as Full when we are told to.

    There is an exception I have just thought about - there is a current issue with tapes positioning to the end of the physical media (should never happen) particularly noticeable on Windows and only affecting versions 6.5.6 and 7.0.1.

    If you have EEB 2140608 this will mark tapes Full if they have this particular issue (EEB is designed to do this as a workaround), and so you could see Full tapes with 'smalll' amounts of data.

     

    Martin

  • Netbackup always writes to the end of the tapes, if you have 10 images on the tape, and the first 9 expire, then you write to the end of tape = you will have a "full" tape with not much data on it...

    This is one of the issues you will strugle with, grasshopper.

  • is not this problem while the tapes are from Scratch_pool (empty tapes).

  • My first suspicion is the well known "shoe shining" factor. A lot of start/stop operation causes gap between data block (Inter-Record Gap). As the space used for inter block gap's does not hold data, it reduces overall capacity.

    As a test try to fill up one new tape with data from a high speed device. Either local disc arrays or some sort of random generated data (eg. a dd if you are running Linux/Unix). You need to archive at least 80MB/sec sustained data flow. Test more than one drive, as a dirty/worn out drive head will reduce the read/write speed and ruin test case.

     

    my 0,02