Hello,
Dumps have worked for 4 months.
The server is:
[amanda@sl501 tmp]$ more /etc/*release
CentOS release 5.7 (Final)
[amanda@sl501 tmp]$
Amanda version: 3.3.0
Suddenly I get this:
NOTES:
planner: Adding new disk node34.rtpnc.epa.gov:/16w.
?
Don
Donald L. (Don) Ritchey
E-mail: [EMAIL PROTECTED]
-Original Message-
From: Jon LaBadie [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 2:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [LONG] Amanda Tru64 V5.1A client sendsize, /sbin/dump fails
On Thu, Feb 13, 2003 at 06:14
On Thu, 13 Feb 2003 at 6:14pm, Sean McGeever wrote
Tru64-client sendsize.debug:
sendsize: debug 1 pid 268247 ruid 203 euid 203 start time Thu Feb 13
17:39:50 2003
/usr/local/libexec/sendsize: version 2.4.2p2
calculating for amname '/', dirname '/'
sendsize: getting size via dump for
On Fri, 14 Feb 2003 at 1:19pm, Sean McGeever wrote
Tru64-client sendsize.debug:
I know nothing of Tru64, but...
sendsize: debug 1 pid 268247 ruid 203 euid 203 start time Thu Feb 13
17:39:50 2003
/usr/local/libexec/sendsize: version 2.4.2p2
calculating for amname '/', dirname '/'
On Fri, Feb 14, 2003 at 09:14:41AM -0500, Joshua Baker-LePain wrote:
On Fri, 14 Feb 2003 at 1:19pm, Sean McGeever wrote
Tru64-client sendsize.debug:
I know nothing of Tru64, but...
[snip]
sendsize: running /sbin/dump 0Ssf 1048576 - /dev/rdisk/dsk0a
At least on Linux, the S flag
Hi,
I've failed to find this precise error condition in either the
amanda or Tru64 archives, so any hints as to solutions would be most welcome.
Sorry for the length of the appended logs, but I hope by including them
I've provided enough data to enable someone to point me in the right
On Thu, Feb 13, 2003 at 06:14:30PM +, Sean McGeever wrote:
Hi,
I've failed to find this precise error condition in either the
amanda or Tru64 archives, so any hints as to solutions would be most welcome.
Sorry for the length of the appended logs, but I hope by including them
I've
Hi Guys,
I am trying to find out why my tapebackup will not work. Amcheck reports
no problems but every dump attempt fails.
I think it has to do with the amanda demon. I send parts of my amdump.1
logfile with it. Anybody any Idea
Thanks in advanc.
Axel
GENERATING SCHEDULE:
DUMP
I think it has to do with the amanda demon. I send parts of my amdump.1
logfile with it. Anybody any Idea
Ummm, yes. It's pretty obvious:
dumper: stream_client: gethostbyname(localhost) failed
Amanda can't do a host name lookup on localhost. You've got something
wrong with the DNS or
Hi,
This pops up every few weeks here on the list, its very simple:
you are backing up an active filesystem with a tool designed primary for
backing up filesystems mounted read-only.
what happens is:
dump first reads in the directory and filepositions on the disk(Pass I and II)
then in pass III
[ On Saturday, December 15, 2001 at 12:40:56 (+0100), Christoph Scheeder wrote: ]
Subject: Re: dump fails with bread and lseek trouble
This pops up every few weeks here on the list, its very simple:
you are backing up an active filesystem with a tool designed primary for
backing up
On Sat, Dec 15, 2001 at 11:10:41AM -0500, Greg A. Woods wrote:
[ On Saturday, December 15, 2001 at 12:40:56 (+0100), Christoph Scheeder wrote: ]
Subject: Re: dump fails with bread and lseek trouble
This pops up every few weeks here on the list, its very simple:
you are backing up
Hi,
Has anyone seen or hear of this problem.
--8--snip*---
/-- geko60.ehb /usr lev 0 FAILED [/sbin/dump returned 3]
sendbackup: start [geko60.ehbas.com:/usr level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/sbin/restore -f... -
sendbackup: info
In a message dated: Fri, 14 Dec 2001 09:29:54 GMT
Thomas Robinson said:
Hi,
Has anyone seen or hear of this problem.
Ayup, I get it all the time. I have no idea what the problem is
though. It seems to come and go sporatically.
I've run e2fsck -c /dev/sda5 to no avail. I also upgraded the
sendsize.x.debug shows that all dumps are failing with:
DUMP: bad sblock magic number
DUMP: The ENTIRE dump is reported
30 Gb partition. Is there a 2 Gb partition size limit? Any idea what might
be causing this?
sendsize.x.debug shows that all dumps are failing with:
DUMP: bad sblock magic number
DUMP: The ENTIRE dump is reported
30 Gb partition. Is there a 2 Gb partition size limit? ...
There may be, but I doubt it is the problem.
Any idea what might be causing this?
It is not pointing
The sendsize.debug on the failing machine does not show a device being
userd. I examined the same file on another machine that is working, and it
shows "DUMP: Dumping /dev/sda1 (/(dir var)) to standard output. The
problem maching is running FreeBSD 4.2 and the agreeable maching is
running Debian
The sendsize.debug on the failing machine does not show a device being
userd. I examined the same file on another machine that is working, and it
shows "DUMP: Dumping /dev/sda1 (/(dir var)) to standard output. ...
So that says Amanda was not able to convert the disklist name it was
given into a
Dumps had been going just fine, but yesterday I installed a CVS
version of amanda to fix a problem with amrecover. Last night, the dumps
from the clients that had the CVS version installed on them failed. I
don't beleive that there is a problem with the CVS code, but rather my
... I
don't beleive that there is a problem with the CVS code, but rather my
installation. I was wondering if anyone can point me in the right
direction. This is the pertinent information from amandad.date.debug
amandad: accept error: access as amanda not allowed from
amanda@Collosys:
On Wed, 21 Mar 2001, John R. Jackson wrote:
... I
don't beleive that there is a problem with the CVS code, but rather my
installation. I was wondering if anyone can point me in the right
direction. This is the pertinent information from amandad.date.debug
amandad: accept error: access as
The chmod changed fixed the error in the amandad log on the clients, but
amcheck is still reporting that client self-checks are timing out. Any
idea what might be causing that? I have checked the logs on the clients,
and they don't show anything obviously wrong
Are you running 2.4.* on both
On Wed, 21 Mar 2001, John R. Jackson wrote:
The chmod changed fixed the error in the amandad log on the clients, but
amcheck is still reporting that client self-checks are timing out. Any
idea what might be causing that? I have checked the logs on the clients,
and they don't show anything
I just ran amcheck with the CVS version installed. No problems now. THanks
a lot for the advice
You had me worried there for a bit that the CVS 2.4.2 branch was no
longer backward compatible. But I just tried a more or less stock 2.4.2
server with CVS 2.4.2 clients and it worked, so something
24 matches
Mail list logo
