Topic: Backup

[HAj]

I'm trying to backup on an ide tape drive. That was working before but one day it did that:
When i try to acces my ide tape drive under SME5.1.2, I've got
/dev/nst0: Input/output error

Because no one had any solution, i'm thinking about backing up on a windowsXP computer over the local network. Is it possible?????
I think I can easly backup on another drive but i'd like to know how to mount a windows shared folder.

PLEASE HELP !

PS:Excuse my poor english as I am french spoken.

[Vic]

See the following How-To from Darrell May:

http://www.myezserver.com/downloads/mitel/howto/flexbackup-to-disk-howto.html

[stephen noble]

you don't need to make *any* changes to the system
do an ordinary backup to desktop and point your download to the windows share

if you want this automated see
dungog.net/sme/faq.html ->custom backups

regards
stephen noble

[Jason Judge]

I may have a fix to this "Input/output error" problem. To confirm you are hitting the same problem as me, could you post the output from the following two Unix commands, both with and without a tape inserted:

mt -f /dev/nst0 tell
mt -f /dev/nst0 status

Ta,

-- Jason

[Des Dougan]

Jason,

These are the responses on my server (no tape loaded first).

[root@jeeves /root]# mt -f /dev/nst0 tell
/dev/nst0: Input/output error
[root@jeeves /root]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
 DR_OPEN IM_REP_EN
[root@jeeves /root]# mt -f /dev/nst0 tell
At block 0.
[root@jeeves /root]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x47 (unknown to this mt).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN
[root@jeeves /root]#

I'd be very interested in what you think is the cause of the problem.

Des Dougan

[HAj]

There it is (no tape loaded first).


[root@e-smith /root]#  mt -f /dev/nst0 tell    
/dev/nst0: Input/output error
[root@e-smith /root]#  mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
 DR_OPEN IM_REP_EN
[root@e-smith /root]#  mt -f /dev/nst0 tell
/dev/nst0: Input/output error
[root@e-smith /root]#  mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (10000):
 IM_REP_EN
[root@e-smith /root]#

[Jason Judge]

Des,

My workaround was to hack the backup script so that it didn't use the 'tell' tape command as that was causing the I/O errors. Instead I used the 'status' command and grepped for 'DR_OPEN' to check whether a tape was in or not.

However, I fixed it properly by upgrading the tape drive firmware (Compaq/Sony STD9000).

Looking at your output though, it seems your tape drive media is a very new type (0x47: TR-5). Would this be a Travan? Do you have any other media you could try? It may be worthwhile upgrading to a later RPM of 'mt-st'. I can't tell you if it would work, as I haven't tried it, but the latest version (0.7) does recognise your media type so may have fewer problems. SME uses version 0.5.

I would certainly check if there is a firmware upgrade for the tape drive first though, as the Input/Output error does not come from the 'mt' command, but from the Linux module behind the ioctl() function call. When you run the 'tell' command and get the Input/Output Error, you should get an entry from the kernel module in the 'messages' log. Try posting that here to see if there are any clues we can spot.

Check out the Redhat hardware compatibility list. If your drive is listed there as compatible, then it is almost certainly the firmware, the media or a dodgy SCSI terminator.

I'm no expert, but having looked at the 'mt' code and device drivers to try to work out what is happening, I am beginning to understand these tape drives a little more. Let me know how it goes.

-- Jason

[Des Dougan]

Jason,

Many thanks for your help.

Jason Judge wrote:
>
> Looking at your output though, it seems your tape drive media
> is a very new type (0x47: TR-5). Would this be a Travan? Do
> you have any other media you could try? It may be worthwhile
> upgrading to a later RPM of 'mt-st'. I can't tell you if it
> would work, as I haven't tried it, but the latest version
> (0.7) does recognise your media type so may have fewer
> problems. SME uses version 0.5.

Yes, this is a new Travan 5 drive, in a new server. I've upgraded the mt-st RPM as you suggested, but I get the same problem (in my case, this is that the backup fails with a "Broken Pipe" error when the tape is first put in the drive. Re-running the backup command after a failure, but leaving the tape in place, works OK.

> I would certainly check if there is a firmware upgrade for
> the tape drive first though, as the Input/Output error does
> not come from the 'mt' command, but from the Linux module
> behind the ioctl() function call. When you run the 'tell'
> command and get the Input/Output Error, you should get an
> entry from the kernel module in the 'messages' log. Try
> posting that here to see if there are any clues we can spot.

The firmware is at the latest level, and this tape drive (Seagate STT20000N) is on Mitel's list of supported devices. I just got a couple of new tapes, and can confirm that the problem exists with all the tapes I've tried.

I see the following messages in the messages log:

Apr 14 13:00:37 jeeves kernel: st0: Error with sense data: Info fld=0x2800, Current st09:00: sense key Illegal Request
Apr 14 13:03:52 jeeves kernel: st0: Error with sense data: Info fld=0x2800, Current st09:00: sense key Illegal Request
Apr 14 13:03:52 jeeves kernel: st0: Error with sense data: Info fld=0x1, Current st09:00: sense key Illegal Request
Apr 14 13:03:52 jeeves kernel: st0: Error on write filemark.


I also note that the failing backup indicates it's at block 1:

flexbackup version 0.9.8
/etc/flexbackup.conf syntax OK

|------------------------------------------------
| Doing level 0 backup of all using dump
| Retensioning tape...

| Rewinding & erasing tape...
| Creating index key 200204141337.29
| Tape #0
| Filesystems = / /boot
|------------------------------------------------
At block 1.
|------------------------------------------------
|

However, the working backup is at block 256:

flexbackup version 0.9.8
/etc/flexbackup.conf syntax OK

|------------------------------------------------
| Doing level 0 backup of all using dump
| Retensioning tape...
| Rewinding & erasing tape...
| Creating index key 200204141349.33
| Tape #0
| Filesystems = / /boot
|------------------------------------------------
At block 256.


In a previous posting to me on this subject, Darrell May noted:

"At block 1 means you are failing to write the
initial 32k block at the beginning of your backup.  In /sbin/e-smith/backup
you will find this:

/bin/dd if=/dev/zero of="/dev/nst0" bs=32k count=1 > /dev/null 2>&1

This should position the backup to start at a block far after 1.  On my
usage I start at block 85. "

I tried this via a template, but wasn't able to get any backup to run successfully at all.

I'm still unclear if this is a flexbackup issue or a hardware problem.


Thanks,

Des

[Jelke van der Meer]

I had the same problem, but since I replaced the Seagate by a HP Colorado T-20 drive (wich is also a 20GB Travan TR-5 drive) all my problems were gone.
So I'm sure it is a hardware problem. Hardware compression of the TapeDrive?????