Topic: Backup failure - ideas?

[Des Dougan]

I run a weekly backup, via the server manager, to a Seagate Travan 5 tape drive on a new server. While I had the server in test mode, it backed up successfully. I recently migrated my production set up to the new hardware and customized te hbackup to run weekly. Over the last several weeks, each time the backup runs, it fails:

|------------------------------------------------
| Doing level 0 backup of all using dump
| Retensioning tape...
| Rewinding & erasing tape...
| Creating index key 200203030403.27
| Tape #0
| Filesystems = / /boot
|------------------------------------------------
At block 1.
|------------------------------------------------
| File number 1, index key 200203030403.27
| Backup of: /
| Date of this level 0 backup: Sun Mar 03 04:03:30 2002
| Date of last level 0 backup: the epoch
|------------------------------------------------
| (dump -0 -b 10 -a -f - / | gzip -4) | buffer -m 3m -s 10k -u 100 -t -p 75 -B \
|  -o /dev/nst0
|------------------------------------------------
  DUMP: Date of this level 0 dump: Sun Mar  3 04:03:30 2002
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/md1 (/) to standard output
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 2848604 tape blocks.
  DUMP: Volume 1 started at: Sun Mar  3 04:06:00 2002
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
buffer (writer): write of data failed: Input/output error
bytes to write=10240, bytes written=-1, total written         10K
  DUMP: Broken pipe
  DUMP: The ENTIRE dump is aborted.

However, if I run the backup again from the command line (/sbin/e-smith/backup), it works. I've seen the same behaviour each time over the past 3 weekends. Can anyone shed any light on why this is happening? I would have thought an erase operation (seen at the beginning of the backup output) would have resolved any header issues.


Des Dougan

[Jelke van der Meer]

Have you tried this:

/sbin/e-smith/db configuration setprop flexbackup erase_rewind_only false
/sbin/e-smith/signal-event console-save


I hope this will work for you as it did for me....

Jelke

[Ari]

Heya Des

I get the same message whenever I do a server reboot. My backup is done nightly and it always seems to happen the first time after a reboot. The second and consecutive nights thereafter are fine.

Not quite sure why it happens, but it's more of an inconvenience than anything else.

Anyone else have a similar experience?

Ari

[Des Dougan]

Jelke,

I haven't tried that, but I will, and report back.

Des Dougan

[Jelke van der Meer]

Hi Des and Ari,

I tried to figure out if my problem with the backup really was solved.
And I have to say it did not.....

I have still the same problem as Ari descripes...
After a reboot the first automated backup is in error, the second works fine...

It would be interesting to know if this has something to do with the Seagate streamer (I have a seagate travan also) or with e-smith SME.

Jelke

[Jelke van der Meer]

B.T.W. I have a SCSI drive, so it could be the termination of the cable....

[Jelke van der Meer]

Problem Solved!!!


Recently I removed the Seagate Tape Drive and put a HP Colorado T-20 in place. This is also a Travan (TR5) Tape drive. Everything works fine now also after a reboot of the server. But I discovered that this drive needs about one hour more time to backup my 10GB data.  I think the problem with the Seagate is the hardware compression of the drive itself...

[John Lewis]

I'm having the same problem.  Used to work fine, but then stopped at some point while still using 5.1.2.  I've upgraded to 5.5 hoping that the issue would have vanished with the upgrade.  No luck.  Automated and manual attempts to do backups fail with the same broken pipe error des mentions at the beginning of this thread.

Des, are you still having problems?

I have a Seagate Travan tape ide tape drive...

[Des Dougan]

Yes, I still haven't successfully resolved this. I did report a bug to Mitel, but it's not high on their list of priorities. I can make it work consistently by running the command again _without_ taking the tape out.

I did, howerver,  notice an oddity that I'm digging into. I was on vacation recently, at home, and had my tapes here rather than off site at my office. I therefore had a tape sitting in the drive for more than a day - and no failures (I run a weekly backup, BTW). Last weekend, however, when I put the tape in on Saturday night, it failed "as normal" when I checked on Sunday morning. I will mount this week's tape on Friday evening and monitor...


Des