Technical Support Pages


My backup/verify failed with an I/O error "offset is XXXXXXXX" or tape write error 5
error 5 edge.summary tape write error I/O error
Product Release(s)
03.04.0x 03.03.0x 03.02.0x 03.01.0x 03.00.0x 02.03.0x 02.02.0x 02.01.0x 02.00.0x
Problem Description
My backup failed with a tape write error 5

An error 5 generated during a BackupEDGE process usually means some type of hardware problem.


The corrective measures would include lowering the blocking factor in edge.config(if > 64), trying a different tape, clean the drive heads, check termination (if SCSI), replace the ribbon cable to the drive, replace the drive, replace the controller.

This is going to be a "Process of Elimination", starting with the obvious.

  • 1. Be certain the tape isn't write protected.
  • 2. Be sure of power to the drive.
  • 3. Clean the heads on the tape drive.
  • 4. Use a brand new tape.
  • 5. Be logged in as 'root'.
  • 6. Make sure the tape is of the correct size for the drive.

    Assuming none of the above solves the problem after performing a Master backup, then we will proceed with more tests.

    How much data gets written to the tape before the process fails?

    If there is only a few files written before the error, then it is possible nothing gets written to the tape and the files are in memory.

    If, for example, you are able to write 100MB to the tape before an error, then we must see if the problem is the file or directory that displays at around 100Mb. Assuming the error is consistent at occurring at 100Mb.

  • 7. Do a selective backup of JUST the directory where the error occurs. If this is successful, then the file where the error occurred is not the problem. If it does fail on this same directory, take the tape drive out of the scenario. Meaning write an archive to a data file rather to the tape device.

    For example:

    This is the file that seems to fail: /usr/meddata/html/index.html

    Back it up to a file name using the following command.

    # tar cvbf 20 /tmp/junk.tar /usr/meddata/html.

    Notice we took BackupEDGE (edge) out of the picture also, in the event you have to contact a hardware vendor, they will not be able to pass it back to BackupEDGE. Also we backed up the entire directory '/usr/meddata/html' and not just the single file index.html.

    If this is successful use BackupEDGE to bit level the archive.

    # edge TTvbf 20 /tmp/junk.tar

    If this is successful, then the problem points back to the chain of hardware related to the tape drive.

    Remember to remove /tmp/junk.tar. If this fails, then your problem is not specific to the tape drive, and points more to the controller or cabling (including termination).

    7. If number 6 is successful, and the tape consistently dies at the same spot( ex:100Mb), then the problem points more towards the drive heads, or ribbon cable.

    8. Replace the ribbon cable first. Least expensive, most overlooked.

    9. Replace the tape drive

    10. Replace the controller.

    With problems such as this, consistency in the most difficult thing to pin point.

    Remember the driver is reporting errors to the kernel. Try to get tar to fail also to convince yourself of a hardware issue. Attempt a complete tar archive, log in as root and type:

    # tar -cvf /dev/rStp0 .

    Allow this to run, if this command fails, it too will generate an error.

  • Get a printer-friendly version of this document



    Last Updated - 2022/01/03