On Friday 04 August 2006 00:43, Gene Heskett wrote:
>Greetings;
>
>2.5.1b1-20060714 running ATM.
>It seemed that I was hearing more disk thrashing than usual, so I took a
>look with htop and found 8 copies of dumper running on this box during
> the estimate phase, which is indeed the limit as set b
Greetings;
2.5.1b1-20060714 running ATM.
It seemed that I was hearing more disk thrashing than usual, so I took a
look with htop and found 8 copies of dumper running on this box during the
estimate phase, which is indeed the limit as set by the 'inparallel'
option, but I also have a maxdumps se
> It looks to work well if I launch the script from bash. But if I try to
> run amcheck, it gives me following error:
>
> ERROR: www-dev: [GNUTAR program not available]
Have you checked amanda debug files (in /tmp/amanda)? It should tell
you what program Amanda is callin GNUTAR.
Did you rebuild
> > Yes, it's the exact same tape drive I've been using extensively for
> > testing, and all that time it had been sitting in the same position on
> > the floor. I moved it on Monday, and then amanda took off like a
> > lightning bolt.
> >
> > Wow, that's something I'll be classing as very weird,
I was wondering if amanda was capable of backing up an older version of
novell. 5.0, 3.12?
Because of a problem with amanda, it can happily overwrite the only
L0 you've got (as happened to me, and documented in a previous thread).
---
AlanP
On 3 Aug 2006, at 17:46, Paul Bijnens wrote:
On 2006-07-28 20:05, C. Chan wrote:
Also Sprach jeffrey d anderson:
On Friday 28 July 2006 10:
On Thu, 3 Aug 2006, Glenn English wrote:
> Geert Uytterhoeven wrote:
> > Indeed. The only way to get my backups working again was downgrading to tar
> > from sarge:
> >
> > apt-get install tar=1.14-2.2
>
> That's exactly what I did 5 minutes after reading Frank Smith's reply.
> That fixed the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Geert Uytterhoeven wrote:
> Indeed. The only way to get my backups working again was downgrading to tar
> from sarge:
>
> apt-get install tar=1.14-2.2
That's exactly what I did 5 minutes after reading Frank Smith's reply.
That fixed the incremen
--On August 3, 2006 9:05:03 AM -0700 "Joe Donner (sent by Nabble.com)"
<[EMAIL PROTECTED]> wrote:
Yes, it's the exact same tape drive I've been using extensively for
testing, and all that time it had been sitting in the same position on
the floor. I moved it on Monday, and then amanda took
On 2006-08-02 04:50, Jon LaBadie wrote:
On Wed, Aug 02, 2006 at 12:36:57AM +0200, Josef Wolf wrote:
On Wed, Jul 26, 2006 at 11:11:41AM -0400, Jon LaBadie wrote:
If talking about amanda's planning, it "shouldn't" happen.
I'm pretty sure that amanda does at most, estimates of three
dump levels;
Olivier Nicole a écrit :
In order to backup a Zope database, I would like to use star with
pre-post processes to stop & restart the server. I've read the doc about
how to use wrapper but i'm still in difficulty.
Jon has already told you all about it. At the end I add some comments
on ba
On 2006-07-28 20:05, C. Chan wrote:
Also Sprach jeffrey d anderson:
On Friday 28 July 2006 10:17, C. Chan wrote:
Related to Mr. Pearson's previous question:
Is there a quick way to determine which DLEs do not have any
Lev 0s on any tapes?
Just coming back from my holidays, I did not follow
On 2006-08-02 23:03, Jeff Portwine wrote:
[...]
Really intriguing problem :-)
I checked the logs:
/usr/local/var/amanda/DailySet1/log/amdump.1:planner:
USE_AMANDAHOSTS CLIENT_LOGIN="backup" FORCE_USERID HAVE_GZIP
You checked here the logs on the server, but you should check the
debug
On Thursday 03 August 2006 08:11, Jeff Portwine wrote:
>On the client the /etc/passwd entry is:
>backup:x:507:509::/home/backup:/bin/bash
>
>-Jeff
Does that 'backup' then belong to a group in the disk or system ranking in
the group file? It should.
>- Original Message -
>From: "Joshua Ba
On 2006-08-03 14:58, Jeff Portwine wrote:
When I checked the debug file, it does show the client_logon=root but I
don't know why.
Aha. Just overlooked it three times, but rereading...
You mean the debug output of amandad on that client does say
"CLIENT_LOGIN=root"?
Just above in the same fi
I solved the problem. It was a problem with the server compile.
Apparently the clock on my backup server was losing time, I will have to
configure ntpd on it. The clock was way behind and there were error
messages related to that in the compile.I fixed that and then recompiled
and insta
Jeff,
Have you set client_username field in the dumptype? Are you using ssh or rsh
as authentication?
Can you provide the output of "amadmin xx version"?
Thanks,
Paddy
On 8/3/06, Jeff Portwine <[EMAIL PROTECTED]> wrote:
> Are you 100% sure that you are looking at the correct files?
> And ther
On Thursday 03 August 2006 08:39, Jeff Portwine wrote:
>Actually I did read the link. In fact I read it when I was first
>installing and configuring Amanda.I read it again when I got your
>response. I missed where it said "make sure you don't buld it as root".
> I generally build everythin
On Thursday 03 August 2006 08:58, Jeff Portwine wrote:
>> Are you 100% sure that you are looking at the correct files?
>> And there is no other "amandad" installed somewhere else, which is
>> invoked instead? Also, someone else with a similar problem had mixed
>> up the hostnames in DNS, resulting
Yes, it's the exact same tape drive I've been using extensively for testing,
and all that time it had been sitting in the same position on the floor. I
moved it on Monday, and then amanda took off like a lightning bolt.
Wow, that's something I'll be classing as very weird, but very good. I was
bis 15.8. bin ich nicht erreichbar. in dringenden fällen senden sie ihre
nachricht bitte an mailto:[EMAIL PROTECTED], vielen dank.
On Thu, Aug 03, 2006 at 08:25:43AM -0700, Joe Donner (sent by Nabble.com) wrote:
>
> Well, I may have "lied" a bit when saying that nothing had changed...
>
> What did change was that I moved the server from temporarily sitting on the
> floor to where it will now stay full-time. So it was a shu
On Thursday 03 August 2006 08:12, Jeff Portwine wrote:
>I believe I was root when I compiled it, but I
>used --with-user=backup --with-group=backup when I ran the ./configure
>script.
>
Doesn't make any diff, the perms are all fubar if built as root.
>
>- Original Message -
>From: "Stefan
Well, I may have "lied" a bit when saying that nothing had changed...
What did change was that I moved the server from temporarily sitting on the
floor to where it will now stay full-time. So it was a shutdown, unplug the
external tape drive and other devices, and then plug them all back in.
A
On 2006-08-02 10:31:43 -0700, Paddy Sreenivasan wrote:
> Can you please clarify what you mean by "nearly-2.5.1". Is it 2.5.1b2
> or 2.5.1b1? There are lots of memory issues fixed using valgrind
> and other tools in 2.5.1b2 release.
>
2.5.1b2 (and CVS HEAD from yesterday morning) exhibit the pr
On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by Nabble.com) wrote:
>
> That was definitely not the case. The holding disk has been empty all this
> time, except on 31 July. And after I ran amflush it was empty again.
>
> What I don't understand is the increase in dump time and tap
Are you 100% sure that you are looking at the correct files?
And there is no other "amandad" installed somewhere else, which is invoked
instead? Also, someone else with a similar problem had mixed
up the hostnames in DNS, resulting in connecting to his test setup
instead. What is in the debug
Actually I did read the link. In fact I read it when I was first
installing and configuring Amanda.I read it again when I got your
response. I missed where it said "make sure you don't buld it as root". I
generally build everything as root, and yes, I know that I may run the make
as a
On 2006-08-02 23:03, Jeff Portwine wrote:
I did the things it suggested there... I checked inetd.conf on the server:
amandaidx stream tcp nowait backup /usr/local/libexec amindexd
amidxtape stream tcp nowait backup /usr/local/libexec amidxtaped
I checked the xinetd.d entry on the client:
service
Jeff Portwine schrieb:
> I believe I was root when I compiled it, but I used --with-user=backup
> --with-group=backup when I ran the ./configure script.
>
> - Original Message - From: "Stefan G. Weichinger" <[EMAIL PROTECTED]>
>> http://www.amanda.org/docs/install.html#id2527059
So you d
I believe I was root when I compiled it, but I
used --with-user=backup --with-group=backup when I ran the ./configure
script.
- Original Message -
From: "Stefan G. Weichinger" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, August 02, 2006 5:09 PM
Subject: Re: amanda config problems
Jef
On the client the /etc/passwd entry is:
backup:x:507:509::/home/backup:/bin/bash
-Jeff
- Original Message -
From: "Joshua Baker-LePain" <[EMAIL PROTECTED]>
To: "Jeff Portwine" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, August 02, 2006 8:18 PM
Subject: Re: amanda config problems
On We
That was definitely not the case. The holding disk has been empty all this
time, except on 31 July. And after I ran amflush it was empty again.
What I don't understand is the increase in dump time and tape time? They
both more than doubled in speed! How is that possible?
Olivier Nicole wrot
> I honestly haven't changed anything. The only thing that happened was that
> I had to run amflush on July 31, because for some reason the amanda-related
> services on the backup server seemed to have hung (but that's an entirely
> different issue).
That si just a wilkd guess, but how about the
Dear all,
Something really strange has happened to my amanda setup. I'm inclined to
feel impressed, but don't know whether this in fact points to something
being wrong.
If you compare run times, dump times, tape times, average dump rate and
average tape write rate for the four different dates b
On Wed, 2 Aug 2006, Frank Smith wrote:
> Glenn English wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > The backup works and verifies, but the report says:
> >
> >> planner: disk zbox.slsware.lan:/usr/bin, estimate of level 2 failed.
> >> planner: disk zbox.slsware.lan:/va
36 matches
Mail list logo