Hi amanda-users,
I have just encountered a problem with amanda-2.4.4p1...
I run: amadmin Daily force-bump basement furnace media
I then run: amdump Daily
Running amstatus Daily prints that it is estimating. It then changes to
"wait for dumping" as each estimate is complete. When all estimates
On Tue, Dec 16, 2003 at 05:51:51PM -0500, Jon LaBadie wrote:
> ** there still are no [gtar] point releases listed from 1.13.25 - 1.13.89 :))
> yet 1.13.90 was followed five weeks later with 1.13.91 and a week
> after that 1.13.92.
I've seen this before. It seems to be a new(ish) conve
Gene,
Thanks, our version of tar here is 1.13. Looking into upgrading
it.
I am currently running amanda-2.4.4p1. I'll check into the
patches available.
I'll post to the group the success/failure of all of this.
At 07:23 PM 12/16/2003, Gene Heskett wrote:
On Tuesday 16 Decem
On Tuesday 16 December 2003 18:07, Ken D'Ambrosio wrote:
>Dan L. Ostrom wrote:
>> I was then able to do an amcheck, and it succeeded. Doing
>> an amdump still
>> fails however. Looking into the log file (sendsize.-.debug) it
>> indicated that
>> amdump is not receiving the size informat
On Tuesday 16 December 2003 17:38, Paul Bijnens wrote:
>[EMAIL PROTECTED] wrote:
>> Question: Is it to be understood that versions of gnutar
>> _greater_ than 1.13.25 are also incompatible? Or is it implied
>> that those are also valid & acceptable for use with Amanda?
>>
>> I ask because I'm see
Hey eveyrone,
Now that I've got a set of tapes running, I'm trying to figure out how to
include another set of tapes. What I would like to do is have an
identical set of tapes same number, same tapecycle, etc., but named
sligtly differently that I can rotate off-site.
For example:
My current se
I'm in a bind, though. Ironically, I don't seem to have a backup copy
of gnutar 1.13.25, so I'm in the process of rebuilding it. But I get
build errors; both GCC and ANSI/C fail with the same file:
GCC:
gmake[2]: Entering directory `/src/gnu/tar-1.13.25/lib'
source='xstrtoimax.c' object='xstrt
[EMAIL PROTECTED] writes:
> That is 10800 seconds for each DLE on that host. If you have 5 DLE's
> on that host, the timeout would become effective after
> 5*10800 seconds.
>
> How many DLE's do have for that host?
Ohhh! I interpreted that to mean that it would wait seconds with
each DLE, no
> In answer to Mark's question, Don't know, yours is the first report
> of using 1.13.9X. You'll have to tell US how it works :))
>
> However, given the rapid release of 1.13.91 and .92, I don't think I'd
> stick with 1.13.90.
Yeah, I think I'll attribute my locked-up DLEs to -gnutar- version .
Dan L. Ostrom wrote:
I was then able to do an amcheck, and it succeeded. Doing an
amdump still
fails however. Looking into the log file (sendsize.-.debug) it
indicated that
amdump is not receiving the size information (presumably from sendsize
module)
that it needs to complete the t
On Tue, Dec 16, 2003 at 01:24:56PM -0500, Gene Heskett wrote:
> On Tuesday 16 December 2003 13:11, [EMAIL PROTECTED] wrote:
> >Jon LaBadie writes:
> >>
> >> ... , is not a suitable version for use with amanda.
> >> It is only 1.13 and what is needed is 1.13.25.
> >
> >Question: Is it to be underst
[EMAIL PROTECTED] wrote:
The fact that it's doing a 'tar -tf -', though, in conjunction with the
errors from amstatus when I finally killed it, indicated that it was
still in the estimate stage:
FAILURE AND STRANGE DUMP SUMMARY:
s3sme /var/opt/ignite/recovery RESULTS MISSING
s3sme
[EMAIL PROTECTED] wrote:
Question: Is it to be understood that versions of gnutar _greater_ than
1.13.25 are also incompatible? Or is it implied that those are also
valid & acceptable for use with Amanda?
I ask because I'm seeing the same problem as is Mr. Kato, only I'm on an
HP-UX server,
[Sorry to keep replying to my own posts, but things keep occurring to me
after I've sent the last one! :-]
> But I'm puzzled as to why, after 15+ hours of working on the
> same DLE, the dump hasn't timed out??
These are the Amanda processes on the client side of a second DLE that
gives the sam
> BTW, etimeout is set to 7200 seconds, which has long since
> elapsed.
Correction -- I meant to say that it's _dtimeout_ that's set to 7200
seconds:
etimeout10800 # 3h estimate timeout per f/s; default
is 300s.
dtimeout7200# 2h amdump time
In fact, when I tried to build 1.13.25 a couple of weeks ago, I kept
hitting a build error:
gmake[2]: Entering directory `/src/gnu/tar-1.13.25/lib'
source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \
depfile='.deps/xstrtoimax.Po' tmpdepfile='.deps/xstrtoimax.TPo' \
depmode=gcc /bin/sh ../dep
On Tuesday 16 December 2003 13:11, [EMAIL PROTECTED] wrote:
>Jon LaBadie writes:
>> On Fri, Nov 14, 2003 at 07:15:07PM +0100, Zoltan Kato wrote:
>> > /home is not NFS mounted and the directories are not transient
>> > (they
>
>are
>
>> > the actual home dirs of individual users). runtar is seduid
>
Jon LaBadie writes:
> On Fri, Nov 14, 2003 at 07:15:07PM +0100, Zoltan Kato wrote:
> > /home is not NFS mounted and the directories are not transient (they
are
> > the actual home dirs of individual users). runtar is seduid root. I
tryed
> > to run the gtar command from the log file manually as r
Hi, Ken D'Ambrosio,
on Montag, 15. Dezember 2003 at 22:56 you wrote to amanda-users:
KDA> Hello, all. I've got some HP/UX 11.11 and 11.00 that I want to back
KDA> up. However, I've run into some problems:
KDA> 1) I can't find an Amanda client to install on 11.11 and 11.00 systems.
KDA> 2) I t
All,
Along
these lines, I too have tried doing an NFS backup using
Amanda, without much luck.
The
*client* machine, is an SANS, so installing client daemons
on it is out of the question.
Doing an
amcheck pointing to the nfs mount point in the conf file
would fail
[EMAIL PROTECTED] wrote:
First backup went fine, but amanda seems to get trouble with the large
filesystems. One of them /var is about
actually /usr from the report below
70 Gig, but only 4% of it about 2.5 GB, are filled with data. What ist
amanda calculating to determine whether a backup fits
Maybe because you are using dump instead of tar,
Amanda tries to dump the entire filesystem instead of content only?
Martin
Hello Amanda-Users, maybe this is a very newby question, but i am running
amanda 2.4.4 to dump several filesystems to a DLT Tape. First backup went fine, but amanda
[EMAIL PROTECTED] wrote:
> Try using GnuTar for your dump program instead. Running 'dump' over
an NFS
> mount if it ever works, is likely to be frought with problems.
Hey, Paul: yah; I'm already using tar instead of dump.
> To compile amanda, you may well need to install a bunch of things
like
Hello Amanda-Users,
maybe this is a very newby question,
but i am running amanda 2.4.4 to dump several filesystems to a DLT Tape.
First backup went fine, but amanda seems
to get trouble with the large filesystems. One of them /var is about
70 Gig, but only 4% of it about 2.5
GB, are filled with d
In a message dated: Mon, 15 Dec 2003 16:56:38 EST
"Ken D'Ambrosio" said:
>Any idea on where I'm going astray?
Ken,
Try using GnuTar for your dump program instead. Running 'dump' over
an NFS mount if it ever works, is likely to be frought with problems.
To compile amanda, you may well need to
25 matches
Mail list logo
