Author: Georg Rehfeld <georg.rehfeld AT gmx DOT de>
Date: Fri, 02 Jan 2004 11:42:05 +0100
Did you try amstatus? It should give the reason. Also look into the amdump.X and log file for that backup near the end, maybe there is diagnostic information neither amreport nor amstatus spit out. S
Did you try amstatus? It should give the reason. Also look into the amdump.X and log file for that backup near the end, maybe there is diagnostic information neither amreport nor amstatus spit out.
Perhaps a dumb question: did you add the amanda server pieces to your inetd.conf file and then restart inetd? "Connection refused" sounds like the amanda server ports aren't open at all. -- Kurt Yode
Author: Georg Rehfeld <georg.rehfeld AT gmx DOT de>
Date: Sat, 03 Jan 2004 11:31:58 +0100
Hi Kurt, John and all others, So the dumper immediately reports 'connection refused' when attempting to connect to the taper process. Wrong permissions? Wrong permissions on what? It's a TCP connecti
Hi Kurt, John and all others, So the dumper immediately reports 'connection refused' when attempting to connect to the taper process. Wrong permissions? Wrong permissions on what? It's a TCP connect
It just occurred to me that maybe this is a side effect of /etc/hosts cache poisoning (courtesy of Red Hat Linux 7.3 NSCD). We've been getting e-mail from a netblock in Vietnam that reverse-resolves
I may be mind-reading her, but I think JLM meant your "amanda" system configuration, not your computer system. Basically, do not use "localhost" as an entry in your amanda config. -- Jon H. LaBadie j
Would upgrading to the current version change this? No, it's a problem with your system configuration, not an amanda bug. Well, I turned off /etc/hosts caching so that should fix the system problem.
Author: Georg Rehfeld <georg.rehfeld AT gmx DOT de>
Date: Wed, 07 Jan 2004 10:38:42 +0100
Hi John and all, It just occurred to me that maybe this is a side effect of /etc/hosts cache poisoning (courtesy of Red Hat Linux 7.3 NSCD). We've been getting e-mail from a netblock in Vietnam that
These dumps were to tape WeeklySet116. The next tape Amanda expects to use is: WeeklySet117. FAILURE AND STRANGE DUMP SUMMARY: mail03 /var/spool/mail lev 0 FAILED [dump to tape failed] mail03 /home l
You are not using any holding disk, is that intentional? Do you mean your /tmp/amanda was empty? Were you looking at those locations on both the server and the client. -- Jon H. LaBadie jon AT jgcomp
You are not using any holding disk, is that intentional? I have two holding disks specified in my config. What are you seeing that makes you conclude that I'm not using any holding disk? I have about
The amreport you posted said something like "error dumping to tape". Dumping, if I understand the message's terminology, means doing the actual backup (tar or dump) and "to tape" meant they were not
Author: Georg Rehfeld <georg.rehfeld AT gmx DOT de>
Date: Wed, 31 Dec 2003 04:17:18 +0100
Dear John, Did you try amstatus? It should give the reason. Also look into the amdump.X and log file for that backup near the end, maybe there is diagnostic information neither amreport nor amstatus
OK, that was the magic incantation. But what would cause a connection failure over the loopback interface? My firewall trusts it and I don't see any dropped packets. Using /var/lib/amanda/WeeklySet1/