On Mon, Jun 15, 2020 at 00:20:25 -0400, Nathan Stratton Treadway wrote:
> On Mon, Jun 15, 2020 at 10:41:58 +0700, Olivier wrote:
> > I have an Amanda client that takes more than 4 hours to do the
> > estimate. The estimate is computed correctly, but when amandad on the
[...]
> Sounds like you
On Mon, Jun 15, 2020 at 10:41:58 +0700, Olivier wrote:
> I have an Amanda client that takes more than 4 hours to do the
> estimate. The estimate is computed correctly, but when amandad on the
> client tries to send back the estimate to the server, the packet times
> out.
>
> I kind of remember
On Saturday 01 August 2015 08:43:24 Gene Heskett wrote:
I forgot to send this at 4:30 am.
It just got done, and the emailed report says the estimate time for a
50 gigabyte backup, was 3 minutes. Total elapsed time a hair over 3
hours.
Cheers, Gene Heskett
Humm, setting that option
On Saturday 01 August 2015 08:43:24 Gene Heskett wrote:
I forgot to send this at 4:30 am.
It just got done, and the emailed report says the estimate time for a
50 gigabyte backup, was 3 minutes. Total elapsed time a hair over 3
hours.
Cheers, Gene Heskett
3 days of uptime, and this machine
On Tuesday 04 August 2015 09:02:05 Gene Heskett wrote:
On Saturday 01 August 2015 08:43:24 Gene Heskett wrote:
I forgot to send this at 4:30 am.
It just got done, and the emailed report says the estimate time for
a 50 gigabyte backup, was 3 minutes. Total elapsed time a hair over
3
On Fri, Jul 31, 2015 at 10:38:54PM -0400, Gene Heskett wrote:
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over
On Saturday 01 August 2015 03:26:55 Jon LaBadie wrote:
On Fri, Jul 31, 2015 at 10:38:54PM -0400, Gene Heskett wrote:
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
On Saturday 01 August 2015 03:59:28 Gene Heskett wrote:
On Saturday 01 August 2015 03:26:55 Jon LaBadie wrote:
On Fri, Jul 31, 2015 at 10:38:54PM -0400, Gene Heskett wrote:
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5 always
work.
And it failed last night again, after only 3 days uptime. and only this
machine. From an amcheck and GO704 is turned off:
Grr! My etimeout is 2000 but yours is certainly in that ball park.
I’d try it at 20,000 (without the comma) just to see if it changes anything.
For a while.
Although, I guess “waiting forever” is what it is currently already
doing, isn’t it?
Hmmm. Thinking.
Deb Baddorf
On Jul
Back on the list, this server aparently does not set a reply-to. So a
reply to list comes up with a blank To: address line.
On Friday 31 July 2015 12:21:39 Debra S Baddorf wrote:
Grr! My etimeout is 2000 but yours is certainly in that ball
park. I’d try it at 20,000 (without the comma)
Gene: Have you seen these additional debug parameters? There may be even more
than these. This is the list that seemed useful to me, when I pulled them.
They go in the amanda.conf
file. They can produce a huge log file, but perhaps it might say more?
## temp settings 4/3/13 dsb
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5
always work.
etimeout was 600, made it 1800
On Friday 31 July 2015 17:14:19 Debra S Baddorf wrote:
Gene: Have you seen these additional debug parameters? There may be
even more than these. This is the list that seemed useful to me,
when I pulled them.They go in the amanda.conf file. They can
produce a huge log file, but
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5 always
work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5 always
work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small change, 135 megs into swap on an 8Gb equipt
machine.
A reboot fixes
On Sunday 19 July 2015 04:21:29 Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5
always work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small change, 135
There is no timeout in amrecover, it can wait for days.
Amrecover detect the error when the system return the error.
Jean-Louis
On 03/22/2013 05:25 AM, Nagai Megumu wrote:
Hello
I want you to teach about timeout of amrecover.
Execution a restore using the amrecover,time out network
Thankｓ.
It is such specification.
I am glad if it can adjust.
＿
Nagai
(2013/03/25 21:12), Jean-Louis Martineau wrote:
There is no timeout in amrecover, it can wait for days.
Amrecover detect the error when the system return the error.
Jean-Louis
On 03/22/2013 05:25 AM, Nagai Megumu wrote:
On Tue, Jun 1, 2010 at 9:39 AM, McGraw, Robert P rmcg...@purdue.edu wrote:
I am seeing several of the following dumper: [request failed: timeout
waiting for REP](too) errors when I run the amstatus command. Below is a
snippet of one of the errors.
Is the (too) really part of the error?
Can
Add '-auth=bsdtcp in argument to amandad.
Jean-Louis
Abilio Carvalho wrote:
I'm getting this message when trying to run amcheck. I've run
amservice as is specified in the wiki page about this error, and I'm
getting the same error, so it's a client issue. Can someone help me
debug this?
Thanks very much for the help, this is pretty urgent now.
I tried doing that, here's the new problem:
This is the inetadm output:
bash-3.00# inetadm -l svc:/network/amanda/tcp:default
SCOPENAME=VALUE
name=amanda
endpoint_type=stream
proto=tcp
isrpc=FALSE
Sunday 01 March 2009 04:59:54 kirjutasid sa:
Toomas Aas wrote at 11:04 +0200 on Feb 28, 2009:
I have a single-machine (client==server) setup which has been working
well for quite a long time. It's running Amanda 2.5.1p3 on FreeBSD 6.4.
Yesterday I added a new disk to the machine,
Toomas Aas wrote at 10:13 +0200 on Mar 1, 2009:
Sunday 01 March 2009 04:59:54 kirjutasid sa:
Is this new DLE big? Lots of files?
The new DLE is not that big. Its 'raw capacity' is 21 GB, ca 25000 files,
but
most of it are MySQL and PostgreSQL database files which are excluded
Toomas Aas wrote at 11:04 +0200 on Feb 28, 2009:
I have a single-machine (client==server) setup which has been working
well for quite a long time. It's running Amanda 2.5.1p3 on FreeBSD 6.4.
Yesterday I added a new disk to the machine, mounted it under /db and
added corresponding
It seems to have resolved overnight. Strangely, I looked at my command
history, and I definitely turned the firewall off two days ago, before
the last set of failures. I'm just going to assume I screwed up and the
firewall was still on for the last set of failures even though that
doesn't
Good, your client works as expected.
Do you upgraded something else on the server? or just amanda?
Do the server receive the PREP and REP packet, look in amdump.1 log file.
Disable all firewall on the client and server.
On the 2.5.2 client, add 'debug_auth 1' in /etc/amanda/amanda-client.conf
Use
I'm using Amanda version 2.5.1p3 for server and clients. The OS I used is
RHEL4. The problem is the result was not occur for all clients. Before this
the Amanda server can do backup and the result only showed STRANGE not
FAILED OR MISSING. This case only occured couples day ago. That why I was
On Sun, 2007-06-24 at 19:37 -0700, fedora wrote:
I'm using Amanda version 2.5.1p3 for server and clients. The OS I used is
RHEL4. The problem is the result was not occur for all clients. Before this
the Amanda server can do backup and the result only showed STRANGE not
FAILED OR MISSING. This
On Fri, Jun 22, 2007 at 10:02:02PM -0700, fedora wrote:
Hi guys,
If my Amanda shows error like timeout waiting for ACK, which debug file its
in? I can't find that error in any debug files. One more thing, assume that
all settings are right, is it possible that the error caused by network
fedora wrote:
Hi guys,
If my Amanda shows error like timeout waiting for ACK, which debug file its
in? I can't find that error in any debug files. One more thing, assume that
all settings are right, is it possible that the error caused by network
which is slow or up and down?? Pls guide.
Chris Hoogendyk wrote:
fedora wrote:
Hi guys,
If my Amanda shows error like timeout waiting for ACK, which debug file its
in? I can't find that error in any debug files. One more thing, assume that
all settings are right, is it possible that the error caused by network
which is slow
After amcheck I see this message:
planner: ERROR Request to asnserv1 failed: timeout waiting for ACK
What system is Amanda server runnig on? What did you change few days
ago?
Did you reboot the machine and the problem is still there?
What is the result of the following command:
netstat
Hi Oliver,
asnserv1 runnig on Debian Linux 2.6.18-4-amd64 with Amanda-2.5.1p1.
netstat -na |grep 10080 - do nothing.
ping on asnserv1 is normal:
asnserv1:/etc/amanda# ping asnserv1
PING asnserv1.localdomain (192.168.0.253) 56(84) bytes of data.
64 bytes from asnserv1.localdomain (192.168.0.253):
netstat -na |grep 10080 - do nothing.
Hummm, I don't use debian, but if you get nothing it would tend to
mean that amandad is not running on that machine, so when the server
call, nobody answers.
Olivier
Hi,
Leonid Shulov schrieb:
netstat -na |grep 10080 - do nothing.
Then the service is not running. Is it running, when you restart (x)inetd? If
not, then check the system logfile if there are any compliants about that
service entry. If you can't fix it, then please post the error of the
If you are running 2.5.1 or 2.5.1p1, these xinetd and .amandahosts entries
require changes. See
http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication
For troubleshooting this problem, you can also see troubleshooting wiki page:
I am using version 2.5.0p2-1
Paddy Sreenivasan wrote:
If you are running 2.5.1 or 2.5.1p1, these xinetd and .amandahosts
entries
require changes. See
http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication
For troubleshooting this problem, you can also see
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
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]
Hi Cameron,
Cameron Matheson wrote:
Hi everyone,
I really want to start taking advantage of the tape-spanning features of
amanda 2.5, so I've begun the upgrading process... I've come a across a
problem that I am having difficulty resolving though. Here's what I've
done so far.
1) Upgrade
Peter Kunst wrote:
Hi Cameron,
Cameron Matheson wrote:
Hi everyone,
I really want to start taking advantage of the tape-spanning features of
amanda 2.5, so I've begun the upgrading process... I've come a across a
problem that I am having difficulty resolving though. Here's what I've
done so
Hi Peter,
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
Cameron Matheson schreef:
Hi everyone,
I really want to start taking advantage of the tape-spanning features of
amanda 2.5, so I've begun the upgrading process... I've come a across a
problem that I am having difficulty resolving though. Here's what I've
done so far.
1) Upgrade version of
-Original Message-
Just to follow up on this: after making sure a default route
was included with the second ethernet jack, I rebooted
the server machine on the private network, and then ran an
amcheck. It came back properly this time. If the backup
doesn't work correctly
-Original Message-
I have a very weird problem with my amanda system, that maybe others
may be able to help. Here's my issue:
I have a server and two clients. The server and one client are
RedHat 9, while the other client is RHEL 4. The problem I'm having
is with the two RH9
-Original Message-
The server and the client in question are directly connected via
second ethernet jacks and a crossover cable.
First, I would check if the crossover connection is perfectly
working with some network test tool.
Been working with netperf and have
On Thu, 30 Oct 2003 at 3:36pm, Paul Singh wrote
I'm able to get amanda running just ifne without compression running.
Now I want to go ahead and enable it.
I tried using high-tar just to see what would happen, and the system
times out after 30 minutes. I see the data is still compressing
--On Thursday, October 30, 2003 15:36:45 -0500 Paul Singh [EMAIL PROTECTED] wrote:
I'm able to get amanda running just ifne without compression running. Now I want to
go ahead and enable it.
I tried using high-tar just to see what would happen, and the system times out after
30 minutes. I
On Thu, 31 Oct 2002 at 11:38am, Siobhan Gowen wrote
The machine is up and the amanda server and the client can ping eachother.
All running Solaris 2.6. On same net/subnet as other clients that don't time
out. Any suggestions???
I upped the etimeout value from 500 to 5500
This has nothing
. Are there relative
logs on the amanda backup server I could look at?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-amanda-users;amanda.org]On Behalf Of Joshua Baker-LePain
Sent: Thursday, October 31, 2002 11:58 AM
To: Siobhan Gowen
Cc: Alex Specogna; [EMAIL PROTECTED]
Subject: Re: timeout
Baker-LePain
Sent: Thursday, October 31, 2002 11:58 AM
To: Siobhan Gowen
Cc: Alex Specogna; [EMAIL PROTECTED]
Subject: Re: timeout
On Thu, 31 Oct 2002 at 11:38am, Siobhan Gowen wrote
The machine is up and the amanda server and the client can ping eachother.
All running Solaris 2.6. On same net
In a message dated: Tue, 18 Dec 2001 11:17:17 EST
Paul Lussier said:
I'm having problems backing up one particular host on my network.
amandad.debug reports:
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack:
Paul Lussier wrote:
I'm having problems backing up one particular host on my network.
amandad.debug reports:
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad:
Paul Lussier wrote:
I'm having problems backing up one particular host on my network.
amandad.debug reports:
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad:
In a message dated: Tue, 18 Dec 2001 13:38:58 EST
Yura Pismerov said:
http://amanda.sourceforge.net/cgi-bin/fom?_highlightWords=firewallfile=16
Thanks, except it's not a firewall problem, nor was amcheck reporting
errors.
As I pointed out in a subsequent post/followup, the problem appears
On Fri, 14 Dec 2001 at 4:47pm, Walter Yuan wrote
I have a set up where the backup server is backing up a linux box. the
first backup went fine, however, since then this linux client has been
generating timeout error msgs. I tried to adjust the etimeout on the
*snip*
backup server: rh
Jeremy Wadsack ([EMAIL PROTECTED]):
I am getting consistent timeout errors on a couple hosts. This doesn't
occur when I run amcheck, just during a dump. I'm using tar on all
hosts, so it's not a Linux dump issue. These two hosts are conspicuous
because they are old (so kernel, libraries and
... it fails on /home every time. ...
The index tee cannot write [Broken pipe] message is not necessarily
an error. It is often just a symptom of the dumper (server) side going
away for some reason. For instance, if you ran out of tape.
What else did your E-mail report say?
Ryan Williams
Jean-Louis Martineau [EMAIL PROTECTED] writes:
On Sun, Oct 08, 2000 at 12:25:19PM -0700, Nate Eldredge wrote:
With amanda 2.4.1p1, I am having trouble dumping a large fs with gnu
tar. It's about 30 GB, 400K files, and mounted via NFS (it's on a Netapps
filer). The symptom is
host
On Thu, Nov 02, 2000 at 03:02:19PM +0100, Sven Rudolph wrote:
Jean-Louis Martineau [EMAIL PROTECTED] writes:
On Sun, Oct 08, 2000 at 12:25:19PM -0700, Nate Eldredge wrote:
With amanda 2.4.1p1, I am having trouble dumping a large fs with gnu
tar. It's about 30 GB, 400K files, and
61 matches
Mail list logo
