Stefan G. Weichinger schrieb:
A DLE with ~180GB fails to be retried on the second tape (LTO-3-changer)
with
FAILED [data write: Connection reset by peer]
I already decreased tcp_keepalive_time yesterday but tonight's amdump
failed again.
As the upper message doesn't come from mesg, but
Stefan G. Weichinger a écrit :
Stefan G. Weichinger schrieb:
A DLE with ~180GB fails to be retried on the second tape
(LTO-3-changer) with
FAILED [data write: Connection reset by peer]
I already decreased tcp_keepalive_time yesterday but tonight's amdump
failed again.
As the upper
jehan procaccia schrieb:
For my initial problem, etimouts + dtimeouts ... I suspect a firewall
issue, maybe it can help in your case ?
http://wiki.zmanda.com/index.php/Results_missing
When using the iptables *ip_conntrack_amanda* kernel module in the
firewall, you may need to adjust the
Some infos from the client-side:
---
sendbackup: start: server:data_db lev 0
sendbackup: time 0.092: spawning /bin/gzip in pipeline
sendbackup: time 0.092: argument list: /bin/gzip --fast
sendbackup-gnutar: time 0.092: pid 29494: /bin/gzip --fast
sendbackup-gnutar: time 0.092: doing level 0
You are doing a dump to tape and the taper failed.
The dumper close the socket to the client, and the client detect the
socket is close.
The first error is the taper. sendbackup error is the result of the
taper error.
Jean-Louis
Stefan G. Weichinger wrote:
Some infos from the
On Thu, May 29, 2008 at 12:04 PM, Stefan G. Weichinger [EMAIL PROTECTED]
wrote:
sendbackup: time 11140.170: index tee cannot write [Broken pipe]
sendbackup: time 11140.214: pid 29495 finish time Thu May 29 05:53:19 2008
Seems as if the index-creation fails, correct?
But why would it then
Jean-Louis Martineau schrieb:
You are doing a dump to tape and the taper failed.
The dumper close the socket to the client, and the client detect the
socket is close.
The first error is the taper. sendbackup error is the result of the
taper error.
But shouldn't the taper simply retry that
Dustin J. Mitchell schrieb:
The first is probably a consequence of the second -- a dump was
aborted because the server ran out of tape, and as a consequence
sendbackup closed the index stream, which caused the tar -tf to fail,
which caused the error you see in the sendbackup log.
But things
It must abort the dump, and restart it.
Jean-Louis
Stefan G. Weichinger wrote:
Jean-Louis Martineau schrieb:
You are doing a dump to tape and the taper failed.
The dumper close the socket to the client, and the client detect the
socket is close.
The first error is the taper. sendbackup
Jean-Louis Martineau schrieb:
It must abort the dump, and restart it.
And what's the solution for my problem?
Stefan
Stefan G. Weichinger wrote:
Jean-Louis Martineau schrieb:
It must abort the dump, and restart it.
And what's the solution for my problem?
Did it retried the dump on the next tape?
Can you explain the problem, because i don't understand it, except you
hit the end of a tape.
Post the
Paul Bijnens schrieb:
On 2008-05-25 18:55, jehan procaccia wrote:
hello,
some clients with big partitions (100Gbytes) freezes my amdump, I
usually get dumps errors which cannot end properly.
I have 2 questions,
1) how can I resolve that client error, timeout or whatever ?
This look
On 2008-05-25 18:55, jehan procaccia wrote:
hello,
some clients with big partitions (100Gbytes) freezes my amdump, I
usually get dumps errors which cannot end properly.
I have 2 questions,
1) how can I resolve that client error, timeout or whatever ?
This look suspiciously like the problem
Paul Bijnens wrote at 12:33 +0200 on May 27, 2008:
On 2008-05-25 18:55, jehan procaccia wrote:
hello,
some clients with big partitions (100Gbytes) freezes my amdump, I
usually get dumps errors which cannot end properly.
I have 2 questions,
1) how can I resolve that client
14 matches
Mail list logo
