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.
driver:
proto
}
Questions for anyone else using Tru64 UNIX?
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 sends
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 Li
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 '/', d
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 vi
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
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 /
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
di
>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 o
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 node1
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
[ 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
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
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 upgrade
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 COMPRESS_S
>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
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 2
>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 pointi
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?
>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
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 anyt
>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 c
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..debug
> >
> >amandad: accept error: acc
>... 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..debug
>
>amandad: accept error: access as amanda not allowed from
>amanda@Collosys: /home/am
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
installation
25 matches
Mail list logo