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
Paul Yeatman wrote:
-In response to your message-
--received from Jean-Louis Martineau--
Paul,
I haven't followed the thread and I don't have old mail.
You should not need bsdudp.
Your disklist should specify : auth bsdtcp
Are you sure you have a correct plist for bsdtcp?
Are you sure in
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
Hope someone can help me out here.
I'm testing Amanda 2.5.0 on RHEL5, to upgrade from our older version.
Everything went well and I can successfully back up older clients.
However, when trying to do an amrecover (as root and to the backup
server itself), using the config I've set up (called
It's not a .amandahosts problem.
Check the xinetd configuration for the amindexd service.
Check system log for xinetd error.
Jean-Louis
Johan Booysen wrote:
Hope someone can help me out here.
I'm testing Amanda 2.5.0 on RHEL5, to upgrade from our older version.
Everything went well and I
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
14 matches
Mail list logo
