Re: amfetchdump returns 'Error writing to fd 7: Broken pipe'
* Jean-Louis Martineau [20170220 14:24]: > On 20/02/17 11:47 AM, Jean-Francois Malouin wrote: > > Hi, > > > > Attempting to restore a DLE with amfetchdump with: > > > > su amanda -c "~amanda/sbin/amfetchdump -p -d tape:/dev/nst0 top localhost > > /data_/mica1 20170219 " | tar -xpGf - > > > > returns 'Error writing to fd 7: Broken pipe'. The logfile shows: > Assuming fd 7 is the pipe to tar, it means that tar exited before > amfetchdump send all the data, do you get any error from tar? > You can try to do it in 2 step: > > $ ~amanda/sbin/amfetchdump -p -d tape:/dev/nst0 top localhost /data_/mica1 > 20170219 > datafile > > Do the data file contain the backup? ls -l, file datafile > > $ tar -xpGf datafile > > Check system/selinux logs for error. Nothing relevant shows up in the host's syslog. Doing the restore in 2 steps as proposed by Jean-Louis terminates without an error: ~# pwd /holddisk/restore ~# su amanda -c "~amanda/sbin/amfetchdump -p -d /dev/nst0 top localhost /data_/mica1 20170219" > mica1.datafile dow:/holddisk/restore# echo $? 0 ~# tar -C /holddisk/restore/mica1 -xpGf mica1.datafile ~# echo $? 0 The amfetchdump debug file shows all is good. I know I had 2 issues in the same post: what about the 2nd one, amrestore not doing recursive restore? thanks, jf > > Jean-Louis > > > > > Mon Feb 20 11:26:03.128402078 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > xfer_cancel_with_error: Error writing to fd 7: Broken pipe > > Mon Feb 20 11:26:03.128432851 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > xfer_queue_message: MSG: > elt= version=0> > > Mon Feb 20 11:26:03.128457912 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > xfer_queue_message: MSG: > elt= version=0> > > Mon Feb 20 11:26:03.128835292 2017: pid 14583: thd-0x1502000: amfetchdump: > > Cancelling -> > > )> > > Mon Feb 20 11:26:03.128867340 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > sending XMSG_CRC message 0x317c810 > > Mon Feb 20 11:26:03.128878700 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > pull_and_write CRC: f9201a62 size 102900957184 > > Mon Feb 20 11:26:03.128886874 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > xfer_queue_message: MSG: > elt= version=0> > > Mon Feb 20 11:26:03.128900594 2017: pid 14583: thd-0x2e49c00: amfetchdump: > > xfer_queue_message: MSG: > elt= version=0> > > Mon Feb 20 11:26:03.129525236 2017: pid 14583: thd-0x1502000: amfetchdump: > > dest_crc: f9201a62:102900957184 > > Mon Feb 20 11:26:03.129946543 2017: pid 14583: thd-0x1502000: amfetchdump: > > /opt/amanda/perl/Amanda/Restore.pm:1892:info:4900012 100491264 kb > > Mon Feb 20 11:26:03.130359016 2017: pid 14583: thd-0x1502000: amfetchdump: > > /opt/amanda/perl/Amanda/Restore.pm:1920:error:4900055 Error writing to fd > > 7: Broken pipe > > Mon Feb 20 11:26:03.130501339 2017: pid 14583: thd-0x1502000: amfetchdump: > > /opt/amanda/perl/Amanda/Restore.pm:2137:error:4900068 Error writing to fd > > 7: Broken pipe > > > > What is the error all about? > > > > A previous amrecover run seems to have gone to all the motions > > correctly, but in the end the restore done in temp dir yield > > nothing...an empty directory... > > > > Any hint? > > Thanks, > > jf
Re: amfetchdump returns 'Error writing to fd 7: Broken pipe'
On 20/02/17 11:47 AM, Jean-Francois Malouin wrote: > Hi, > > Attempting to restore a DLE with amfetchdump with: > > su amanda -c "~amanda/sbin/amfetchdump -p -d tape:/dev/nst0 top localhost > /data_/mica1 20170219 " | tar -xpGf - > > returns 'Error writing to fd 7: Broken pipe'. The logfile shows: Assuming fd 7 is the pipe to tar, it means that tar exited before amfetchdump send all the data, do you get any error from tar? You can try to do it in 2 step: $ ~amanda/sbin/amfetchdump -p -d tape:/dev/nst0 top localhost /data_/mica1 20170219 > datafile Do the data file contain the backup? ls -l, file datafile $ tar -xpGf datafile Check system/selinux logs for error. Jean-Louis > > Mon Feb 20 11:26:03.128402078 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_cancel_with_error: Error writing to fd 7: Broken pipe > Mon Feb 20 11:26:03.128432851 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.128457912 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.128835292 2017: pid 14583: thd-0x1502000: amfetchdump: > Cancelling -> > )> > Mon Feb 20 11:26:03.128867340 2017: pid 14583: thd-0x2e49c00: amfetchdump: > sending XMSG_CRC message 0x317c810 > Mon Feb 20 11:26:03.128878700 2017: pid 14583: thd-0x2e49c00: amfetchdump: > pull_and_write CRC: f9201a62 size 102900957184 > Mon Feb 20 11:26:03.128886874 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.128900594 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.129525236 2017: pid 14583: thd-0x1502000: amfetchdump: > dest_crc: f9201a62:102900957184 > Mon Feb 20 11:26:03.129946543 2017: pid 14583: thd-0x1502000: amfetchdump: > /opt/amanda/perl/Amanda/Restore.pm:1892:info:4900012 100491264 kb > Mon Feb 20 11:26:03.130359016 2017: pid 14583: thd-0x1502000: amfetchdump: > /opt/amanda/perl/Amanda/Restore.pm:1920:error:4900055 Error writing to fd 7: > Broken pipe > Mon Feb 20 11:26:03.130501339 2017: pid 14583: thd-0x1502000: amfetchdump: > /opt/amanda/perl/Amanda/Restore.pm:2137:error:4900068 Error writing to fd 7: > Broken pipe > > What is the error all about? > > A previous amrecover run seems to have gone to all the motions > correctly, but in the end the restore done in temp dir yield > nothing...an empty directory... > > Any hint? > Thanks, > jf
Re: amfetchdump returns 'Error writing to fd 7: Broken pipe'
* Jean-Francois Malouin [20170220 11:47]: > Hi, > > Attempting to restore a DLE with amfetchdump with: Forgot to add: this with amanda-3.4.2 > > su amanda -c "~amanda/sbin/amfetchdump -p -d tape:/dev/nst0 top localhost > /data_/mica1 20170219 " | tar -xpGf - > > returns 'Error writing to fd 7: Broken pipe'. The logfile shows: > > Mon Feb 20 11:26:03.128402078 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_cancel_with_error: Error writing to fd 7: Broken pipe > Mon Feb 20 11:26:03.128432851 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.128457912 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.128835292 2017: pid 14583: thd-0x1502000: amfetchdump: > Cancelling -> > )> > Mon Feb 20 11:26:03.128867340 2017: pid 14583: thd-0x2e49c00: amfetchdump: > sending XMSG_CRC message 0x317c810 > Mon Feb 20 11:26:03.128878700 2017: pid 14583: thd-0x2e49c00: amfetchdump: > pull_and_write CRC: f9201a62 size 102900957184 > Mon Feb 20 11:26:03.128886874 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.128900594 2017: pid 14583: thd-0x2e49c00: amfetchdump: > xfer_queue_message: MSG: elt= version=0> > Mon Feb 20 11:26:03.129525236 2017: pid 14583: thd-0x1502000: amfetchdump: > dest_crc: f9201a62:102900957184 > Mon Feb 20 11:26:03.129946543 2017: pid 14583: thd-0x1502000: amfetchdump: > /opt/amanda/perl/Amanda/Restore.pm:1892:info:4900012 100491264 kb > Mon Feb 20 11:26:03.130359016 2017: pid 14583: thd-0x1502000: amfetchdump: > /opt/amanda/perl/Amanda/Restore.pm:1920:error:4900055 Error writing to fd 7: > Broken pipe > Mon Feb 20 11:26:03.130501339 2017: pid 14583: thd-0x1502000: amfetchdump: > /opt/amanda/perl/Amanda/Restore.pm:2137:error:4900068 Error writing to fd 7: > Broken pipe > > What is the error all about? > > A previous amrecover run seems to have gone to all the motions > correctly, but in the end the restore done in temp dir yield > nothing...an empty directory... Addendum to the amrecover: Doing 'add .' at the prompt in amrecover apparently will not descend recursively in the DLE: it just seems to add '.', and that's it. 'add *' will just add the matching files and directories, but again will not do a recursive restore. Makes amrecover a bit useless unless to restore single files. That's not the behaviour I had with previous version. Am I doing something wrong or overlooking something simple? jf > > Any hint? > Thanks, > jf -- Jean-Francois Malouin | IT Operations and Infrastructure McConnell Brain Imaging Centre | MNI | McGill University
amfetchdump returns 'Error writing to fd 7: Broken pipe'
Hi, Attempting to restore a DLE with amfetchdump with: su amanda -c "~amanda/sbin/amfetchdump -p -d tape:/dev/nst0 top localhost /data_/mica1 20170219 " | tar -xpGf - returns 'Error writing to fd 7: Broken pipe'. The logfile shows: Mon Feb 20 11:26:03.128402078 2017: pid 14583: thd-0x2e49c00: amfetchdump: xfer_cancel_with_error: Error writing to fd 7: Broken pipe Mon Feb 20 11:26:03.128432851 2017: pid 14583: thd-0x2e49c00: amfetchdump: xfer_queue_message: MSG: version=0> Mon Feb 20 11:26:03.128457912 2017: pid 14583: thd-0x2e49c00: amfetchdump: xfer_queue_message: MSG: version=0> Mon Feb 20 11:26:03.128835292 2017: pid 14583: thd-0x1502000: amfetchdump: Cancelling -> )> Mon Feb 20 11:26:03.128867340 2017: pid 14583: thd-0x2e49c00: amfetchdump: sending XMSG_CRC message 0x317c810 Mon Feb 20 11:26:03.128878700 2017: pid 14583: thd-0x2e49c00: amfetchdump: pull_and_write CRC: f9201a62 size 102900957184 Mon Feb 20 11:26:03.128886874 2017: pid 14583: thd-0x2e49c00: amfetchdump: xfer_queue_message: MSG: version=0> Mon Feb 20 11:26:03.128900594 2017: pid 14583: thd-0x2e49c00: amfetchdump: xfer_queue_message: MSG: version=0> Mon Feb 20 11:26:03.129525236 2017: pid 14583: thd-0x1502000: amfetchdump: dest_crc: f9201a62:102900957184 Mon Feb 20 11:26:03.129946543 2017: pid 14583: thd-0x1502000: amfetchdump: /opt/amanda/perl/Amanda/Restore.pm:1892:info:4900012 100491264 kb Mon Feb 20 11:26:03.130359016 2017: pid 14583: thd-0x1502000: amfetchdump: /opt/amanda/perl/Amanda/Restore.pm:1920:error:4900055 Error writing to fd 7: Broken pipe Mon Feb 20 11:26:03.130501339 2017: pid 14583: thd-0x1502000: amfetchdump: /opt/amanda/perl/Amanda/Restore.pm:2137:error:4900068 Error writing to fd 7: Broken pipe What is the error all about? A previous amrecover run seems to have gone to all the motions correctly, but in the end the restore done in temp dir yield nothing...an empty directory... Any hint? Thanks, jf
Re: amcheckdump fails with broken pipe
Hi, Le vendredi 21 janvier 2011 17:55:50, vous avez écrit : > I am finding that amcheckdump (3.2.0) gets sporadic failures with messages > like > > Reading volume AMB009L4 file 9 > Validation errors: > Error writing to fd 9: Broken pipe > /bin/gzip exited with status 1 maybe you should check the logs to have the gzip error message ? > > A similar problem was reported in > http://www.mail-archive.com/amanda-users@amanda.org/msg44288.html > but I'm not sure whether it is meant to be fixed in 3.2.0. > > In my configuration tar is not involved, the backup files are in > compressed dump format. So amcheckdump creates a pipe containing gzip and > restore; presumably gzip terminates when it gets to the end of the real > data and does not bother reading the zero padding at the end of the last > block. Unlike with tar I don't know any way of forcing gzip to > read till the bitter end. > > My blocks are 512kB and they are read over a slowish iscsi connection so > that possibly gives gzip plenty of time to process its data while the > rest of the block is still being read. > > I can live with the problem, but it is a bit irritating so any comments > welcome. > > Bob not sure it is related but I had some similar problem when trying to write my own verification script. I did something like that : amfetchdump -p -h ... > FETCH_PIPE & ( dd bs=32k of=HEADER_PIPE count=1; dd bs=32k of=DUMP_PIPE; )
amcheckdump fails with broken pipe
I am finding that amcheckdump (3.2.0) gets sporadic failures with messages like Reading volume AMB009L4 file 9 Validation errors: Error writing to fd 9: Broken pipe /bin/gzip exited with status 1 A similar problem was reported in http://www.mail-archive.com/amanda-users@amanda.org/msg44288.html but I'm not sure whether it is meant to be fixed in 3.2.0. In my configuration tar is not involved, the backup files are in compressed dump format. So amcheckdump creates a pipe containing gzip and restore; presumably gzip terminates when it gets to the end of the real data and does not bother reading the zero padding at the end of the last block. Unlike with tar I don't know any way of forcing gzip to read till the bitter end. My blocks are 512kB and they are read over a slowish iscsi connection so that possibly gives gzip plenty of time to process its data while the rest of the block is still being read. I can live with the problem, but it is a bit irritating so any comments welcome. Bob
Fw: Amanda 2.5.2p1-1 - Broken Pipe .....again
Additional information about this problem. An additional external USB hard drive has been added to this host about one month ago. The filesystem on this hard drive is not backed up with Amanda. But the observation is that the "Broken Pipe" problem seems to disappear when the filesystem on this hard disk is unmounted from the root filesystem. Any suggestions for resolving the problem are appreciated. Thanks in advance, Yogesh amdump.1 Description: Binary data
Amanda 2.5.2p1-1 - Broken Pipe .....again
Hi All, We use Amanda-2.5.2p1 for our daily incremental backup requirements. A single filesystem on a single host is backed up in this setup. The backup server and the client is the same host. The OS on the host is RHEL 3. The setup has been working reasonably fine for last two and half years, except for a few problems once in a while. Currently I am facing a problem in which the backup has failed for last one week and the error message that I receive in the email message is as follows: FAILURE AND STRANGE DUMP SUMMARY: /vol/vol1/home lev 0 FAILED [data write: Broken pipe] /vol/vol1/home lev 0 FAILED [input: Can't read data: : Connection reset by peer] /vol/vol1/home lev 0 FAILED [dump to tape failed] The same error was observed about a month ago. I had browsed through the wiki, in which I couldn't find a solution. So I just restarted my backup client/server which had solved the problem. I am trying to figure out whether the issue can be resolved without restarting the host. I have attached the amdump.1 file with this email. Would appreciate if I could get some guidance to resolve this issue and make sure that it doesn't occur again. Thanks, Yogesh amdump.1 Description: Binary data
Re: FAILED [data write: Broken pipe]
--- On Thu, 6/18/09, Jean-Louis Martineau wrote: From: Jean-Louis Martineau Subject: Re: FAILED [data write: Broken pipe] To: "Yogesh Hasabnis" Cc: amanda-users@amanda.org Date: Thursday, June 18, 2009, 6:02 PM Yogesh Hasabnis wrote: > gzip: stdout: Connection timed out This is weird, do your system automaticaly close connection after some time? After how many it happens? is it always the same? Jean-Louis No it doesn't. The backup system with amanda was working fine all these days. The problem has cropped up since last 4 days. All of the last 4 daily backups have failed. I am attaching the error message received in the email again. It's as follows: FAILURE AND STRANGE DUMP SUMMARY: /vol/vol1/home lev 0 FAILED [data write: Broken pipe] /vol/vol1/home lev 0 FAILED [input: Can't read data: : Connection reset by peer] /vol/vol1/home lev 0 FAILED [dump to tape failed] STATISTICS: Total Full Incr. Estimate Time (hrs:min) 1:26 Run Time (hrs:min) 5:27 Dump Time (hrs:min) 0:00 0:00 0:00 Output Size (meg) 0.0 0.0 0.0 Original Size (meg) 0.0 0.0 0.0 Avg Compressed Size (%) -- -- -- Filesystems Dumped 0 0 0 Avg Dump Rate (k/s) -- -- -- Tape Time (hrs:min) 0:00 0:00 0:00 Tape Size (meg) 0.0 0.0 0.0 Tape Used (%) 0.0 0.0 0.0 Filesystems Taped 0 0 0 Chunks Taped 0 0 0 Avg Tp Write Rate (k/s) -- -- -- USAGE BY TAPE: Label Time Size % Nb Nc tendaily-08 0:00 0K 0.0 0 0 FAILED AND STRANGE DUMP DETAILS: /-- /vol/vol1/home lev 0 FAILED [data write: Broken pipe] sendbackup: start [toe.tti.tensilica.com:/vol/vol1/home level 0] sendbackup: info BACKUP=/bin/gtar sendbackup: info RECOVER_CMD=/bin/gtar -f... - sendbackup: info end \ NOTES: planner: Incremental of toe.tti.tensilica.com:/vol/vol1/home bumped to level 2. taper: tape tendaily-08 kb 32064 fm 1 [OK] DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- - - -/vol1/home 0 FAILED (brought to you by Amanda version 2.5.0p2) Thanks in advance, Yogesh
Re: FAILED [data write: Broken pipe]
Post the complete amdump.? file Yogesh Hasabnis wrote: --- On *Thu, 6/18/09, Jean-Louis Martineau //* wrote: No it doesn't. The backup system with amanda was working fine all these days. The problem has cropped up since last 4 days. All of the last 4 daily backups have failed. I am attaching the error message received in the email again. It's as follows:
Re: FAILED [data write: Broken pipe]
Yogesh Hasabnis wrote: gzip: stdout: Connection timed out This is weird, do your system automaticaly close connection after some time? After how many it happens? is it always the same? Jean-Louis
Re: FAILED [data write: Broken pipe]
Any suggestions ? My backup has failed for 3 days now.
FAILED [data write: Broken pipe]
Hi All, We use Amanda 2.5.0p2 in our backup setup. We have the same host acting as the amanda backup server as well as the client. The OS on the backup server/client host is RHEL3. The setup has been working reasonably OK for the last 2 years. I am facing problems in backups for the last 2 days. The error message that I get in the email message is as follows: FAILURE AND STRANGE DUMP SUMMARY: /vol/vol1/home lev 2 FAILED [data write: Broken pipe] /vol/vol1/home lev 2 FAILED [data write: Broken pipe I see the following text in the /var/log/amanda//amdump file gzip: stdout: Connection timed out dumper: kill compress command driver: state time 29736.268 free kps: 1759 space: 284000 taper: idle idle-dumpers: 3 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 0 driver-idle: no-dumpers dumper: kill index command driver: interface-state time 29736.268 if : free 359 if LE0: free 400 if LOCAL: free 1000 driver: hdisk-state time 29736.268 hdisk 0: free 284000 dumpers 1 driver: result time 29736.268 from dumper0: FAILED 00-2 [data write: Broken pipe] driver: send-cmd time 29736.268 to chunker0: FAILED 00-2 driver: state time 35868.133 free kps: 1759 space: 284000 taper: idle idle-dumpers: 3 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 0 driver-idle: no-dumpers driver: interface-state time 35868.133 if : free 359 if LE0: free 400 if LOCAL: free 1000 driver: hdisk-state time 35868.133 hdisk 0: free 284000 dumpers 1 driver: result time 35868.133 from chunker0: PARTIAL 00-2 60480 [sec 14769.366 kb 60480 kps 4.1] driver: finished-cmd time 35868.133 chunker0 chunked :/vol/vol1/home Any help or suggestions in debugging this problem are appreciated. Thanks in advance. Yogesh
sendbackup: broken pipe
Hello, every now and then I see this error on an otherwise perfectly working Amanda system (server 2.4.4p3, client 2.5.1p1): FAILURE AND STRANGE DUMP SUMMARY: host.staso / lev 0 FAILED [data timeout] The client's sendbackup log for such a failed run: sendbackup: debug 1 pid 14726 ruid 34 euid 34: start at Fri Nov 21 22:46:00 2008 sendbackup: version 2.5.1p1 Could not open conf file "/etc/amanda/amanda-client.conf": No such file or directory sendbackup req: parsed request as: program `GNUTAR' disk `/' device `/' level 0 since 1970:1:1:0:0:0 options `|;bsd-auth;no-record;index;exclude-list=.backup.exc;exclude-optional;' sendbackup: start: host.stasoft.ch:/ lev 0 sendbackup-gnutar: time 0.006: doing level 0 dump as listed-incremental to '/var/lib/amanda/gnutar-lists/host.stasoft.ch__0.new' sendbackup-gnutar: time 0.010: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: time 0.015: spawning /usr/lib/amanda/runtar in pipeline sendbackup: argument list: runtar NOCONFIG gtar --create --file - --directory / --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/host.stasoft.ch__0.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendbackup._.20081121224600.exclude . sendbackup: time 0.078: started index creator: "/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'" sendbackup-gnutar: time 0.082: /usr/lib/amanda/runtar: pid 14729 sendbackup: time 0.083: started backup sendbackup: time 2996.696: index tee cannot write [Broken pipe] sendbackup: time 2996.718: pid 14728 finish time Fri Nov 21 23:35:57 2008 sendbackup: time 2996.697: 118: strange(?): sendbackup: index tee cannot write [Broken pipe] sendbackup: time 2996.751: 118: strange(?): sed: couldn't flush stdout: Broken pipe sendbackup: time 2996.779: 47:size(|): Total bytes written: 16497745920 (16GiB, ?/s) sendbackup: time 2996.780: 118: strange(?): gtar: -: Wrote only 4096 of 10240 bytes sendbackup: time 2996.781: 118: strange(?): gtar: Error is not recoverable: exiting now sendbackup: time 2996.781: parsed backup messages sendbackup: time 2996.781: pid 14726 finish time Fri Nov 21 23:35:57 2008 On the server side, the amdump log contains: [...] driver: send-cmd time 2015.907 to dumper0: FILE-DUMP 01-00032 /amholdingdisk/20081121/host.stasoft.ch._.0 host.stasoft.ch feff9ffeff / NODEVICE 0 1970:1:1:0:0:0 1048576 GNUTAR 49498848 |;bsd-auth;no-record;index;exclude-list=.backup.exc;exclude-optional; [...] driver: result time 6812.702 from dumper0: FAILED 01-00032 [data timeout] [...] Hmm, but most of the time I do _not_ see this problem. Any hints what could cause the problem or how to debug this further? Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
data-write: Broken pipe
Hi, We use amanda-2.5.0 for our backup requirements. The backup failed yesterday and the error message received in the email is as given below. Would like to get some advice about why this error may have occurred. FAILURE AND STRANGE DUMP SUMMARY:toe.tti.tensilica.com /vol/vol1/home lev 3 FAILED [data write: Broken pipe]driver: FATAL Don't know how to send ABORT command to chunkerchunker: FATAL error [bad command after RQ-MORE-DISK: "QUIT"] Also, after running the "ps -ef" command I observe that the "amdump" process is still running. The ouput of "ps -ef | grep amanda" is as follows: 30318 20267 1 0 Aug16 ? 00:00:00 /usr/lib/amanda/sendbackup root 20273 20267 93 Aug16 ? 16:00:37 gtar --create --file - --directory /vol/vol1/home --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/toe.tti.tensilica.com_vol_vol1_home_3.new --sparse --ignore-failed-read --totals . Is it OK if I kill this process using "kill -15 " or should I use something like "amcleanup" before I execute today's backup? Thanks in advance. Yogesh - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.
Re: index tee cannot write [Broken pipe]
Hi, Thanks, I checked the network setting and I don't find ipv6 active on any interface but I will keep checking a bit deeper in case it was on somewhere else. The link and error Paul pointed out may also have some merit. I will use ipmon and snoop tonight when the backup kicks off to see what is going on the network. I didn't see any references to the client on the server (in the /tmp/amanda/. debug files which strikes me funny). Thanks for the the help and pointers, Mike On Aug 2, 2007, at 2:47 PM, Dustin J. Mitchell wrote: On Thu, Aug 02, 2007 at 09:56:12AM -0400, Mike Gallant wrote: I have an amanda (2.5.1p3) server (solaris10) with seven amanda clients (2.4.4) and a new amanda (2.5.2) client on new hardware. I have been getting a "index tee cannot write [Broken pipe]" error message. I have looked at all the various aspects I can think of but still no joy. Could someone point me in the right direction for resolving this. I have included the sendbackup.debug (client) and a good part of the amandad (client) missing the repetitive entries. amandad: time 1800.842: stream_server: bind(in6addr_any) failed: Invalid argument amandad: time 1800.842: security_seterror(handle=30d90, driver=ff2dd95c (BSD) error=can't create server stream: Invalid argument) This looks like an IPv6 networking problem. Several such problems were fixed in the 2.5.1 -> 2.5.2 upgrade. Perhaps you could try upgrading? Dustin -- Dustin J. Mitchell Storage Software Engineer, Zmanda, Inc. http://www.zmanda.com/
Re: index tee cannot write [Broken pipe]
On Thu, Aug 02, 2007 at 09:56:12AM -0400, Mike Gallant wrote: > I have an amanda (2.5.1p3) server (solaris10) with seven amanda clients > (2.4.4) and a new amanda (2.5.2) client on new hardware. I have been getting > a "index tee cannot write > [Broken pipe]" error message. I have looked at all the various aspects I can > think of but still no joy. Could someone point me in the right direction for > resolving this. > > I have included the sendbackup.debug (client) and a good part of the amandad > (client) missing the repetitive entries. > amandad: time 1800.842: stream_server: bind(in6addr_any) failed: Invalid > argument > amandad: time 1800.842: security_seterror(handle=30d90, driver=ff2dd95c (BSD) > error=can't create server stream: Invalid argument) This looks like an IPv6 networking problem. Several such problems were fixed in the 2.5.1 -> 2.5.2 upgrade. Perhaps you could try upgrading? Dustin -- Dustin J. Mitchell Storage Software Engineer, Zmanda, Inc. http://www.zmanda.com/
Re: index tee cannot write [Broken pipe]
On 2007-08-02 15:56, Mike Gallant wrote:
I have an amanda (2.5.1p3) server (solaris10) with seven amanda clients
(2.4.4) and a new amanda (2.5.2) client on new hardware. I have been
getting a "index tee cannot write [Broken pipe]" error message. I have
looked at all the various aspects I can think of but still no joy.
Could someone point me in the right direction for resolving this.
The error "index tee cannot write" is the collateral damage of some
earlier problem. The index tcp-connection got closed, probably because
of some other error.
See also:
http://wiki.zmanda.com/index.php/Mesg_read:_Connection_reset_by_peer
which has a similar effect on the client.
Don't focus on this "index tee" but look earlier.
I'm interested in the error messages from the server-side as well.
I have included the sendbackup.debug (client) and a good part of the
amandad (client) missing the repetitive entries.
Thanks,
Mike
sendbackup: debug 1 pid 14529 ruid 105 euid 105: start at Thu Aug 2 01:55:27
2007
sendbackup: version 2.5.2
[...]
sendbackup: time 3.199: 91: normal(|): DUMP: Estimated 5852872 blocks
(2857.85MB) on 0.04 tapes.
So you're trying to dump less than 3 Gbyte.
sendbackup: time 3.245: 91: normal(|): DUMP: Dumping (Pass III)
[directories]
sendbackup: time 16237.077: index tee cannot write [Broken pipe]
Here the index tcp-connection got broken, proabably because the server
gave up on this host. The real problem happened much earlier.
(more than 4 hours after startup -- a really patient server :-) )
sendbackup: time 16237.077: pid 14531 finish time Thu Aug 2 06:26:04 2007
vReading conf file "/etc/opt/slis/amanda/amanda-client.conf".
[...]
amandad: time 0.005: security_getdriver(name=BSD) returns ff2dd95c
amandad: version 2.5.2
amandad: time 0.005: build: VERSION="Amanda-2.5.2"
amandad: time 0.005:BUILT_DATE="Thu May 24 22:05:16 EDT 2007"
Did it work correct before? Of do you struggle with the problem
until now?
[...]
amandad: time 0.024: accept recv REQ pkt:
<<<<<
SERVICE sendbackup
DUMP /zones 0 1970:1:1:0:0:0 OPTIONS |;auth=BSD;index;
>>>>>
amandad: time 0.024: creating new service: sendbackup
DUMP /zones 0 1970:1:1:0:0:0 OPTIONS |;auth=BSD;index;
amandad: time 0.028: sending ACK pkt:
<<<<<
>>>>>
amandad: time 0.028: dgram_send_addr(addr=30db0, dgram=ff2dddac)
amandad: time 0.028: (sockaddr_in *)30db0 = { 2, 731, 192.168.36.38 }
amandad: time 0.028: dgram_send_addr: ff2dddac->socket = 0
amandad: time 0.072: security_streaminit(stream=418f8, driver=ff2dd95c
(BSD))
amandad: time 0.072: try_socksize: send buffer size is 65536
amandad: time 0.072: try_socksize: receive buffer size is 65536
amandad: time 0.072: stream_server: Could not bind to any port: Invalid argument
Here is the problem, I believe, although I do not know what is wrong.
Some syscall is giving "EINVAL" on one of the arguments.
Do you have some weird network setup?
e.g. do you have a lower limit then 64k for UDP-packets etc.
amandad: time 0.072: stream_server: Retrying entire range after 10 second delay.
... and so on ...
amandad: time 1800.842: security_seterror(handle=30d90, driver=ff2dd95c
(BSD) error=can't create server stream: Invalid argument)
amandad: time 1800.842: couldn't open stream to server: can't create
server stream: Invalid argument
amandad: time 1800.842: security_streaminit(stream=418f8,
driver=ff2dd95c (BSD))
The upper layers repeating what the lower layers were saying...
amandad: time 1800.842: try_socksize: send buffer size is 65536
amandad: time 1800.842: try_socksize: receive buffer size is 65536
amandad: time 1800.842: stream_server: Could not bind to any port: Invalid
argument
amandad: time 1800.842: stream_server: Retrying entire range after 10 second
delay.
and starting again (not sure why??)
amandad: time 5402.381: stream_server: bind(in6addr_any) failed: Invalid
argument
in6addr_any?? suddenly using IPV6??
I believe 2.5.2p1 fixed some IPV6 bugs. (It has at least less bugs, so
better try that one. I'm using it without problems.)
amandad: time 16247.142: sending REP pkt:
<<<<<
CONNECT DATA -1 MESG -1 INDEX -1
OPTIONS features=9ffe00;
>>>>>
More trouble, proabably because of the previous ones.
Normally amandad should reply with the tcp-ports it has opened
for the three streams, and "-1" is of course not valid.
amandad: time 16247.142: dgram_send_addr(addr=49e40, dgram=ff2dddac)
amandad: time 16247.142: (sockaddr_in *)49e40 = { 2, 731, 192.168.36.38 }
amandad: time 16247.142: dgram_send_addr: ff2dddac->socket = 0
amandad: time 16257.150: timeout
amandad: time 16257.150: timeout waiting for ACK for our REP
But after 16000 seconds the server isn't expecting anything from this
host prob
index tee cannot write [Broken pipe]
I have an amanda (2.5.1p3) server (solaris10) with seven amanda
clients (2.4.4) and a new amanda (2.5.2) client on new hardware. I
have been getting a "index tee cannot write [Broken pipe]" error
message. I have looked at all the various aspects I can think of but
still no joy. Could someone point me in the right direction for
resolving this.
I have included the sendbackup.debug (client) and a good part of the
amandad (client) missing the repetitive entries.
Thanks,
Mike
sendbackup: debug 1 pid 14529 ruid 105 euid 105: start at Thu Aug 2
01:55:27 20
07
sendbackup: version 2.5.2
Reading conf file "/etc/opt/slis/amanda/amanda-client.conf".
Reading conf file "/etc/opt/slis/amanda/mwf/amanda-client.conf".
sendbackup: debug 1 pid 14529 ruid 105 euid 105: rename at Thu Aug 2
01:55:27 2
007
sendbackup req: |;auth=BSD;index;>
parsed request as: program `DUMP'
disk `/zones'
device `/zones'
level 0
since 1970:1:1:0:0:0
options `|;auth=BSD;index;'
sendbackup: start: bowen:/zones lev 0
sendbackup: time 0.015: dumping device '/dev/md/rdsk/d40' with 'ufs'
sendbackup: time 0.017: spawning /usr/sbin/ufsdump in pipeline
sendbackup: time 0.017: argument list: dump 0usf 1048576 - /dev/md/
rdsk/d40
sendbackup: time 0.019: started backup
sendbackup: time 0.052: started index creator: "/usr/sbin/ufsrestore -
tvf - 2>&1
| sed -e '
s/^leaf[]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: time 0.266: 91: normal(|): DUMP: Date of this level 0
dump: Thu
Aug 02 01:55:27 2007
sendbackup: time 0.267: 91: normal(|): DUMP: Date of last level 0
dump: the
epoch
sendbackup: time 0.267: 91: normal(|): DUMP: Dumping /dev/md/rdsk/
d40
(bowen:/zones) to standard output.
sendbackup: time 2.105: 91: normal(|): DUMP: Mapping (Pass I)
[regular files
]
sendbackup: time 2.576: 91: normal(|): DUMP: Mapping (Pass II)
[directories]
sendbackup: time 3.198: 91: normal(|): DUMP: Writing 32 Kilobyte
records
sendbackup: time 3.199: 91: normal(|): DUMP: Estimated 5852872
blocks (2857.
85MB) on 0.04 tapes.
sendbackup: time 3.245: 91: normal(|): DUMP: Dumping (Pass III)
[directories
]
sendbackup: time 16237.077: index tee cannot write [Broken pipe]
sendbackup: time 16237.077: pid 14531 finish time Thu Aug 2 06:26:04
2007
vReading conf file "/etc/opt/slis/amanda/amanda-client.conf".
amandad: time 0.005: security_getdriver(name=BSD) returns ff2dd95c
amandad: version 2.5.2
amandad: time 0.005: build: VERSION="Amanda-2.5.2"
amandad: time 0.005:BUILT_DATE="Thu May 24 22:05:16 EDT 2007"
amandad: time 0.005:CC="gcc"
amandad: time 0.005:CONFIGURE_COMMAND="'./configure' '--
prefix=/opt/slis
' '--with-user=amanda' '--with-group=amanda' '--with-libraries=/opt/
sfw/lib' '--
with-configdir=/etc/opt/slis/amanda' '--with-includes=/opt/sfw/
include' '--with-
krb5-security=/opt/slis/krb5' '--with-gnutar=/opt/slis/bin/tar' '--
with-portrang
e=5,50100'"
amandad: time 0.005: paths: bindir="/opt/slis/bin" sbindir="/opt/slis/
sbin"
amandad: time 0.005:libexecdir="/opt/slis/libexec" mandir="/
opt/slis/man
"
amandad: time 0.005:AMANDA_TMPDIR="/tmp/amanda"
AMANDA_DBGDIR="/tmp/aman
da"
amandad: time 0.005:CONFIG_DIR="/etc/opt/slis/amanda"
DEV_PREFIX="/dev/d
sk/"
amandad: time 0.005:RDEV_PREFIX="/dev/rdsk/" DUMP="/usr/sbin/
ufsdump"
amandad: time 0.005:RESTORE="/usr/sbin/ufsrestore"
VDUMP=UNDEF VRESTORE=
UNDEF
amandad: time 0.005:XFSDUMP=UNDEF XFSRESTORE=UNDEF
VXDUMP=UNDEF VXRESTOR
E=UNDEF
amandad: time 0.005:SAMBA_CLIENT="/usr/sfw/bin/smbclient"
amandad: time 0.005:GNUTAR="/opt/slis/bin/tar"
COMPRESS_PATH="//bin/gzip
"
amandad: time 0.005:UNCOMPRESS_PATH="//bin/gzip" LPRCMD="//
bin/lp"
amandad: time 0.005:MAILER="//bin/mailx"
amandad: time 0.005:listed_incr_dir="/var/opt/slis/amanda/
gnutar-lists"
amandad: time 0.005:DEFAULT_CONFIG="DailySet1"
amandad: time 0.005:NEED_STRSTR HAVE_SYSVSHM
LOCKING=POSIX_FCNTL SETPGRP
_VOID
amandad: time 0.005:DEBUG_CODE AMANDA_DEBUG_DAYS=4
BSD_SECURITY KRB5_SEC
URITY
amandad: time 0.005:RSH_SECURITY USE_AMANDAHOSTS
CLIENT_LOGIN="amanda"
amandad: time 0.005:FORCE_USERID HAVE_GZIP COMPRESS_SUFFIX=".gz"
amandad: time 0.005:COMPRESS_FAST_OPT="
Re: sendbackup: index tee cannot write [Broken pipe]
A few days ago I had some backup problems that turned out to be caused by a hanging NFS mount, causing "sendsize" to lock up completely - see a separate post on this. Now I have sorted out this problem, and it seemed like amdump would once again start properly, but it turns out that the backup still doesn't run properly - this time it's "sendbackup" that gets into trouble. The full sendbackup...debug from a failed dump is included below. [ ... ] Right. After looking a bit more at the logs etc. I'm no longer convinced that the error reported here is the main issue, and that it could be caused by a full disk - which I didn't think at first it might be, because I though I got the same behaviour for different configs with different holding space on different disks and I was convinced that they can't all have been filled up. Anyhow, the thing is, I've been getting the following strange and somewhat annoying (because I just can't understand what "stranded on waitq" is supposed to mean) error message: fileserv:/archive0 planner: [hmm, disk was stranded on waitq] This turned out to be caused by various sendsize processes hanging because of NFS access problems. Or at least, so I thought, but after sorting out these issues, I still get the same message. So I looked at the logs again and noticed the "index tee cannot write", but maybe it's just a coincidence that this started occurring right now, and that the other message is caused by something else entirely? - Toralf
sendbackup: index tee cannot write [Broken pipe]
A few days ago I had some backup problems that turned out to be caused by a hanging NFS mount, causing "sendsize" to lock up completely - see a separate post on this. Now I have sorted out this problem, and it seemed like amdump would once again start properly, but it turns out that the backup still doesn't run properly - this time it's "sendbackup" that gets into trouble. The full sendbackup...debug from a failed dump is included below. Does anyone have any idea what may be causing this? What exactly is this "index tee" trying to write to (file, FIFO, socket...)? Is there anything extra that needs to be cleaned up after problems caused by hanging sendsize processes? sendbackup: debug 1 pid 13900492 ruid 33 euid 33: start at Fri Mar 2 16:58:31 2007 sendbackup: version 2.5.0p2 parsed request as: program `GNUTAR' disk `/scanner/golg' device `/scanner/golg' level 0 since 1970:1:1:0:0:0 options `|;auth=BSD;srvcomp-fast;index;exclude-list=.amanda.excludes;exclude-optional;' sendbackup-gnutar: time 0.019: doing level 0 dump as listed-incremental to /usr/freeware/var/lib/amanda/gnutar-lists/fileserv_scanner_golg_0.new sendbackup-gnutar: time 385956.158: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: time 385956.592: spawning /usr/freeware/libexec/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory /scanner/golg --one-file-system --listed-incremental /usr/freeware/var/lib/amanda/gnutar-lists/fileserv_scanner_golg_0.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendbackup._scanner_golg.20070307041107.exclude . sendbackup: time 385956.603: started index creator: "/usr/freeware/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'" sendbackup-gnutar: time 385956.605: /usr/freeware/libexec/runtar: pid 14323097 sendbackup: time 385956.606: started backup sendbackup: time 385969.818: index tee cannot write [Broken pipe] sendbackup: time 385969.818: pid 14193336 finish time Wed Mar 7 04:11:21 2007 sendbackup: time 385969.842: 117: strange(?): sendbackup: index tee cannot write [Broken pipe] sendbackup: time 403598.554: error [/usr/freeware/bin/tar got signal 9] sendbackup: time 403598.615: pid 13900492 finish time Wed Mar 7 09:05:09 2007
Broken pipe on a big DLE
Hello!
I recently (this Sunday) upgraded my Amanda server to 2.5.0p2. Clients (other
than the server itself) are 2.4.4 and 2.4.5.
First two amdumps (Monday and Tuesday evenyng) ran fine, except that I forgot
to change the tape on Tuesday and had to run amflush on Wednesday. But the
Wednesday evening dump had two DLEs fail.
The reason of first one (tsensor.raad.tartu.ee /) I understand - it's caused
by a firewall on client not handling some TCP windowing stuff very well. This
has happened from time to time, even before upgrading the Amanda server, even
though the error message was a bit different.
The second one (heerold.raad.tartu.ee /home) is something new, however.
The situation with this DLE is that it is quite big and sometimes doesn't fit on
holding disk. With previous versions of Amanda it was started to dump on
holdingdisk,
then the holdingdisk filled up, then there was a "broken pipe" message in
syslog (but
not in Amanda report), then the DLE was restarted directly to tape and got
backed up
successfully.
It seems that now, once the holdingdisk fills up, the DLE is not restarted
directly
to tape, it just fails.
I think I might set "holdingdisk no" for this DLE since it often doesn't fit
anyway,
but the behaviour of Amanda in this situation still doesn't seem quite correct
to me.
Amanda report
Subject: TLV AMANDA MAIL REPORT FOR August 23, 2006
Date: Thu, 24 Aug 2006 03:32:58 +0300 (EEST)
From: [EMAIL PROTECTED] (System Operator)
To: [EMAIL PROTECTED]
*** THE DUMPS DID NOT FINISH PROPERLY!
These dumps were to tape PAEV33.
The next tape Amanda expects to use is: PAEV34.
FAILURE AND STRANGE DUMP SUMMARY:
tsensor.raad.tartu.ee / lev 0 FAILED [cannot read header: got 0
instead of 32768]
heerold.raad.tartu.ee /home lev 0 FAILED [data write: Broken pipe]
driver: FATAL Don't know how to send ABORT command to chunker
chunker: FATAL error [bad command after RQ-MORE-DISK: "QUIT"]
(brought to you by Amanda version 2.5.0p2)
Amanda report
sendbackup debug
sendbackup: debug 1 pid 36024 ruid 1034 euid 1034: start at Thu Aug 24 01:48:29
2006
/usr/local/libexec/amanda/sendbackup: version 2.4.4p4
parsed request as: program `DUMP'
disk `/home'
device `/home'
level 0
since 1970:1:1:0:0:0
options `|;auth=BSD;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.11081
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.11082
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.11083
sendbackup: time 0.000: waiting for connect on 11081, then 11082, then 11083
sendbackup: time 0.016: stream_accept: connection from 194.126.106.100.11083
sendbackup: time 0.035: stream_accept: connection from 194.126.106.100.11084
sendbackup: time 0.061: stream_accept: connection from 194.126.106.100.11085
sendbackup: time 0.061: got all connections
sendbackup: time 0.062: dumping device '/dev/da0s1g' with 'ufs'
sendbackup: time 0.063: spawning /sbin/dump in pipeline
sendbackup: argument list: dump 0ushf 1048576 0 - /dev/da0s1g
sendbackup: time 0.065: started index creator: "/sbin/restore -tvf - 2>&1 | sed
-e '
s/^leaf[]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: time 0.068: 93: normal(|): DUMP: WARNING: should use -L when
dumping live read-write filesystems!
sendbackup: time 0.068: 93: normal(|): DUMP: Date of this level 0 dump: Thu
Aug 24 01:48:29 2006
sendbackup: time 0.069: 93: normal(|): DUMP: Date of last level 0 dump: the
epoch
sendbackup: time 0.069: 93: normal(|): DUMP: Dumping /dev/da0s1g (/home) to
standard output
sendbackup: time 0.767: 93: normal(|): DUMP: mapping (Pass I) [regular
files]
sendbackup: time 2.676: 93: normal(|): DUMP: mapping (Pass II) [directories]
sendbackup: time 2.677: 93: normal(|): DUMP: estimated 17437291 tape blocks.
sendbackup: time 2.725: 93: normal(|): DUMP: dumping (Pass III)
[directories]
sendbackup: time 26.967: 93: normal(|): DUMP: dumping (Pass IV) [regular
files]
sendbackup: time 302.311: 93: normal(|): DUMP: 5.25% done, finished in 1:30
at Thu Aug 24 03:23:45 2006
sendbackup: time 602.284: 93: normal(|): DUMP: 11.48% done, finished in
1:17 at Thu Aug 24 03:15:36 2006
sendbackup: time 902.281: 93: normal(|): DUMP: 16.86% done, finished in
1:13 at Thu Aug 24 03:17:28 2006
sendbackup: time 1202.285: 93: normal(|): DUMP: 22.56% done, finished in
1:08 at Thu Aug 24 03:17:10 2006
sendbackup: time 1502.290: 93: normal(|): DUMP: 28.54% done, finished in
1:02 at Thu Aug 24 03:16:07 2006
sendbackup: time 1802.283: 93: normal(|): DUMP:
Re: broken pipe (WAS: Re: timeout while waiting for REP)
Cameron Matheson schreef: Well, Changing the etimeout/estimate-method in amanda.conf definitely helped, but now I'm getting a broken-pipe error. Here's the excerpt from this morning's e-mail: aspapp2.tonservices.com /opt/webapp/images lev 0 FAILED [data timeout] aspapp2.tonservices.com /opt/webapp/images lev 0 FAILED [dump to tape failed] taper: no split_diskbuffer specified: using fallback split size of 10240kb to buffer aspapp2.tonservices.com:/opt/webapp/images.0 in-memory taper: tape DailySet1012 kb 59249888 fm 25 [OK] That looks bad... I looked up what split_diskbuffer was in the amanda.conf manpage, but I'm not sure how setting that to anything different would help me (I think I'll just let it use its default until I understand it better). When Amanda writes to tape, and it bumps into end of tape, it needs to rewrite the whole chunk on the next tape (because you cannot be sure up to which byte did end up on tape, unless you write a filemark). The "tape_splitsize" indicates how large such a tapechunk ending with a filemark will be. In the worst case Amanda will loose that amount of tapecapacity at the end of a tape. That chunk needs to be buffered somewhere. If you're not using a holding disk, which would contain the complete dump file, then Amanda can use some diskspace to buffer that chunk: some file in the directory which you specify with "split_diskbuffer". As a last resort it buffers the data in memory, in which case the tape chunks now are only 10 Mbyte by default. A good choice for directory as "split_diskbuffer" is your holdingdisk directory. And if your machine has plenty of RAM, then increase the 10 Mbyte "fallback_splitsize" too. One remark: Amanda reads from the diskbuffer with a mmap() as large as the "tape_splitsize" value. This means that you are limited with your virtual memory how large that value can be. If you specify it too large, than Amanda will fall back to the fallback_splitsize, even you have have 100 Gbyte free holdingdiskspace. sendbackup: time 0.080: started backup sendbackup: time 33267.859: index tee cannot write [Broken pipe] sendbackup: time 33267.866: pid 15806 finish time Thu Jul 6 11:31:56 2006 sendbackup: time 33267.880: 117: strange(?): sendbackup: index tee cannot write [Broken pipe] [...] It takes 9 hours, so I can see why that might time-out, but I'm not sure why the pipe is closed... isn't the output from tar going over the network the entire time? How do I prevent this from occurring? Could it be yet another symptom of this problem here: http://wiki.zmanda.com/index.php/Amdump:_mesg_read:_Connection_reset_by_peer Try this and see if it helps: echo 180 > /proc/sys/net/ipv4/tcp_keepalive_time -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
broken pipe (WAS: Re: timeout while waiting for REP)
Hi, I'm back: On Wed, Jul 05, 2006 at 04:56:43PM -0600, Cameron Matheson wrote: > On Thu, Jul 06, 2006 at 12:36:43AM +0200, Peter Kunst wrote: > > try using a larger number (in seconds) for "etimeout" in your amanda.conf > > > > try "estimate server" within the dumptype used for that DLE (which is > > something new since, let me guess, can't remember, 2.5.x ?) > > Thanks, I had never changed the default 300 seconds which is no where > near long enough for this directory (I would need more like an hour). > That estimate server thing looks like just the ticket too (spending an > hour each night estimating would not be ideal). Well, Changing the etimeout/estimate-method in amanda.conf definitely helped, but now I'm getting a broken-pipe error. Here's the excerpt from this morning's e-mail: aspapp2.tonservices.com /opt/webapp/images lev 0 FAILED [data timeout] aspapp2.tonservices.com /opt/webapp/images lev 0 FAILED [dump to tape failed] taper: no split_diskbuffer specified: using fallback split size of 10240kb to buffer aspapp2.tonservices.com:/opt/webapp/images.0 in-memory taper: tape DailySet1012 kb 59249888 fm 25 [OK] That looks bad... I looked up what split_diskbuffer was in the amanda.conf manpage, but I'm not sure how setting that to anything different would help me (I think I'll just let it use its default until I understand it better). Anyway, Here's the excerpt from the sendbackup file on my client (Sorry, this is a little long): sendbackup-gnutar: time 0.000: doing level 0 dump as listed-incremental to /usr/local/var/amanda/gnutar-lists/aspapp2.tonservices.com_opt_webapp_images_0.new sendbackup-gnutar: time 0.076: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: time 0.079: started index creator: "/bin/gtar -tf - 2>/dev/null | sed -e 's/^\.//'" sendbackup: time 0.079: spawning /usr/local/libexec/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory /opt/webapp/images --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/aspapp2.tonservices.com_opt_webapp_images_0.new --sparse --ignore-failed-read --totals . sendbackup-gnutar: time 0.080: /usr/local/libexec/runtar: pid 15808 sendbackup: time 0.080: started backup sendbackup: time 33267.859: index tee cannot write [Broken pipe] sendbackup: time 33267.866: pid 15806 finish time Thu Jul 6 11:31:56 2006 sendbackup: time 33267.880: 117: strange(?): sendbackup: index tee cannot write [Broken pipe] sendbackup: time 33267.880: 117: strange(?): sed: couldn't flush stdout: Broken pipe sendbackup: time 33268.445: 46: size(|): Total bytes written: 20480 (20KiB, ?/s) sendbackup: time 33268.445: 117: strange(?): gtar: -: Cannot write: Broken pipe sendbackup: time 33268.445: 117: strange(?): gtar: Error is not recoverable: exiting now sendbackup: time 33268.633: error [/bin/gtar returned 2] sendbackup: time 33268.633: pid 15804 finish time Thu Jul 6 11:31:57 2006 It takes 9 hours, so I can see why that might time-out, but I'm not sure why the pipe is closed... isn't the output from tar going over the network the entire time? How do I prevent this from occurring? Thanks again, Cameron Matheson
Re: [out of tape] [dump to tape failed] ["data write: Broken pipe"]
Thank's a lot.. u put me on the right track...
After running dd as u said I knew what the problem was when it stopped at 2GB
What I did was to change filesystem on the disk from Fat32 to EXT3... wich accepts a
bigger filesize...
\\Reidar
- Original Message -
From: "Frank Smith" <[EMAIL PROTECTED]>
To: "Reidar Nordin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, August 30, 2004 2:33 AM
Subject: Re: [out of tape] [dump to tape failed] ["data write: Broken pipe"]
> --On Sunday, August 29, 2004 15:17:50 +0200 Reidar Nordin <[EMAIL PROTECTED]> wrote:
>
> >
> >> Your 'tape' is full. It doesn't necessarily mean the disk
> >> is full, it could be that your backups exceed your tape length.
> >> Look farther down in your report for the taper line and see if it
> >> wrote as many bytes as you specified for the length in your tapetype.
> >> If so, either increase your tape length (since you're really writing
> >> to a file instead of to a tape) or increase runtapes to write to
> >> multiple 'tapes'.
> >
> > I have increased the length in tapetype from 10GB to 20GB but still got the same
> > error as desc. before
> >
> > The dumpsummary for just this server (awe) says:
> > ***
> >
> >DUMPER STATSTAPER STATS
> > HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
> > awe /home 0 FAILED ---
> > awe /httpd/conf 0 200 55 27.5 0:00 272.6 0:00 240.5
> > awe -/local/adm 0 30 2 6.7 0:00 5.0 0:00 7.0
> > awe -/lib/mysql 0 184160 22300 12.1 1:19 282.1 1:19 282.0
> > ***
> >
> > From the end of my amanda log:
> > ***
> > INFO taper tape backup09 kb 2188064 fm 30 writing file: short write
>
> Looks like it died around 2 GB.
>
> > FAIL taper awe /home 20040828 0 [out of tape]
> > ERROR taper no-tape [[writing file: short write]]
> > FAIL driver awe /home 20040828 0 [dump to tape failed]
> > FAIL dumper awe /home 20040828 0 ["data write: Broken pipe"]
> > sendbackup: start [awe:/home level 0]
> > sendbackup: info BACKUP=/bin/tar
> > sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
> > sendbackup: info COMPRESS_SUFFIX=.gz
> > sendbackup: info end
> > FINISH driver date 20040828 time 2188.326
> > ***
> >
> >> I'm guessing you're not using a holding disk. While it's not as
> >> necessary using the file driver, it would allow multiple dumps to
> >> occur in parallel, which can shorten your backup window (using a
> >> different disk is recommended to lessen I/O contention)
> >
> > I am using hdb1 for my backup's (mounted FAT32 disk)
>
> I think this is your problem, I don't think FAT32 can't handle files
> greater than 4 GB (twice what you are erroring out at, but much smaller
> than your configured 'tape' size), but I think smbmount may have a 2 GB
> limit.
>
> Can you create a bigger file using dd ?
> dd if=/dev/zero of=/mounted/fat32disk/testfile bs=1024 count=500
>
> should create a 5 GB file in the path you specify with the of=, if it
> bombs at 2 GB then look into how it is mounted (could be samba or kernel
> problem). If you need files bigger than 4 GB on windows it needs to
> be NTFS and not fat32.
>
> > I am using hda2 as holding disk, this is my config in amanda.conf:
> >
> > ***
> > holdingdisk hda2 {
> > comment "main holding disk"
> > directory "/usr/local/etc/amanda/holdingdisk" # where the holding disk is
> > use -10 Mb # how much space can we use on it
> > # a non-positive value means:
> > #use all space but that value
> > chunksize 10Gb # size of chunk if you want big dump to be
> > # dumped on multiple files on holding disks
> > # N Kb/Mb/Gb split images in chunks of size N
> > # The maximum value should be
> > # (MAX_FILE_SIZE - 1Mb)
> > # 0 same as INT_MAX bytes
> > }
> > ***
> >
> > But the holdingdisk seems to be empty when Amanda tells me that some files may
> > have been left in the holdingsdisk and that I should run amflush to flush them to
> > tape.
>
> Your backup was going direct to tape (FAIL driver awe /home 20040828 0 [dump to tape
> failed]) so there was nothing in the holding disk to flush. The 'flush to
> tape' message is always output on a failed backup whether there is anythng to
> flush or not (it probably should check, but it doesn't).
>Perhaps your reserve parameter is set to not allow level 0s to holdingdisk.
>
> Frank
>
> >
> > \\Reidar
> >
> >
> >
> >
> >
>
>
>
>
>
Re: [out of tape] [dump to tape failed] ["data write: Broken pipe"]
--On Sunday, August 29, 2004 15:17:50 +0200 Reidar Nordin <[EMAIL PROTECTED]> wrote:
>
>> Your 'tape' is full. It doesn't necessarily mean the disk
>> is full, it could be that your backups exceed your tape length.
>> Look farther down in your report for the taper line and see if it
>> wrote as many bytes as you specified for the length in your tapetype.
>> If so, either increase your tape length (since you're really writing
>> to a file instead of to a tape) or increase runtapes to write to
>> multiple 'tapes'.
>
> I have increased the length in tapetype from 10GB to 20GB but still got the same
> error as desc. before
>
> The dumpsummary for just this server (awe) says:
> ***
>
>DUMPER STATSTAPER STATS
> HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
> awe /home 0 FAILED ---
> awe /httpd/conf 0 200 55 27.5 0:00 272.6 0:00 240.5
> awe -/local/adm 0 30 2 6.7 0:00 5.0 0:00 7.0
> awe -/lib/mysql 0 184160 22300 12.1 1:19 282.1 1:19 282.0
> ***
>
> From the end of my amanda log:
> ***
> INFO taper tape backup09 kb 2188064 fm 30 writing file: short write
Looks like it died around 2 GB.
> FAIL taper awe /home 20040828 0 [out of tape]
> ERROR taper no-tape [[writing file: short write]]
> FAIL driver awe /home 20040828 0 [dump to tape failed]
> FAIL dumper awe /home 20040828 0 ["data write: Broken pipe"]
> sendbackup: start [awe:/home level 0]
> sendbackup: info BACKUP=/bin/tar
> sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
> sendbackup: info COMPRESS_SUFFIX=.gz
> sendbackup: info end
> FINISH driver date 20040828 time 2188.326
> ***
>
>> I'm guessing you're not using a holding disk. While it's not as
>> necessary using the file driver, it would allow multiple dumps to
>> occur in parallel, which can shorten your backup window (using a
>> different disk is recommended to lessen I/O contention)
>
> I am using hdb1 for my backup's (mounted FAT32 disk)
I think this is your problem, I don't think FAT32 can't handle files
greater than 4 GB (twice what you are erroring out at, but much smaller
than your configured 'tape' size), but I think smbmount may have a 2 GB
limit.
Can you create a bigger file using dd ?
dd if=/dev/zero of=/mounted/fat32disk/testfile bs=1024 count=500
should create a 5 GB file in the path you specify with the of=, if it
bombs at 2 GB then look into how it is mounted (could be samba or kernel
problem). If you need files bigger than 4 GB on windows it needs to
be NTFS and not fat32.
> I am using hda2 as holding disk, this is my config in amanda.conf:
>
> ***
> holdingdisk hda2 {
> comment "main holding disk"
> directory "/usr/local/etc/amanda/holdingdisk" # where the holding disk is
> use -10 Mb # how much space can we use on it
> # a non-positive value means:
> #use all space but that value
> chunksize 10Gb # size of chunk if you want big dump to be
> # dumped on multiple files on holding disks
> # N Kb/Mb/Gb split images in chunks of size N
> # The maximum value should be
> # (MAX_FILE_SIZE - 1Mb)
> # 0 same as INT_MAX bytes
> }
> ***
>
> But the holdingdisk seems to be empty when Amanda tells me that some files may have
> been left in the holdingsdisk and that I should run amflush to flush them to tape.
Your backup was going direct to tape (FAIL driver awe /home 20040828 0 [dump to tape
failed]) so there was nothing in the holding disk to flush. The 'flush to
tape' message is always output on a failed backup whether there is anythng to
flush or not (it probably should check, but it doesn't).
Perhaps your reserve parameter is set to not allow level 0s to holdingdisk.
Frank
>
> \\Reidar
>
>
>
>
>
Re: [out of tape] [dump to tape failed] ["data write: Broken pipe"]
On Sun, Aug 29, 2004 at 03:17:50PM +0200, Reidar Nordin wrote:
>
> > Your 'tape' is full. It doesn't necessarily mean the disk
> > is full, it could be that your backups exceed your tape length.
> > Look farther down in your report for the taper line and see if it
> > wrote as many bytes as you specified for the length in your tapetype.
> > If so, either increase your tape length (since you're really writing
> > to a file instead of to a tape) or increase runtapes to write to
> > multiple 'tapes'.
>
> I have increased the length in tapetype from 10GB to 20GB but still got the same
> error as desc. before
>
> The dumpsummary for just this server (awe) says:
> ***
>
>DUMPER STATSTAPER STATS
> HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
> awe /home 0 FAILED ---
> awe /httpd/conf 0 200 55 27.5 0:00 272.6 0:00 240.5
> awe -/local/adm 0 30 2 6.7 0:00 5.0 0:00 7.0
> awe -/lib/mysql 0 184160 22300 12.1 1:19 282.1 1:19 282.0
> ***
>
> >From the end of my amanda log:
> ***
> INFO taper tape backup09 kb 2188064 fm 30 writing file: short write
> FAIL taper awe /home 20040828 0 [out of tape]
> ERROR taper no-tape [[writing file: short write]]
> FAIL driver awe /home 20040828 0 [dump to tape failed]
> FAIL dumper awe /home 20040828 0 ["data write: Broken pipe"]
> sendbackup: start [awe:/home level 0]
> sendbackup: info BACKUP=/bin/tar
> sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
> sendbackup: info COMPRESS_SUFFIX=.gz
> sendbackup: info end
> FINISH driver date 20040828 time 2188.326
> ***
>
> > I'm guessing you're not using a holding disk. While it's not as
> > necessary using the file driver, it would allow multiple dumps to
> > occur in parallel, which can shorten your backup window (using a
> > different disk is recommended to lessen I/O contention)
>
> I am using hdb1 for my backup's (mounted FAT32 disk)
> I am using hda2 as holding disk, this is my config in amanda.conf:
>
> ***
> holdingdisk hda2 {
> comment "main holding disk"
> directory "/usr/local/etc/amanda/holdingdisk" # where the holding disk is
> use -10 Mb # how much space can we use on it
> # a non-positive value means:
> #use all space but that value
> chunksize 10Gb # size of chunk if you want big dump to be
> # dumped on multiple files on holding disks
> # N Kb/Mb/Gb split images in chunks of size N
> # The maximum value should be
> # (MAX_FILE_SIZE - 1Mb)
> # 0 same as INT_MAX bytes
> }
> ***
>
> But the holdingdisk seems to be empty when Amanda tells me that some files may have
> been left in the holdingsdisk and that I should run amflush to flush them to tape.
>
> \\Reidar
>
I don't know the max file size on your FS's, but on some it is 2GB.
You could eliminate that as a possible problem on the holding disk
by specifying a "chunksize" as 1GB. I don't know about the FAT32
you are using for your virtual 20GB tapes. Is there a file size
limit on FAT32?
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: [out of tape] [dump to tape failed] ["data write: Broken pipe"]
> Your 'tape' is full. It doesn't necessarily mean the disk
> is full, it could be that your backups exceed your tape length.
> Look farther down in your report for the taper line and see if it
> wrote as many bytes as you specified for the length in your tapetype.
> If so, either increase your tape length (since you're really writing
> to a file instead of to a tape) or increase runtapes to write to
> multiple 'tapes'.
I have increased the length in tapetype from 10GB to 20GB but still got the same error
as desc. before
The dumpsummary for just this server (awe) says:
***
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
awe /home 0 FAILED ---
awe /httpd/conf 0 200 55 27.5 0:00 272.6 0:00 240.5
awe -/local/adm 0 30 2 6.7 0:00 5.0 0:00 7.0
awe -/lib/mysql 0 184160 22300 12.1 1:19 282.1 1:19 282.0
***
>From the end of my amanda log:
***
INFO taper tape backup09 kb 2188064 fm 30 writing file: short write
FAIL taper awe /home 20040828 0 [out of tape]
ERROR taper no-tape [[writing file: short write]]
FAIL driver awe /home 20040828 0 [dump to tape failed]
FAIL dumper awe /home 20040828 0 ["data write: Broken pipe"]
sendbackup: start [awe:/home level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
FINISH driver date 20040828 time 2188.326
***
> I'm guessing you're not using a holding disk. While it's not as
> necessary using the file driver, it would allow multiple dumps to
> occur in parallel, which can shorten your backup window (using a
> different disk is recommended to lessen I/O contention)
I am using hdb1 for my backup's (mounted FAT32 disk)
I am using hda2 as holding disk, this is my config in amanda.conf:
***
holdingdisk hda2 {
comment "main holding disk"
directory "/usr/local/etc/amanda/holdingdisk" # where the holding disk is
use -10 Mb # how much space can we use on it
# a non-positive value means:
#use all space but that value
chunksize 10Gb # size of chunk if you want big dump to be
# dumped on multiple files on holding disks
# N Kb/Mb/Gb split images in chunks of size N
# The maximum value should be
# (MAX_FILE_SIZE - 1Mb)
# 0 same as INT_MAX bytes
}
***
But the holdingdisk seems to be empty when Amanda tells me that some files may have
been left in the holdingsdisk and that I should run amflush to flush them to tape.
\\Reidar
Re: [out of tape] [dump to tape failed] ["data write: Broken pipe"]
--On Sunday, August 29, 2004 09:08:24 +0200 Reidar Nordin <[EMAIL PROTECTED]> wrote: > I am running amanda in a redhat based network. I am backing up to disk > instead of to tape because I had to many errors with the tapes. > When I first started to back up to tape it worked fine but after a while > i started getting error messages for just one server. > I am backing up 7 servers and they all work fine except for one of them, > the server that gives me the error is (awe), I get this error message > after every run (the disk is not full): > > These dumps were to tape backup09. > *** A TAPE ERROR OCCURRED: [[writing file: short write]]. > Some dumps may have been left in the holding disk. > Run amflush to flush them to tape. > The next tape Amanda expects to use is: backup010. > > FAILURE AND STRANGE DUMP SUMMARY: > awe/home lev 0 FAILED [out of tape] Your 'tape' is full. It doesn't necessarily mean the disk is full, it could be that your backups exceed your tape length. Look farther down in your report for the taper line and see if it wrote as many bytes as you specified for the length in your tapetype. If so, either increase your tape length (since you're really writing to a file instead of to a tape) or increase runtapes to write to multiple 'tapes'. > awe/home lev 0 FAILED [dump to tape failed] I'm guessing you're not using a holding disk. While it's not as necessary using the file driver, it would allow multiple dumps to occur in parallel, which can shorten your backup window (using a different disk is recommended to lessen I/O contention) Frank > awe/home lev 0 FAILED ["data write: Broken pipe"] > > > /-- awe/home lev 0 FAILED ["data write: Broken pipe"] > sendbackup: start [awe:/home level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... - > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > \ > > > Anyone got a clue > > > > \\Reidar > > > > > > >
[out of tape] [dump to tape failed] ["data write: Broken pipe"]
I am running amanda in a redhat based network. I am backing up to disk instead of to tape because I had to many errors with the tapes. When I first started to back up to tape it worked fine but after a while i started getting error messages for just one server. I am backing up 7 servers and they all work fine except for one of them, the server that gives me the error is (awe), I get this error message after every run (the disk is not full): These dumps were to tape backup09.*** A TAPE ERROR OCCURRED: [[writing file: short write]].Some dumps may have been left in the holding disk.Run amflush to flush them to tape.The next tape Amanda expects to use is: backup010.FAILURE AND STRANGE DUMP SUMMARY: awe /home lev 0 FAILED [out of tape] awe /home lev 0 FAILED [dump to tape failed] awe /home lev 0 FAILED ["data write: Broken pipe"] /-- awe /home lev 0 FAILED ["data write: Broken pipe"]sendbackup: start [awe:/home level 0]sendbackup: info BACKUP=/bin/tarsendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -sendbackup: info COMPRESS_SUFFIX=.gzsendbackup: info end\ Anyone got a clue \\Reidar
RE: sendbackup: index tee cannot write [Broken pipe], Why?
Wish I knew why it fixed it. In fact, when I added the holding-disk stuff to disklist, it wasn't because I was trying to fix the index tee problem, per se, it was simply because I noticed I had forgotten it. Then, subsequently noticed I had no more "broken tee" errors ... Regards, Michael Martinez ISTM/CSREES United States Department of Agriculture --- This email is signed with my digital signature so that you may verify the authenticity of the sender. --> -Original Message- --> From: Paul Bijnens [mailto:[EMAIL PROTECTED] --> Sent: Wednesday, November 05, 2003 10:19 AM --> To: Martinez, Michael --> Cc: [EMAIL PROTECTED] --> Subject: Re: sendbackup: index tee cannot write [Broken pipe], Why? --> --> --> Martinez, Michael wrote: --> --> > I had this problem and fixed it by specifying --> "holding-disk -1 local" in --> > disklist for the partition holding ~amanda on the tape server, and --> > specifying "-1 local" for the rest of the tape server partitions. --> > --> > --> John Grover wrote: --> > --> --> > --> > ? sendbackup: index tee cannot write [Broken pipe] --> > --> > ? index returned 1 --> > --> > sendbackup: error [/usr/bin/tar got signal 13] --> --> --> Clarifying -- I guess you had DLE's like: --> --> host.domain /amandaholding-disk -1 local --> host.domain / comp-user-tar -1 local --> host.domain /home comp-user-tar -1 local --> --> And with "comp-user-tar" instead of "holding-disk" on /amanda you --> would get the above error message. --> --> "Holding-disk" results in backup to tape immediatly, bypassing --> the holdingdisk. Any idea how that could influence the index tee? --> Did the ~amanda also contain the holdingdisk? If yes, then it's --> obvious you had to specify it, otherwise tar could create a huge --> (infinite) backup image. Eventually you would run out of --> holdingdisk --> space. --> --> Could it be triggered by the following sequence: --> Tar is reading some huge files, maybe compressing them too. This --> takes a long time; in the meanwhile the "index" tee times out --> in the server because the accompying index is only a few lines, and --> is still buffered in the client. But AFAIK there is no timeout --> on the index-tee, see dumper.c, line 1260 etc. --> Or there you should find some errors about "dup2", just --> before execlp --> the "gzip --best" for the index writer, or the gzip --best --> on the server crashed (how would you find out about this? there is --> no shell to log such a message). It could also be an output --> error in "gzip --best" because your disk got full. But then --> you should have found an message in the logs (or maybe not, because --> your disk was full :-) ). --> --> Just trying to understand -- maybe we found some obscure bug. --> --> --> -- --> Paul Bijnens, XplanationTel --> +32 16 397.511 --> Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax --> +32 16 397.512 --> http://www.xplanation.com/ email: --> [EMAIL PROTECTED] --> --> *** --> * I think I've got the hang of it now: exit, ^D, ^C, ^\, --> ^Z, ^Q, F6, * --> * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, --> bye, /bye, * --> * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, --> abort, hangup, * --> * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, --> shutdown, * --> * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, --> Stop-A, ...* --> * ... "Are you sure?" ... YES ... Phew ... I'm --> out * --> --> *** --> --> --> smime.p7s Description: S/MIME cryptographic signature
Re: sendbackup: index tee cannot write [Broken pipe], Why?
Martinez, Michael wrote: I had this problem and fixed it by specifying "holding-disk -1 local" in disklist for the partition holding ~amanda on the tape server, and specifying "-1 local" for the rest of the tape server partitions. > --> John Grover wrote: --> --> > ? sendbackup: index tee cannot write [Broken pipe] --> > ? index returned 1 --> > sendbackup: error [/usr/bin/tar got signal 13] Clarifying -- I guess you had DLE's like: host.domain /amandaholding-disk -1 local host.domain / comp-user-tar -1 local host.domain /home comp-user-tar -1 local And with "comp-user-tar" instead of "holding-disk" on /amanda you would get the above error message. "Holding-disk" results in backup to tape immediatly, bypassing the holdingdisk. Any idea how that could influence the index tee? Did the ~amanda also contain the holdingdisk? If yes, then it's obvious you had to specify it, otherwise tar could create a huge (infinite) backup image. Eventually you would run out of holdingdisk space. Could it be triggered by the following sequence: Tar is reading some huge files, maybe compressing them too. This takes a long time; in the meanwhile the "index" tee times out in the server because the accompying index is only a few lines, and is still buffered in the client. But AFAIK there is no timeout on the index-tee, see dumper.c, line 1260 etc. Or there you should find some errors about "dup2", just before execlp the "gzip --best" for the index writer, or the gzip --best on the server crashed (how would you find out about this? there is no shell to log such a message). It could also be an output error in "gzip --best" because your disk got full. But then you should have found an message in the logs (or maybe not, because your disk was full :-) ). Just trying to understand -- maybe we found some obscure bug. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
RE: sendbackup: index tee cannot write [Broken pipe], Why?
I had this problem and fixed it by specifying "holding-disk -1 local" in disklist for the partition holding ~amanda on the tape server, and specifying "-1 local" for the rest of the tape server partitions. Regards, Michael Martinez ISTM/CSREES United States Department of Agriculture --- This email is signed with my digital signature so that you may verify the authenticity of the sender. --> -Original Message- --> From: Paul Bijnens [mailto:[EMAIL PROTECTED] --> Sent: Monday, November 03, 2003 11:17 AM --> To: John Grover --> Cc: [EMAIL PROTECTED] --> Subject: Re: sendbackup: index tee cannot write [Broken pipe], Why? --> --> --> John Grover wrote: --> --> > I'm guessing that the timeout is caused by the failure of --> tar to write --> > to the broken pipe, but the logs don't give me much to go on. I've --> > scoured every lat resource I can find and still get these --> results. I'd --> > be happy to send logs to anyone who would care to help me out with --> > this. --> --> --> > ? sendbackup: index tee cannot write [Broken pipe] --> > ? index returned 1 --> > sendbackup: error [/usr/bin/tar got signal 13] --> --> This problem is signalled now and then on this list. People --> give lots of --> tips to help/investigate/fix, but nobody ever came back and --> told what --> he/she did to solve it. If it ever got solved at all. --> --> It seems it is the index-pipe on the server that is failing with --> an (unknown) error. This triggers a broken index pipe on --> the client. --> We're not sure about that either. That's why I suggested to --> (temporarily) run without index for this DLE, and see if it gets any --> better. --> --> If this works fine, they you could try to create the index manually, --> and see what's wrong, using commands on the server: --> amrestore -p ... | gtar -tf - > /tmp/the_index --> Then with "gtar" running on the client: --> ssh -l amanda amanda_server amrestore -p ... | gtar -tf --> - > /tmp/x --> --> If you gzip the resulting index file and put in the correct --> place, with --> the correct name, you have an index for amrecover too. --> --> --> Also verify the gnutar version (on the client!); best is 1.13.25 --> (1.13.19 is probably ok too, but if you have it, I advice --> to upgrade --> anyway). All other versions are suspicious. --> Maybe the problem is with gzip (index files are ALWAYS compressed --> --best). Verify that version too. --> --> --> -- --> Paul Bijnens, XplanationTel --> +32 16 397.511 --> Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax --> +32 16 397.512 --> http://www.xplanation.com/ email: --> [EMAIL PROTECTED] --> --> *** --> * I think I've got the hang of it now: exit, ^D, ^C, ^\, --> ^Z, ^Q, F6, * --> * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, --> bye, /bye, * --> * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, --> abort, hangup, * --> * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, --> shutdown, * --> * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, --> Stop-A, ...* --> * ... "Are you sure?" ... YES ... Phew ... I'm --> out * --> --> *** --> --> --> smime.p7s Description: S/MIME cryptographic signature
Re: sendbackup: index tee cannot write [Broken pipe], Why?
John Grover wrote: I'm guessing that the timeout is caused by the failure of tar to write to the broken pipe, but the logs don't give me much to go on. I've scoured every lat resource I can find and still get these results. I'd be happy to send logs to anyone who would care to help me out with this. ? sendbackup: index tee cannot write [Broken pipe] ? index returned 1 sendbackup: error [/usr/bin/tar got signal 13] This problem is signalled now and then on this list. People give lots of tips to help/investigate/fix, but nobody ever came back and told what he/she did to solve it. If it ever got solved at all. It seems it is the index-pipe on the server that is failing with an (unknown) error. This triggers a broken index pipe on the client. We're not sure about that either. That's why I suggested to (temporarily) run without index for this DLE, and see if it gets any better. If this works fine, they you could try to create the index manually, and see what's wrong, using commands on the server: amrestore -p ... | gtar -tf - > /tmp/the_index Then with "gtar" running on the client: ssh -l amanda amanda_server amrestore -p ... | gtar -tf - > /tmp/x If you gzip the resulting index file and put in the correct place, with the correct name, you have an index for amrecover too. Also verify the gnutar version (on the client!); best is 1.13.25 (1.13.19 is probably ok too, but if you have it, I advice to upgrade anyway). All other versions are suspicious. Maybe the problem is with gzip (index files are ALWAYS compressed --best). Verify that version too. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
sendbackup: index tee cannot write [Broken pipe], Why?
Amanda Users List:
I've been getting the following error consistently on this client/disk
despite my best efforts to solve it. I've changed the timeout values on
the server, removed extra files from the file system and double checked
permissions and port numbers. The /var filesystem on this same client
backs up fine using the same configuration.
I'm guessing that the timeout is caused by the failure of tar to write
to the broken pipe, but the logs don't give me much to go on. I've
scoured every lat resource I can find and still get these results. I'd
be happy to send logs to anyone who would care to help me out with
this.
Thanks,
John Grover
/-- MyClient.my.d / lev 0 FAILED [data timeout]
sendbackup: start [MyClient.my.domain.name.here:/ level 0]
sendbackup: info BACKUP=/usr/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/tar -f... -
sendbackup: info end
? sendbackup: index tee cannot write [Broken pipe]
? index returned 1
sendbackup: error [/usr/bin/tar got signal 13]
\
Log excerpt:
...
WARNING planner Last full dump of MyClient.my.domain.name.here:/ on
tape overwritten in 1 run.
...
FAIL dumper MyClient.my.domain.name.here / 20031101 0 [data timeout]
sendbackup: start [MyClient.my.domain.name.here:/ level 0]
sendbackup: info BACKUP=/usr/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/tar -f... -
sendbackup: info end
? gtar: Cannot add file
./usr/local/blackboard/docs/lib/session/41394: No such file or
directory
? sendbackup: index tee cannot write [Broken pipe]
? index returned 1
sendbackup: error [/usr/bin/tar got signal 13]
SUCCESS dumper MyClient.my.domain.name.here /var 20031101 1 [sec 14.720
kb 2500 kps 169.8 orig-kb 2500]
SUCCESS taper MyClient.my.domain.name.here /var 20031101 1 [sec 2.310
kb 2500 kps 1081.8 {wr: writers 80 rdwait 0.000 wrwait 0.199 filemark
2.107}]
...
Re: backup over slow internet line, Broken pipe?
Palle Girgensohn wrote: I get Broken pipe all the time when backing up using tar. The backup client is at a different site, so backup is performed over a 2 Mbit/s line. While the 2Mb line is not top quality, using netstat -i 1 reveals that after a number of hours, almost no backup data is sent at all. Finally, it gives up with a "broken pipe" error. Looks to me that the tar program fails? Any ideas how get this working better? Can I force TCP connections instead of UDP? Anything else I've missed? It is already using TCP. The UDP packet is only sent from server to client to initiate the backup and the client replies with a UDP packet with in it 2 or 3 TCP ports where the server should connect to: one for the backup, one the error channel and if needed one for the indexes. sendbackup: time 0.088: spawning /usr/local/libexec/amanda/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory /usr/local/www/server --one-file-system --listed-inc remental /usr/local/var/amanda/gnutar-lists/myclient.mydomain_usr_local_www_server_0 .new --sparse --ignore-failed -read --totals --files-from /tmp/amanda/sendbackup._usr_local_www_server.20031023035208.include sendbackup-gnutar: time 0.090: /usr/local/libexec/amanda/runtar: pid 11408 sendbackup: time 0.094: started index creator: "/usr/local/bin/gtar -tf - 2>/dev/null | sed -e 's/^\.//'" sendbackup: time 45609.758: index tee cannot write [Broken pipe] After 45609 seconds (>12 hours), the index stream got broken. log, serverside: STRANGE dumper myclient.mydomain /usr/local/www/server 0 [sec 42722.653 kb 4990910 kps 116.8 orig-kb 4990910] but 2887 seconds earlier the backup was finished. Why is the index-stream still open? There were similar messages on this list about a broken index-tee but nobody ever mentioned a solution. If it is really the index only, maybe try it without indexing, to see how this behaves? If this works, we have a better idea where to look. Also don't forget firewall settings... (something times out after maybe an hour or so?) -- Paul @ Home
backup over slow internet line, Broken pipe?
Hi!
I get Broken pipe all the time when backing up using tar. The backup client
is at a different site, so backup is performed over a 2 Mbit/s line. While
the 2Mb line is not top quality, using netstat -i 1 reveals that after a
number of hours, almost no backup data is sent at all. Finally, it gives up
with a "broken pipe" error. Looks to me that the tar program fails? Any
ideas how get this working better? Can I force TCP connections instead of
UDP? Anything else I've missed?
Thanks,
Palle
I use freebsd 4.8p3, amanda 2.4.4.
netusage 400 kbps # maximum net bandwidth for Amanda, in KB per sec
dumpcycle 21 days # the number of days in the normal dump cycle
runspercycle 12 # number of amdump runs in dumpcycle days
tapecycle 18 tapes # the number of tapes in rotation
bumpsize 20 Mb # minimum savings (threshold) to bump level 1 -> 2
bumpdays 2 # minimum days at each level
bumpmult 1.5# threshold = bumpsize * (level-1)**bumpmult
reserve 10 # reserve N % of holding disk for non-level-0 dumps
# Remember to switch between the 2 tape device
tapedev "/dev/nrsa1"# The no-rewind tape device to be uesd DLT
tapetype Adic # DLT
...
define interface iponly {
comment "iponly in the bergrum"
use 2 mbps
}
and the disklist:
...
myclient.mydomain / inferior -1 iponly
myclient.mydomain /usr/local/www/server tar_normal -1 iponly
...
All other backups run smooth, as well as the dump of the root disk.
log, on the client:
sendbackup: debug 1 pid 11405 ruid 10 euid 10: start at Thu Oct 23 03:52:08
2003
/usr/local/libexec/amanda/sendbackup: version 2.4.4
parsed request as: program `GNUTAR'
disk `/usr/local/www/server'
device `/usr/local/www/server'
level 0
since 1970:1:1:0:0:0
options
`|;auth=bsd;index;include-list=.amanda.includes;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.4531
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.4532
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.4533
sendbackup: time 0.000: waiting for connect on 4531, then 4532, then 4533
sendbackup: time 0.013: stream_accept: connection from 195.178.168.86.1382
sendbackup: time 0.020: stream_accept: connection from 195.178.168.86.1383
sendbackup: time 0.034: stream_accept: connection from 195.178.168.86.1384
sendbackup: time 0.034: got all connections
sendbackup-gnutar: time 0.048: doing level 0 dump as listed-incremental to
/usr/local/var/amanda/gnutar-lists/myclient.mydomain_usr_local_www_server_0
.new
sendbackup-gnutar: time 0.065: doing level 0 dump from date: 1970-01-01
0:00:00 GMT
sendbackup: time 0.088: spawning /usr/local/libexec/amanda/runtar in
pipeline
sendbackup: argument list: gtar --create --file - --directory
/usr/local/www/server --one-file-system --listed-inc
remental
/usr/local/var/amanda/gnutar-lists/myclient.mydomain_usr_local_www_server_0
.new --sparse --ignore-failed
-read --totals --files-from
/tmp/amanda/sendbackup._usr_local_www_server.20031023035208.include
sendbackup-gnutar: time 0.090: /usr/local/libexec/amanda/runtar: pid 11408
sendbackup: time 0.094: started index creator: "/usr/local/bin/gtar -tf -
2>/dev/null | sed -e 's/^\.//'"
sendbackup: time 45609.758: index tee cannot write [Broken pipe]
sendbackup: time 45609.758: pid 11407 finish time Thu Oct 23 16:32:18 2003
sendbackup: time 45609.761: 124: strange(?): sendbackup: index tee cannot
write [Broken pipe]
sendbackup: time 45609.763: error [/usr/local/bin/gtar got signal 13]
sendbackup: time 45609.763: pid 11405 finish time Thu Oct 23 16:32:18 2003
log, serverside:
STRANGE dumper myclient.mydomain /usr/local/www/server 0 [sec 42722.653 kb
4990910 kps 116.8 orig-kb 4990910]
sendbackup: start [myclient.mydomain:/usr/local/www/server level 0]
sendbackup: info BACKUP=/usr/local/bin/gtar
sendbackup: info RECOVER_CMD=/usr/local/bin/gtar -f... -
sendbackup: info end
? gtar: ./libfiles/58992: Warning: Cannot stat: (null)
? gtar: ./libfiles/58993: Warning: Cannot stat: (null)
| Total bytes written: 5110691840 (4.8GB, 117kB/s)
sendbackup: size 4990910
sendbackup: end
Broken pipe error
I'm getting the following error from one of my client machines: /-- wiley.my.d / lev 0 FAILED [data timeout] sendbackup: start [wiley.my.domain:/ level 0] sendbackup: info BACKUP=/usr/bin/tar sendbackup: info RECOVER_CMD=/usr/bin/tar -f... - sendbackup: info end ? sendbackup: index tee cannot write [Broken pipe] ? index returned 1 sendbackup: error [/usr/bin/tar got signal 13] \ Another machine is configured identically but has no problem... Any ideas? Thanks John Grover John W Grover, Systems and Database Administrator Lake Michigan College www.lakemichigancollege.edu
Broken pipe
Hi, all of our machines are being backup except one machine. This server (RH 8) have 3 partitions (/, /home, /var). I can backup the root partition without problems, but the other two are saying this (in the /tmp/amanda/ logs): sendbackup: started index creator: "/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'" index tee cannot write [Broken pipe] sendbackup: pid 28683 finish time Thu Sep 18 00:18:14 2003 error [/bin/tar got signal 13, compress returned 1] Any ideas ?
ANSWER: FATAL syncpipe_put: Broken pipe
Kurt Yoder said: > What does "taper: FATAL syncpipe_put: Broken pipe" mean? I've tried > twice to flush a 26 GB dump image to tape, and got this message both > times. It was a hardware problem. Something about the motherboard and Linux didn't get along. Switching to previous motherboard seems to have fixed it. -- Kurt Yoder Sport & Health network administrator
Re: FATAL syncpipe_put: Broken pipe
On Thu, Sep 11, 2003 at 12:09:24PM -0400, Kurt Yoder wrote: > So what would be > wrong with the dump image? Should I try manually uncompressing that > image and seeing what's on it? I doubt you'd learn anything. As far as taper is concerned, I believe the image is just an opaque stream of bytes. If there's something in the image's content that's killing taper -- and that seems pretty farfetched! -- it'll be in the compressed byte stream as it is in the holding disk. A problem in the uncompressed image would affect the lower-level restore tool (restore, gtar, etc.), but as far as Amanda itself is concerned, the only effect I can imagine would be on index generation, since that depends on the lower-level restorer. But indexing shouldn't come into play during amflush. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot
Re: FATAL syncpipe_put: Broken pipe
Paul Bijnens said: > Kurt Yoder wrote: > >> My amdump log file is quite long, so here's the part that seems >> most >> relevant: > > ... > > It seems it is the taper writer that is somehow crashing, without > telling anybody. Do you find a core file in the amanda home dir > or in /tmp/amanda ? Nope [EMAIL PROTECTED]:/tmp/amanda# find / -name core /dev/core /proc/sys/net/core /old/dev/core > Just a wild guess: is the tapecapacity < 26Gbyte? You're still > running > version 2.4.2p2 and I remember somewhere someone changed something > so that a file that fails twice while taping, is not a candidate > anymore > (avoiding that one file is tried on each tape and trashes all tapes > in the loader). Tape and drive capacity is 40 GB uncompressed. So what would be wrong with the dump image? Should I try manually uncompressing that image and seeing what's on it? > If you're brave, upgrade to 2.4.4p1 (or the latest 2.4.4 snapshot > from > http://www.iro.umontreal.ca/~martinea/amanda ) and if the problem > persists, recompile amanda with TAPER_DEBUG=1. I'd like to avoid that if at all possible... -- Kurt Yoder Sport & Health network administrator
Re: FATAL syncpipe_put: Broken pipe
Paul Bijnens said: > Kurt Yoder wrote: > >> What does "taper: FATAL syncpipe_put: Broken pipe" mean? I've >> tried >> twice to flush a 26 GB dump image to tape, and got this message >> both >> times. > > Any other messages in the file "amdump.*" and the LOG.datestamp.lvl. > file? > There are two tapers, a reader and a writer. Maybe there are some > error messages from one of those. My amdump log file is quite long, so here's the part that seems most relevant: driver: finished-cmd time 9464.088 dumper0 dumped borneo.shcorp.com:/home/groups/graphics_photos driver: send-cmd time 9464.088 to taper: FILE-WRITE 00-00026 /backups/amandadisk/holding/20030911/borneo.shcorp.com._home_groups_graphics__photos.0 borneo.shcorp.com /home/groups/graphics_photos 0 20030911 driver: state time 9464.088 free kps: 36000 space: 55661264 taper: writing idle-dumpers: 4 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 86400 driver-idle: not-idle driver: interface-state time 9464.088 if : free 36000 driver: hdisk-state time 9464.088 hdisk 0: free 55661264 dumpers 0 syncpipe_put: Broken pipe taper: pid 6574 finish time Thu Sep 11 03:31:12 2003 driver: result time 10870.550 from taper: dump of driver schedule before start degraded mode: Then here's my amflush log file: driver: send-cmd time 0.000 to taper: START-TAPER 20030911 taper: pid 7964 executable taper version 2.4.2p2 changer: opening pipe to: /usr/lib/amanda/chg-multi -info changer: got exit: 0 str: 1 1 1 changer_query: changer return was 1 1 changer_query: searchable = 0 changer_find: looking for CDS1tape07 changer is searchable = 0 changer: opening pipe to: /usr/lib/amanda/chg-multi -slot current changer: got exit: 0 str: 1 /dev/nst0 taper: slot 1: date 20030811 label CDS1tape07 (exact label match) taper: read label `CDS1tape07' date `20030811' taper: wrote label `CDS1tape07' date `20030911' driver: send-cmd time 11.544 to taper: FILE-WRITE 00-1 /backups/amandadisk/holding/20030911/borneo.shcorp.com._home_groups_graphics__photos.0 borneo.shcorp.com /home/groups/graphics_photos 0 20030911 syncpipe_put: Broken pipe taper: pid 7965 finish time Thu Sep 11 09:18:40 2003 driver: send-cmd time 44.205 to taper: QUIT writing taper command: Broken pipe and here's my log.20030911.1: START amflush date 20030911 START taper datestamp 20030911 label CDS1tape07 tape 0 FATAL taper syncpipe_put: Broken pipe WARNING amflush /backups/amandadisk/holding/20030911/borneo.shcorp.com._home_groups_graphics__photos.0: taper error, leaving file on disk WARNING amflush Could not rmdir /backups/amandadisk/holding/20030911. Check for cruft. FINISH amflush date 20030911 time 44.205 -- Kurt Yoder Sport & Health network administrator
FATAL syncpipe_put: Broken pipe
What does "taper: FATAL syncpipe_put: Broken pipe" mean? I've tried twice to flush a 26 GB dump image to tape, and got this message both times. -- Kurt Yoder Sport & Health network administrator
AMANDA and sencrypt/sst -> dump: Broken pipe
Hello, I am using an AMANDA 2.4.3 server patched with the sencrypt script from http://cns.utoronto.ca/~pkern/stuff/amanda-patch/ and also using sst to do the encryption from the same author. I am using exactly the same configuration on both the server and the client. The problem is that somehow dump returns Broken pipe with I turn sencrypt to on, if I don't use sencrypt it works pefectly. Here is the output of the sendbackup logfile on the client: sendbackup: debug 1 pid 21255 ruid 104 euid 104: start at Sun Feb 9 19:44:14 2003 /opt/amanda/libexec/sendbackup: version 2.4.3 parsed request as: program `DUMP' disk `/' device `/' level 1 since 2003:2:8:23:14:6 options `|;auth=bsd;sencrypt;compress-best;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.44864 sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.44865 sendbackup: time 0.001: waiting for connect on 44864, then 44865 sendbackup: time 0.039: stream_accept: connection from X.X.X.X.57784 sendbackup: time 0.059: stream_accept: connection from X.X.X.X.51050 sendbackup: time 0.060: got all connections sendbackup: time 0.060: spawning /local/bin/sst in pipeline sendbackup: argument list: /local/bin/sst -celv sendbackup: time 0.061: spawning /bin/gzip in pipeline sendbackup: argument list: /bin/gzip --best sendbackup-dump: time 0.061: pid 21258: /bin/gzip --best sendbackup: time 0.063: dumping device '/dev/hda2' with 'ext3' sendbackup: time 0.064: spawning /sbin/dump in pipeline sendbackup: argument list: dump 1usf 1048576 - /dev/hda2 sendbackup: time 0.904: 91: normal(|): DUMP: Date of this level 1 dump: Sun Feb 9 19:44:14 2003 sendbackup: time 0.907: 91: normal(|): DUMP: Date of last level 0 dump: Sat Feb 8 23:27:22 2003 sendbackup: time 0.909: 91: normal(|): DUMP: Dumping /dev/hda2 (/) to standard output sendbackup: time 0.911: 91: normal(|): DUMP: Exclude ext3 journal inode 8 sendbackup: time 1.112: 91: normal(|): DUMP: Label: / sendbackup: time 1.115: 91: normal(|): DUMP: mapping (Pass I) [regular files] sendbackup: time 3.663: 91: normal(|): DUMP: mapping (Pass II) [directories] sendbackup: time 4.818: 91: normal(|): DUMP: estimated 139205 tape blocks. sendbackup: time 4.821: 91: normal(|): DUMP: Volume 1 started with block 1 at: Sun Feb 9 19:44:19 2003 sendbackup: time 4.864: 91: normal(|): DUMP: dumping (Pass III) [directories] sendbackup: time 5.756: 91: normal(|): DUMP: Broken pipe sendbackup: time 5.758: 91: normal(|): DUMP: The ENTIRE dump is aborted. sendbackup: time 6.059: error [compress got signal 13, sencrypt returned 33, /sbin/dump returned 3] sendbackup: time 6.059: pid 21255 finish time Sun Feb 9 19:44:20 2003 Does anyone know what could be wrong ? If you need more details or other log files let me know, I would be pleased to provide them... Thanks for the help ! Regards
Error 32 (Broken pipe)
I'm trying to restore a backup of a client from tape. I'd like to first read archive file off tape onto amanda server, then move the file onto the amanda client and run it through restore. I typed: amrestore /dev/nst1 samba /dev/hdc1 after a few minutes of restoring I get: Error 32 (Broken pipe) offset 859930624+32768, wrote 0 amrestore: pipe reader has quit in middle of file amrestore: skipping ahead to start of next file, please wait... Can someone please help ? Regards, Ben
index tee cannot write [Broken pipe]
Hi, I am using amanda version 2.4.2p2. I am getting error in /tmp/amanda/sendbackup.20020226160838.debug . The content of sendbackup.20020226160838.debug is the following. sendbackup-gnutar: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: spawning /usr/local/libexec/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory /contents --one-file-system --list ed-incremental /usr/local/var/amanda/gnutar-lists/aspone_contents_0.new --sparse --ignore-f ailed -read --totals . sendbackup-gnutar: /usr/local/libexec/runtar: pid 28450 sendbackup: started index creator: "/bin/gtar -tf - 2>/dev/null | sed -e 's/^\.//'" index tee cannot write [Broken pipe] sendbackup: pid 28448 finish time Tue Feb 26 17:49:17 2002 Backup is fail. I can not understand this error. Please help me. Best regards, Masafumi Hikawa
Broken Pipe errors
I recently added a new machine to my backups, and seem to be having a problem with a couple of file systems with "index tee cannot write [Broken pipe]" errors. Client is Solaris 7 Server is Solaris 7 amanda version 2.4.2p2 gnutar 1.13.19 firewall between the two servers, but no security restrictions (as in all other backups work fine). Server is NAT'ed at firewall I've run some tests just backing one of those filesystems up, and no matter how I fiddle with the dumptype (thinking compression in particular might be part of the problem) I cannot get this error to go away. In test mode I'm trying to dump only to holding disk which has 11.5 GB free. The file system in question is only ~1.5 GBs. Larger filesystems on the same host can be backed up with the same dumptype parameters with no problems. When I was watching the backup being performed with "amstatus" it showed data being transferred, and the correct file was being created and updated on the server. I think when it stopped updating, the size sent reported by amstatus was a few KB (32?) over the estimated backup size (didnt write the data down like a fool) - I realize this may or may not mean a thing, but just throwing it out there. Here are some (hopefully!) appropriate log files (they dont tell me too much): = log.20020225.0 from server = START planner date 20020225 START driver date 20020225 ERROR taper no-tape [no tape online] FINISH planner date 20020225 STATS driver startup time 2.472 FAIL dumper rnbuyer /export/home 0 [mesg read: Connection timed out] sendbackup: start [rnbuyer:/export/home level 0] sendbackup: info BACKUP=/usr/local/bin/tar sendbackup: info RECOVER_CMD=/usr/local/bin/tar -f... - sendbackup: info end FINISH driver date 20020225 time 7744.120 = amdump.1 from server = amdump: start at Mon Feb 25 10:38:00 EST 2002 planner: pid 5123 executable /usr/local/libexec/planner version 2.4.2p2 planner: build: VERSION="Amanda-2.4.2p2" planner:BUILT_DATE="Mon Jul 30 12:22:45 EDT 2001" planner:BUILT_MACH="SunOS utl-atl-05 5.7 Generic_106541-15 sun4u sparc SUNW,Ultra-4" planner:CC="gcc" planner: paths: bindir="/usr/local/bin" sbindir="/usr/local/sbin" planner:libexecdir="/usr/local/libexec" mandir="/usr/local/man" planner:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" planner:CONFIG_DIR="/usr/local/etc/amanda" DEV_PREFIX="/dev/dsk/" planner:RDEV_PREFIX="/dev/rdsk/" DUMP="/usr/sbin/ufsdump" planner:RESTORE="/usr/sbin/ufsrestore" planner:SAMBA_CLIENT="/usr/local/samba/bin/smbclient" planner:GNUTAR="/usr/local/bin/tar" planner:COMPRESS_PATH="/usr/local/bin/gzip" planner:UNCOMPRESS_PATH="/usr/local/bin/gzip" planner:MAILER="/usr/bin/mailx" planner:listed_incr_dir="/usr/local/var/amanda/gnutar-lists" planner: defs: DEFAULT_SERVER="utl-atl-06" DEFAULT_CONFIG="DailySet1" planner:DEFAULT_TAPE_SERVER="utl-atl-06" planner:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM planner:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE planner:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS planner:CLIENT_LOGIN="siteops" FORCE_USERID HAVE_GZIP planner:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" planner:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" planner: dgram_bind: socket bound to 0.0.0.0.603 READING CONF FILES... startup took 0.010 secs SETTING UP FOR ESTIMATES... setting up estimates for rnbuyer:/export/home rnbuyer:/export/home overdue 11744 days for level 0 setup_estimate: rnbuyer:/export/home: command 4, options: last_level -1 next_level0 -11744 level_days 0 getting estimates 0 (0) -1 (-1) -1 (-1) setting up estimates took 0.000 secs GETTING ESTIMATES... driver: pid 5122 executable /usr/local/libexec/driver version 2.4.2p2 driver: send-cmd time 0.005 to taper: START-TAPER 20020225 taper: pid 5124 executable taper version 2.4.2p2 driver: started dumper0 pid 5126 dumper: dgram_bind: socket bound to 0.0.0.0.606 dumper: pid 5126 executable dumper version 2.4.2p2, using port 606 dumper: dgram_bind: socket bound to 0.0.0.0.607 dumper: pid 5127 executable dumper version 2.4.2p2, using port 607 driver: started dumper1 pid 5127 driver: started dumper2 pid 5128 driver: started dumper3 pid 5129 driver: started dumper4 pid 5130 driver: started dumper5 pid 5131 dumper: dgram_bind: socket bound to 0.0.0.0.608 dumper: pid 5128 executable dumper version 2.4.2p2, using port 608 dumper: dgram_bind: socket bound to 0.0.0.0.610 dumper: pid 5130 exec
RE: broken pipe?!
> -Original Message-
> From: John R. Jackson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 3:30 PM
> To: Chris Noon
> Cc: [EMAIL PROTECTED]
> Subject: Re: broken pipe?!
>
>
> >... Unfortunately, another dump ran on
> >that client since this error, so sendbackup.debug doesn't refer to this
> >dump.
>
> Sigh. FYI, if you upgrade that client to 2.4.2p2 (you would not have
> to do everything), the debug files will be kept separate. Or you could
> rebuild that client using --with-pid-debug-files, but that will require
> you also remember to clean up /tmp/amanda on occasion.
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
I've gotten this error again, and this time I've got the sendbackup.debug
file from the client. I don't see any glaring problems with it, but here it
is...
**
sendbackup: debug 1 pid 10379 ruid 5095 euid 5095 start time Wed Sep 19
11:29:38 2001
/usr/local/amanda-2.4.2/libexec/sendbackup: got input request: DUMP c1t4d0s7
0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;srvcomp-fast;
index;
parsed request as: program `DUMP' disk `c1t4d0s7' lev 0 since
1970:1:1:0:0:0 opt `|;bsd-auth;srvcomp-fast;index;'
waiting for connect on 57695, then 57696, then 57697
got all connections
sendbackup: started index creator: "/usr/sbin/ufsrestore -tvf - 2>&1 |
sed -e '
s/^leaf[]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: spawning "/usr/sbin/ufsdump" in pipeline
sendbackup: argument list: "dump" "0usf" "1048576" "-" "/dev/rdsk/c1t4d0s7"
sendbackup: index pipe returned 36096
sendbackup: pid 10379 finish time Wed Sep 19 14:05:46 2001
**
Thanks in advance again.
--Chris
Re: broken pipe?!
>... Unfortunately, another dump ran on >that client since this error, so sendbackup.debug doesn't refer to this >dump. Sigh. FYI, if you upgrade that client to 2.4.2p2 (you would not have to do everything), the debug files will be kept separate. Or you could rebuild that client using --with-pid-debug-files, but that will require you also remember to clean up /tmp/amanda on occasion. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: broken pipe?!
Yes it's solaris, using amanda-2.4.1p1. Unfortunately, another dump ran on that client since this error, so sendbackup.debug doesn't refer to this dump. -Original Message- From: John R. Jackson [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 1:22 PM To: Chris Noon Cc: [EMAIL PROTECTED] Subject: Re: broken pipe?! >I keep getting the following error whenever I run a Level 0 on this one >disk. ... >| DUMP: DUMP IS DONE >| DUMP: Level 0 dump on Wed Sep 12 09:37:15 2001 >? Broken Pipe I take it the client is Solaris? What version of Amanda? What's in /tmp/amanda/sendbackup*debug on the client? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: broken pipe?!
>I keep getting the following error whenever I run a Level 0 on this one >disk. ... >| DUMP: DUMP IS DONE >| DUMP: Level 0 dump on Wed Sep 12 09:37:15 2001 >? Broken Pipe I take it the client is Solaris? What version of Amanda? What's in /tmp/amanda/sendbackup*debug on the client? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
broken pipe?!
I keep getting the following error whenever I run a Level 0 on this one disk. Everything seems to be fine with the dump, as I am able to successfully restore from it. But this error is driving me mad, and I am getting nowhere on my own. Any ideas? * FAILED AND STRANGE DUMP DETAILS: /-- kabru c1t4d0s7 lev 0 STRANGE sendbackup: start [kabru:c1t4d0s7 level 0] sendbackup: info BACKUP=/usr/sbin/ufsdump sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... - sendbackup: info end | DUMP: Writing 32 Kilobyte records | DUMP: Date of this level 0 dump: Wed Sep 12 09:37:15 2001 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/rdsk/c1t4d0s7 (kabru.domain.com:/usr2) to standard output. | DUMP: Mapping (Pass I) [regular files] | DUMP: Mapping (Pass II) [directories] | DUMP: Estimated 10822366 blocks (5284.36MB) on 0.08 tapes. | DUMP: Dumping (Pass III) [directories] | DUMP: Dumping (Pass IV) [regular files] | DUMP: 7.68% done, finished in 2:00 | DUMP: 14.26% done, finished in 2:00 | DUMP: 21.50% done, finished in 1:49 | DUMP: 27.63% done, finished in 1:45 | DUMP: 34.33% done, finished in 1:36 | DUMP: 41.03% done, finished in 1:26 | DUMP: 47.23% done, finished in 1:18 | DUMP: 53.78% done, finished in 1:09 | DUMP: 60.59% done, finished in 0:58 | DUMP: 66.98% done, finished in 0:49 | DUMP: 73.76% done, finished in 0:39 | DUMP: 80.72% done, finished in 0:28 | DUMP: 87.16% done, finished in 0:19 | DUMP: 93.48% done, finished in 0:09 | DUMP: 10816190 blocks (5281.34MB) on 1 volume at 598 KB/sec | DUMP: DUMP IS DONE | DUMP: Level 0 dump on Wed Sep 12 09:37:15 2001 ? Broken Pipe sendbackup: size 5408095 sendbackup: end \
Re: amanda client broken pipe
>I'm getting a weird error on one of my amanda clients (2.4.1p1 on >freebsd 4.2 using gnu tar v 1.13) ... I hope you don't really mean "1.13" for tar. If it's not 1.13.19 or later (from alpha.gnu.org), you're not getting good index files. >? sendbackup: index tee cannot write [Broken pipe] This is usually just a symptom of doing a direct to tape backup (i.e. bypassing the holding disk) and banging into end of tape. See if that matches up with the rest of the E-mail report you got. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
amanda client broken pipe
Hello I'm getting a weird error on one of my amanda clients (2.4.1p1 on freebsd 4.2 using gnu tar v 1.13) that I'm having trouble understanding: FAILED AND STRANGE DUMP DETAILS: /-- galadriel. /usr lev 0 FAILED [data timeout] sendbackup: start [galadriel.shcorp.com:/usr level 0] sendbackup: info BACKUP=/usr/bin/tar sendbackup: info RECOVER_CMD=/usr/bin/tar -f... - sendbackup: info end ? sendbackup: index tee cannot write [Broken pipe] sendbackup: error [/usr/bin/tar got signal 13, index returned 1] \ /tmp/amanda/sendbackup.debug says: sendbackup: debug 1 pid 25453 ruid 1000 euid 1000 start time Thu Sep 6 02:08:29 2001 /usr/local/libexec/amanda/sendbackup: got input request: GNUTAR /usr 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;index;exclude-list=/usr/local/lib/amanda/exclude.gtar; parsed request as: program `GNUTAR' disk `/usr' lev 0 since 1970:1:1:0:0:0 opt `|;bsd-auth;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;' sendbackup: exclude list file "/usr/local/lib/amanda/exclude.gtar" does not exist, ignoring waiting for connect on 2473, then 2474, then 2475 got all connections sendbackup: doing level 0 dump as listed-incremental: /usr/local/var/amanda/gnutar-lists/galadriel.shcorp.com_usr_0.new sendbackup: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: spawning "/usr/local/libexec/amanda/runtar" in pipeline sendbackup: argument list: "gtar" "--create" "--directory" "/usr" "--listed-incremental" "/usr/local/var/amanda/gnutar-lists/galadriel.shcorp.com_usr_0.new" "--sparse" "--one-file-system" "--ignore-failed-read" "--totals" "--file" "-" "." sendbackup-gnutar: pid 25456: /usr/local/libexec/amanda/runtar --create --directory /usr --listed-incremental /usr/local/var/amanda/gnutar-lists/galadriel.shcorp.com_usr_0.new --sparse --one-file-system --ignore-failed-read --totals --file - . sendbackup: started index creator: "/usr/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'" index tee cannot write [Broken pipe] error [/usr/bin/tar got signal 13, index returned 1] any ideas on how to fix this? TIA!
Re: "index tee broken pipe" problem again
On Thu, 2 Aug 2001, John R. Jackson wrote: > >... I haven't touched something since weeks. > > Yeah, yeah, yeah. We've all heard that story before :-). OK., I'm catched. :-)) I touched something on sunday: my firewall. :-( Seems to be a firewall problem now, packets were dropped since I installed SP4 and some hotfixes on my Checkpoint fireall, complaining "unknown established TCP packet". Does anybody have experience with that? I changed a file according to phoneboys FAQ, if that solves the problem remains to be seen on my next backup tomorrow. Bye, Gaby -- enlog AGDaimlerstr. 15 - 89079 Ulm Dipl. Inf. Gaby Hornik Germany Systems Administrator Tel.: +49 731 2075134 mailto:[EMAIL PROTECTED] Fax: +49 731 2075109
Re: "index tee broken pipe" problem again
On Thu, 2 Aug 2001, John R. Jackson wrote: > >... I haven't touched something since weeks. > > Yeah, yeah, yeah. We've all heard that story before :-). He hereally! :-))) > >Here is, what amanda report says: > >? sendbackup: index tee cannot write [Broken pipe] > > What else was in the Amanda report, in particular about this disk or > from taper? Nothing, except the STRANGE messages coming with backing up windows shares over Samba. taper: first fail on Monday night: no error message second fail on Tuesday night: nothing, but planner said someting: planner: Last full dump of shop:hda4 on tape enlog-std002 overwritten on this run. Wednesday night: nothing about this special disk last night: nothing but tape is [OK] > This typically means the backup was going along OK and the tape server > side shut down for some reason, such as running out of holding disk > space or running out of tape. The "index tee cannot write" is just a > symptom of something else going on. Hmmm...I have 50 GB on holding disk, backup was about 10 GB and this special disk has only 500 MB used. Now, weekly backup will start in half an our and I will watch whats happening. Thanks, Gaby -- enlog AGDaimlerstr. 15 - 89079 Ulm Dipl. Inf. Gaby Hornik Germany Systems Administrator Tel.: +49 731 2075134 mailto:[EMAIL PROTECTED] Fax: +49 731 2075109
"index tee broken pipe" problem again
Hello!
I have this problem since two days. I can't figure
out whats wrong, because I haven't touched something
since weeks.
I also searched Yahoo egroup for this, but I didn't
find a solution.
Here is, what amanda report says:
/-- shop hda4 lev 0 FAILED [data timeout]
sendbackup: start [shop:hda4 level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/sbin/restore -f... -
sendbackup: info end
| DUMP: Date of this level 0 dump: Thu Aug 2 00:52:01 2001
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/hda4 (/var) to standard output
| DUMP: Label: none
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 431729 tape blocks.
| DUMP: Volume 1 started at: Thu Aug 2 00:53:17 2001
? sendbackup: index tee cannot write [Broken pipe]
| DUMP: Broken pipe
| DUMP: The ENTIRE dump is aborted.
? index returned 1
sendbackup: error [/sbin/dump returned 3]
\
Seems that sendbackup has some problems, so I looked
into sendbackup.debug:
sendbackup: debug 1 pid 1628 ruid 37 euid 37 start time Thu Aug 2
00:52:01 2001
/usr/local/libexec/sendbackup: got input request: DUMP hda4 0
1970:1:1:0:0:0 OPTIONS |;bsd-auth;index;
parsed request as: program `DUMP' disk `hda4' lev 0 since 1970:1:1:0:0:0
opt `|;bsd-auth;index;'
waiting for connect on 50054, then 50055, then 50056
got all connections
sendbackup: spawning "/usr/local/libexec/rundump" in pipeline
sendbackup: argument list: "dump" "0usf" "1048576" "-" "/dev/hda4"
sendbackup: started index creator: "/sbin/restore -tvf - 2>&1 | sed -e '
s/^leaf[]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
index tee cannot write [Broken pipe]
error [/sbin/dump returned 3]
Can somebody give me a hint whats wrong?
Thanks, Gaby
--
enlog AGDaimlerstr. 15 - 89079 Ulm
Dipl. Inf. Gaby Hornik Germany
Systems Administrator Tel.: +49 731 2075134
mailto:[EMAIL PROTECTED] Fax: +49 731 2075109
Re: "index tee broken pipe" problem again
>... I haven't touched something since weeks. Yeah, yeah, yeah. We've all heard that story before :-). >Here is, what amanda report says: >? sendbackup: index tee cannot write [Broken pipe] What else was in the Amanda report, in particular about this disk or from taper? This typically means the backup was going along OK and the tape server side shut down for some reason, such as running out of holding disk space or running out of tape. The "index tee cannot write" is just a symptom of something else going on. >Gaby John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Broken pipe errors
>A DDS-3 tape should hold 12GB, compressed, right? It looks like "taper" >dies after 10GB. Does the TAPE-ERROR/short write mean the tape is bad? If >the tape was more full, I wouldn't be suspicious; but it seems like I >should be getting more space out of 125m. Amanda consider only the non-compressed size. Compressed size is a commercial only argument, that has NO reality. Do NOT calculate with compressed size. Olivier
Re: Broken pipe errors
>> You don't, by any chance, have both hardware and software compression >> turned on, do you? > >How do I tell, exactly? I have a dumptype line reading > > compress client fast > >But that just seems like which CPU it uses to compute the compression >algorithm. This line says you are using software compression. It also happens to say it's done on the client, but that doesn't really matter. Since you're using software compression, you **must** turn off hardware compression. How you do that is highly OS dependent (it's based on the tape device name for Solaris and AIX, I think it's an "mt" command for Linux, and so on). If you want to use hardware compression, you should turn off software compression with: compress none ... for all the dumptypes. I wouldn't advise going that route unless you're having trouble (e.g. excessive load or wallclock time) with software compression. Software does a better job (since it can look at longer strings of data) and is more flexible (you could turn it off for just certain disks whose data was already compressed, for instance). >> Which size specification? If you mean the one from taper, it's very >> accurate (to the KByte). > >Good. By "the one from taper" I was referring to the "taper: tape /dev/whatever kb NNN fm NNN ..." line in the "NOTES" section of the E-mail (or in the amdump.NN file). All the other Amanda statistics are based on what was *successfully* done. So if the image being processed at the time of the error was large, they could be way off from where the error happened. >Drew John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Broken pipe errors
* "John R. Jackson" <[EMAIL PROTECTED]>: > > I thought DDS-3 was 12 native and 24 compressed. You're right. I had my terminology mixed up. By "12 compressed" I meant *after* the compression had taken effect. Anyway... > You don't, by any chance, have both hardware and software compression > turned on, do you? How do I tell, exactly? I have a dumptype line reading compress client fast But that just seems like which CPU it uses to compute the compression algorithm. > Double compressing things often makes them expand, > i.e. you don't even get the native capacity, and might explain what > you're seeing. That could explain a lot. I inherited this system from a previous admin who had a few gigabytes less data to back-up. Now, after a few months have passed, I'm the one stuck with the tapes filling up. He very well could have been using both compression types and not have known it. > Which size specification? If you mean the one from taper, it's very > accurate (to the KByte). Good. > If you mean the one from the manufacturer, well, let's just say a lot > of those folks won't ever have an employment problem as long as there > are cars (or snake oil :-). We all can't be engineers... :) -- Drew
Re: Broken pipe errors
>A DDS-3 tape should hold 12GB, compressed, right? ... I thought DDS-3 was 12 native and 24 compressed. >It looks like "taper" dies after 10GB. ... Correct. >Does the TAPE-ERROR/short write mean the tape is bad? ... It means taper got an error. That, in turn, might mean any number of things are bad (tape, drive, cleaning, cables, distance to the nearest candy machine, etc). You don't, by any chance, have both hardware and software compression turned on, do you? Double compressing things often makes them expand, i.e. you don't even get the native capacity, and might explain what you're seeing. >How accurate is the size specification of the tape? Which size specification? If you mean the one from taper, it's very accurate (to the KByte). If you mean the one from the manufacturer, well, let's just say a lot of those folks won't ever have an employment problem as long as there are cars (or snake oil :-). >Drew John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Broken pipe errors
> A DDS-3 tape should hold 12GB, compressed, right? It looks like "taper" > dies after 10GB. Does the TAPE-ERROR/short write mean the tape is bad? If > the tape was more full, I wouldn't be suspicious; but it seems like I > should be getting more space out of 125m. DDS-3 holds 12 GB uncompressed. Period. Don't count on what marketing people say. blah, 24 GB, blah... They have no clue of technical details. It depends on the compressibility of your data how much will fit with _either_ hardware or software (gzip/bzip2) compression onto a tape. _Do not_ use both hard and software compression. _It will_ enlarge your data. You get something around 20 GB of the usual data mix onto DDS-3 using either hardware or software compression. Lots of source code, executables, news or mails extend compressibility, lots of mp3's or gzipped files reduce it. It's the amount of entropy in a file being important for reducing it's size. Do you really expect some algorithm being able to reduce an mp3 in size with no loss of information which in turn already has only 1/10th of the original PCM signal _with_ loss of information? - May this loss be detectable with your ears or not. How do you want to compress _random_ data? What similarities do you expect in random data to be able to write them in a short term? I assume you're using hardware compression with gzipped images. Something between 9.5 to 10 GB is here the usual limit on DDS-3. Using software compression makes things clearer for Amanda. She knows how much an image compresses in full and incrementals. This information will be used in planner stage deciding what to backup in what level. The usable tape size value can be very accurate. Hardware compression saves your CPU times, but Amanda doesn't have a clue about the compressibility of each image. So you use an average value for tape size hoping for the best. > How accurate is the size specification of the tape? When I pushed Amanda to the limit by adding more and more hosts or filesystems using software compression, I noticed tapetype's measure being very accurate. Sometimes it didn't fit onto one tape (DDS-2, 4 GB) because it failed to write 10-50 MB. This is a real good guess! You'll have to pay lot's of money to get a measuring instrument working below 1 % error.
Broken pipe errors
I'm having some seemingly elementary errors that I don't quite understand.
Using Solaris 2.7, Amanda 2.4.1p1, Sun StorEdge DDS-3 changer on an E450.
>From the amdump log:
driver: dumping phg:/export/home directly to tape
driver: send-cmd time 11090.642 to taper: PORT-WRITE 00-00043 phg
/export/home 0 20010630
driver: result time 11090.656 from taper: PORT 41252
driver: send-cmd time 11090.660 to dumper0: PORT-DUMP 01-00044 41252 phg
/export/home 0 1970:1:1:0:0:0 DUMP |;bsd-auth;compress-fast;index;
driver: state time 11090.660 free kps: 1357 space: 15843292 taper: writing
idle-dumpers: 3 qlen tape q: 0 runq: 0 stoppedq: 0 wakeup: 86400 driver-idle:
not-idle
driver: interface-state time 11090.660 if : free 1 if LE0: free 1
if LOCAL: free 357
driver: hdisk-state time 11090.660 hdisk 0: free 15843292 dumpers 0
taper: writing end marker. [phg-weekly-015 ERR kb 10020128 fm 22]
driver: result time 14749.051 from dumper0: FAILED 01-00044 ["data write:
Broken pipe"]
dumper: kill index command
driver: result time 14749.051 from taper: TAPE-ERROR 00-00043 [writing
file: short write]
driver: QUITTING time 14749.137 telling children to quit
driver: send-cmd time 14749.137 to taper: QUIT
Broken Pipe
amdump: end at Sat Jun 30 05:05:50 CDT 2001
A DDS-3 tape should hold 12GB, compressed, right? It looks like "taper"
dies after 10GB. Does the TAPE-ERROR/short write mean the tape is bad? If
the tape was more full, I wouldn't be suspicious; but it seems like I
should be getting more space out of 125m.
How accurate is the size specification of the tape?
--
Drew
Re: Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe]
The problem ended up being the autosensing media. I have never run into a problem with a media autosense before but I think from now on I will try to set that every time I setup a network card. Thanks for the Help, Ryan Williams - Original Message - From: "John R. Jackson" <[EMAIL PROTECTED]> To: "Ryan Williams" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 01, 2001 6:59 PM Subject: Re: Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe] > >It is a 100meg card set to autoselect between all of the 100 and 10 base T. > > Uh, huh. On Solaris, at least, autoselect is death. No matter what > you try to do, it will pick wrong and really bad things start to happen. > We **always** force the issue with an explicit config file entry. > > I don't know that's what's happening to you, but it's been a common > problem. > > >The network is a 10baseT. I am not shure if it is full or half duplex. ... > > I'm out of my depth here, but I think if the cable is actually 10Mbit, > duplex does not matter. Only 100Mbit bring duplex into the picture. > > >What do you make of that. I dont see anywhere that it says what it is > >actually set at. ... > > Which might make sense if it does not apply because you're really only > doing 10Mbit. > > >> It would also be useful to go to the client and look at sendbackup*debug > >> in /tmp/amanda, in particular the start and stop time (first and last > >> lines). > > > >/usr/local/libexec/sendbackup: got input request: DUMP ad0s1e 0 > >1970:1:1:0:0:0 OPTIONS |;bsd-auth;srvcomp-fast;index; > > parsed request as: program `DUMP' disk `ad0s1e' lev 0 since 1970:1:1:0:0:0 > >opt `|;bsd-auth;srvcomp-fast;index;' > > waiting for connect on 2622, then 2623, then 2624 > >/usr/local/libexec/sendbackup: timeout on mesg port 2623 > >/usr/local/libexec/sendbackup: timeout on index port 2624 > >sendbackup: pid 79500 finish time Tue May 1 01:47:00 2001 > > You cut off the first line, but in any case, this indicates something else > is going on. It says sendbackup on the client got tired (30 seconds) > of waiting on dumper on the server side to make the connections on > those ports. The next line after "waiting for connect ..." should have > been "got all connections". > > The sequence of events is: > > dumper connects to the amandad port on the client > > they do some security stuff (UDP packets) then dumper tells it to > start sendbackup > > sendbackup starts listening on two or three new ports and sends their > numbers (UDP packet) back to dumper on the server > > dumper connects to those ports (TCP) on the client and data starts > to flow > > So either dumper never got the list of ports, or the connections it > tried to make didn't work. It looks like dumper would log an error if > the connection failed, which implies sendbackup never saw it. > > If you upgrade at least the server to 2.4.2p2, you'll get messages > like this in the amdump.NN file showing that dumper did its part: > > dumper: stream_client: connected to 128.210.10.26.63832 > dumper: stream_client: our side is 0.0.0.0.63834 > > Upgrading the client would show similar extra detail on that side. > > I don't know why this would be happening. Any firewalls or other > protection between the two machines that would not allow these ports to > go through? Any help from the FreeBSD folks? > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe]
>It is a 100meg card set to autoselect between all of the 100 and 10 base T. Uh, huh. On Solaris, at least, autoselect is death. No matter what you try to do, it will pick wrong and really bad things start to happen. We **always** force the issue with an explicit config file entry. I don't know that's what's happening to you, but it's been a common problem. >The network is a 10baseT. I am not shure if it is full or half duplex. ... I'm out of my depth here, but I think if the cable is actually 10Mbit, duplex does not matter. Only 100Mbit bring duplex into the picture. >What do you make of that. I dont see anywhere that it says what it is >actually set at. ... Which might make sense if it does not apply because you're really only doing 10Mbit. >> It would also be useful to go to the client and look at sendbackup*debug >> in /tmp/amanda, in particular the start and stop time (first and last >> lines). > >/usr/local/libexec/sendbackup: got input request: DUMP ad0s1e 0 >1970:1:1:0:0:0 OPTIONS |;bsd-auth;srvcomp-fast;index; > parsed request as: program `DUMP' disk `ad0s1e' lev 0 since 1970:1:1:0:0:0 >opt `|;bsd-auth;srvcomp-fast;index;' > waiting for connect on 2622, then 2623, then 2624 >/usr/local/libexec/sendbackup: timeout on mesg port 2623 >/usr/local/libexec/sendbackup: timeout on index port 2624 >sendbackup: pid 79500 finish time Tue May 1 01:47:00 2001 You cut off the first line, but in any case, this indicates something else is going on. It says sendbackup on the client got tired (30 seconds) of waiting on dumper on the server side to make the connections on those ports. The next line after "waiting for connect ..." should have been "got all connections". The sequence of events is: dumper connects to the amandad port on the client they do some security stuff (UDP packets) then dumper tells it to start sendbackup sendbackup starts listening on two or three new ports and sends their numbers (UDP packet) back to dumper on the server dumper connects to those ports (TCP) on the client and data starts to flow So either dumper never got the list of ports, or the connections it tried to make didn't work. It looks like dumper would log an error if the connection failed, which implies sendbackup never saw it. If you upgrade at least the server to 2.4.2p2, you'll get messages like this in the amdump.NN file showing that dumper did its part: dumper: stream_client: connected to 128.210.10.26.63832 dumper: stream_client: our side is 0.0.0.0.63834 Upgrading the client would show similar extra detail on that side. I don't know why this would be happening. Any firewalls or other protection between the two machines that would not allow these ports to go through? Any help from the FreeBSD folks? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe]
- Original Message - From: "John R. Jackson" <[EMAIL PROTECTED]> To: "Ryan Williams" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, April 30, 2001 7:20 PM Subject: Re: Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe] > >Below are the two pertinant parts (I think) of an error that is occuring on > >an everyday basis on this server. ... > > What version of Amanda? Same version on client and server? 2.4.2 on both client and server > > >... There are 11 other servers that are being backed up > >just fine but this one just does not want to work. ... > > So what's different about it? (just kidding :-). > > >... Of course it was upgraded because we could not > >find a network card that worked decently ... > > Are we talking 100 Mbit Ethernet? Any chance you have a duplex problem > between the client and switch? Getting that wrong can cause truly > amazingly bad performance. > It is a 100meg card set to autoselect between all of the 100 and 10 base T. The network is a 10baseT. I am not shure if it is full or half duplex. It could be a duplex problem. I believe that our backup network can only support 1/2 duplex. rl0: flags=8843 mtu 1500 inet 10.0.0.203 netmask 0xff00 broadcast 10.0.0.255 inet6 fe80::250:baff:fe88:c760%rl0 prefixlen 64 scopeid 0x2 ether 00:50:ba:88:c7:60 media: autoselect (none) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX What do you make of that. I dont see anywhere that it says what it is actually set at. Mabey I should try and manually set the mode on the card. > > web45.inte ad0s1f lev 0 FAILED [data timeout] > > web45.inte ad0s1a lev 0 FAILED [could not connect to web45.internal] > > web45.inte ad0s1e lev 0 FAILED [could not connect to web45.internal] > > The first one says Amanda waited 30 minutes between getting started or > getting a block of data and then gave up. I'm guessing the other two > failures were because amandad was still running on the client and so > the new connections were not allowed. > > If you're running 2.4.2 or beyond, you could increase the dtimeout > value in amanda.conf, but half an hour to wait on data is a long time. > I suspect it means something else is wrong. > 1/2 an hour should be plenty of time I would think. > It would also be useful to go to the client and look at sendbackup*debug > in /tmp/amanda, in particular the start and stop time (first and last > lines). > /usr/local/libexec/sendbackup: got input request: DUMP ad0s1e 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;srvcomp-fast;index; parsed request as: program `DUMP' disk `ad0s1e' lev 0 since 1970:1:1:0:0:0 opt `|;bsd-auth;srvcomp-fast;index;' waiting for connect on 2622, then 2623, then 2624 /usr/local/libexec/sendbackup: timeout on mesg port 2623 /usr/local/libexec/sendbackup: timeout on index port 2624 sendbackup: pid 79500 finish time Tue May 1 01:47:00 2001 > The "index tee cannot write [Broken pipe]" stuff is just a symptom of > the server giving up on the client. The server shut down the connections > and the client was still trying to write, so it got a "broken pipe" error. > The real problem is why the data stream quit moving. > > Some other possibilities: > > * An **extremely** busy disk that tar has a hard time getting access > to. > Judging on a ps auxw, It does not appear that the server is doing an awefull lot on the disk. It should not be doing much as it is mostly just a mail server for a small number of users. > * A busy client and you have compression turned on, so it just cannot > get enough CPU. > It has a big enough cpu to try and do so I would believe. It is a PII 350 and like I said it does not do much. > * A very large file system that compresses extremely well so tar and > gzip are crunching along but not generating any (enough) output. > Small filesystem. The whole server is only about 3-4 gigs used. > * A broken disk that is very slow to respond (e.g. lots of retries). > I dont see any evidence of this on the server. > * Some kind of networking problem, software or hardware. You might > try some big ftp put's from the client to /dev/null on the server > and see what happens. > Most likely. I was at first under the impression from the output that it was a software problem. I am going to look further into the hardware aspects of it now. > >Ryan Williams > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] > Thanks
Re: Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe]
>Below are the two pertinant parts (I think) of an error that is occuring on >an everyday basis on this server. ... What version of Amanda? Same version on client and server? >... There are 11 other servers that are being backed up >just fine but this one just does not want to work. ... So what's different about it? (just kidding :-). >... Of course it was upgraded because we could not >find a network card that worked decently ... Are we talking 100 Mbit Ethernet? Any chance you have a duplex problem between the client and switch? Getting that wrong can cause truly amazingly bad performance. > web45.inte ad0s1f lev 0 FAILED [data timeout] > web45.inte ad0s1a lev 0 FAILED [could not connect to web45.internal] > web45.inte ad0s1e lev 0 FAILED [could not connect to web45.internal] The first one says Amanda waited 30 minutes between getting started or getting a block of data and then gave up. I'm guessing the other two failures were because amandad was still running on the client and so the new connections were not allowed. If you're running 2.4.2 or beyond, you could increase the dtimeout value in amanda.conf, but half an hour to wait on data is a long time. I suspect it means something else is wrong. It would also be useful to go to the client and look at sendbackup*debug in /tmp/amanda, in particular the start and stop time (first and last lines). The "index tee cannot write [Broken pipe]" stuff is just a symptom of the server giving up on the client. The server shut down the connections and the client was still trying to write, so it got a "broken pipe" error. The real problem is why the data stream quit moving. Some other possibilities: * An **extremely** busy disk that tar has a hard time getting access to. * A busy client and you have compression turned on, so it just cannot get enough CPU. * A very large file system that compresses extremely well so tar and gzip are crunching along but not generating any (enough) output. * A broken disk that is very slow to respond (e.g. lots of retries). * Some kind of networking problem, software or hardware. You might try some big ftp put's from the client to /dev/null on the server and see what happens. >Ryan Williams John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Strange Amanda Error: sendbackup: index tee cannot write [Broken pipe]
Below are the two pertinant parts (I think) of an error that is occuring on an everyday basis on this server. Amcheck runs just fine, it just does not work on this server. There are 11 other servers that are being backed up just fine but this one just does not want to work. I recently upgraded the OS from Freebsd 2.2.7 to Freebsd 4.2. This is when the error started occuring. The upgrade kind of botched itself when it ran but I was able to recover most of the server. Of course it was upgraded because we could not find a network card that worked decently to do a backup with amanda so we did not have a backup of the server. (3c509's work terriably in Freebsd, especially under a load like amanda, even the fix that we found on one of the mailing lists did not fix the problem) Any help would be appreciated. Also if there is any further information that I could give pertaining to this backup. FAILURE AND STRANGE DUMP SUMMARY: web45.inte ad0s1f lev 0 FAILED [data timeout] web45.inte ad0s1a lev 0 FAILED [could not connect to web45.internal] web45.inte ad0s1e lev 0 FAILED [could not connect to web45.internal] /-- web45.inte ad0s1f lev 0 FAILED [data timeout] sendbackup: start [web45.internal:ad0s1f level 0] sendbackup: info BACKUP=/usr/bin/tar sendbackup: info RECOVER_CMD=/usr/bin/tar -f... - sendbackup: info end ? sendbackup: index tee cannot write [Broken pipe] ? index returned 1 sendbackup: error [/usr/bin/tar got signal 13] \ Regards, Ryan Williams
Re: broken pipe
Am Donnerstag, 15. Februar 2001 09:50 schrieben Sie: > See? No failures. You can use amtoc or amadmin info to find out in > which tape the filesystem was stored. OK, no failure. Amadmin tell me that the backup is ok. I thank you for your help and Infos. Bye Juergen -- Dies ist eine Microsoft freie Mail!
Re: broken pipe
On Feb 15, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote:
> fileserver sdb10 1319558413195584 -- 40:525380.8 40:555375.7
> fileserver sdc10 1313555213135552 -- 45:114844.5 45:134840.9
> fileserver sdd10 92850889285088 -- 30:535009.9 30:555005.7
> king hdb10 98416969841696 -- 43:483745.2 43:483744.4
See? No failures. You can use amtoc or amadmin info to find out in
which tape the filesystem was stored.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: broken pipe
Am Donnerstag, 15. Februar 2001 08:51 schrieben Sie:
Hi Alexandre!
> > Also the backup is finnished correctly?
> I'd guess so, but you didn't post the part of the report that says
> which dumps made to which tape, so I can't tell for sure.
OK, i send you the complete mail from amanda and hope that it helps:
Begin complete mail fom Amanda
These dumps were to tapes Daily01, Daily02.
Tonight's dumps should go onto 2 tapes: Daily03, Daily04.
FAILURE AND STRANGE DUMP SUMMARY:
fileserver sdc1 lev 0 FAILED ["data write: Broken pipe"]
fileserver sdc1 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:10
Run Time (hrs:min) 3:45
Dump Time (hrs:min)2:41 2:41 0:00
Output Size (meg) 44392.544392.50.0
Original Size (meg) 44392.544392.50.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped4 4 0
Avg Dump Rate (k/s) 4713.1 4713.1--
Tape Time (hrs:min)2:41 2:41 0:00
Tape Size (meg) 44392.644392.60.0
Tape Used (%) 111.0 111.00.0
Filesystems Taped 4 4 0
Avg Tp Write Rate (k/s) 4710.0 4710.0--
FAILED AND STRANGE DUMP DETAILS:
/-- fileserver sdc1 lev 0 FAILED ["data write: Broken pipe"]
sendbackup: start [fileserver:sdc1 level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/sbin/restore -f... -
sendbackup: info end
| DUMP: Date of this level 0 dump: Thu Feb 15 04:14:16 2001
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/sdc1 (/test/platte3) to standard output
| DUMP: Label: none
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 13086232 tape blocks.
| DUMP: Volume 1 started at: Thu Feb 15 04:14:58 2001
| DUMP: dumping (Pass III) [directories]
| DUMP: dumping (Pass IV) [regular files]
| DUMP: 10.23% done, finished in 0:43
| DUMP: 21.75% done, finished in 0:35
| DUMP: 33.32% done, finished in 0:30
| DUMP: 44.95% done, finished in 0:24
| DUMP: 57.16% done, finished in 0:18
| DUMP: 68.34% done, finished in 0:13
| DUMP: 80.59% done, finished in 0:08
\
NOTES:
taper: tape Daily01 kb 44245472 fm 4 writing file: No space left on device
taper: retrying fileserver:sdc1.0 on new tape: [writing file: No space left
on device]
taper: tape Daily02 kb 13135584 fm 1 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
fileserver sdb10 1319558413195584 -- 40:525380.8 40:555375.7
fileserver sdc10 1313555213135552 -- 45:114844.5 45:134840.9
fileserver sdd10 92850889285088 -- 30:535009.9 30:555005.7
king hdb10 98416969841696 -- 43:483745.2 43:483744.4
(brought to you by Amanda version 2.4.2-19991216-beta1)
---End of Mail from Amanda
Bye Jeurgen
--
Dies ist eine Microsoft freie Mail!
Re: broken pipe
On Feb 15, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote:
> Also the backup is finnished correctly?
I'd guess so, but you didn't post the part of the report that says
which dumps made to which tape, so I can't tell for sure.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: broken pipe
Am Donnerstag, 15. Februar 2001 08:40 schrieben Sie: > On Feb 15, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote: > > fileserver sdc1 lev 0 FAILED ["data write: Broken pipe"] > > fileserver sdc1 lev 0 FAILED [dump to tape failed] > [snip] > > taper: tape Daily01 kb 44245472 fm 4 writing file: No space left on > > device > Looks like tape full. Ok, the tape is full, > > taper: tape Daily02 kb 13135584 fm 1 [OK] > Looks like Amanda recovered correctly, restarting the dump in the > following tape. and used the next tape. Also the backup is finnished correctly? Bye Juergen -- Dies ist eine Microsoft freie Mail!
Re: broken pipe
On Feb 15, 2001, Juergen Knott <[EMAIL PROTECTED]> wrote:
> fileserver sdc1 lev 0 FAILED ["data write: Broken pipe"]
> fileserver sdc1 lev 0 FAILED [dump to tape failed]
[snip]
> taper: tape Daily01 kb 44245472 fm 4 writing file: No space left on device
Looks like tape full.
> taper: tape Daily02 kb 13135584 fm 1 [OK]
Looks like Amanda recovered correctly, restarting the dump in the
following tape.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
broken pipe
Hi!
At first i installed amanda for a long time on a tape server and amanda works
fine.
After insatlling amanda on a client i have this problems.
---Begin Amanda Mail
These dumps were to tapes Daily01, Daily02.
Tonight's dumps should go onto 2 tapes: Daily03, Daily04.
FAILURE AND STRANGE DUMP SUMMARY:
fileserver sdc1 lev 0 FAILED ["data write: Broken pipe"]
fileserver sdc1 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:10
Run Time (hrs:min) 3:45
Dump Time (hrs:min)2:41 2:41 0:00
Output Size (meg) 44392.544392.50.0
Original Size (meg) 44392.544392.50.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped4 4 0
Avg Dump Rate (k/s) 4713.1 4713.1--
Tape Time (hrs:min)2:41 2:41 0:00
Tape Size (meg) 44392.644392.60.0
Tape Used (%) 111.0 111.00.0
Filesystems Taped 4 4 0
Avg Tp Write Rate (k/s) 4710.0 4710.0--
FAILED AND STRANGE DUMP DETAILS:
/-- fileserver sdc1 lev 0 FAILED ["data write: Broken pipe"]
sendbackup: start [fileserver:sdc1 level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/sbin/restore -f... -
sendbackup: info end
| DUMP: Date of this level 0 dump: Thu Feb 15 04:14:16 2001
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/sdc1 (/drive/drive3) to standard output
| DUMP: Label: none
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 13086232 tape blocks.
| DUMP: Volume 1 started at: Thu Feb 15 04:14:58 2001
| DUMP: dumping (Pass III) [directories]
| DUMP: dumping (Pass IV) [regular files]
| DUMP: 10.23% done, finished in 0:43
| DUMP: 21.75% done, finished in 0:35
| DUMP: 33.32% done, finished in 0:30
| DUMP: 44.95% done, finished in 0:24
| DUMP: 57.16% done, finished in 0:18
| DUMP: 68.34% done, finished in 0:13
| DUMP: 80.59% done, finished in 0:0
\
NOTES:
taper: tape Daily01 kb 44245472 fm 4 writing file: No space left on device
taper: retrying fileserver:sdc1.0 on new tape: [writing file: No space left
on device]
taper: tape Daily02 kb 13135584 fm 1 [OK]
-- End Message from Amanda
What´s the problem of amanda?
Bye Juergen
