Hi,
I'm getting an error message from amdump. Amanda is installed on a machine
called marvin. But amdump is saying "all estimate timed out" regarding
directories on marvin itself. The email message from amanda with the error
message is copied below. I tried amcheck:
$ amche
This seems like an obvious "read the FAQ" situation, but . . .
I'm running Amanda 3.3.2 on a Sun T5220 with Solaris 10 and a J4500 "jbod" disk array with multipath
SAS. It all should be fast and is on the local server, so there isn't any network path outside
localhost for the DLE's that are giv
John Heim schrieb:
marvin /var lev 0 FAILED [disk /var, all
estimate timed out]
marvin /etc lev 0 FAILED [disk /etc, all
estimate timed out]
marvin /backup/ulam/current/mail lev 0 FAILED [disk
/backup/ulam/current/mail, all estimate timed
Hi Chris,
Am 03.04.2013 17:26, schrieb Chris Hoogendyk:
This seems like an obvious "read the FAQ" situation, but . . .
I'm running Amanda 3.3.2 on a Sun T5220 with Solaris 10 and a J4500 "jbod" disk
array with multipath
SAS. It all should be fast and is on the local server, so there isn't any
On 4/3/13 12:15 PM, C.Scheeder wrote:
Hi Chris,
Am 03.04.2013 17:26, schrieb Chris Hoogendyk:
This seems like an obvious "read the FAQ" situation, but . . .
I'm running Amanda 3.3.2 on a Sun T5220 with Solaris 10 and a J4500 "jbod" disk
array with multipath
SAS. It all should be fast and is
Chris,
for larger file systems I've moved to "server estimate", less
accurate but takes the entire estimate phase out of the equation.
We have had a lot of success with pig zip rather than regular
gzip, is it'll take advantage of the mutiple CPUs and give
parallelization during compression, whic
For some reason, the headers in the particular message from the list (from Brian) are causing my
mail client or something to completely strip the message so that it is blank when I reply. That is,
I compose a message, it looks good, and I send it. But then I get a blank bcc, brian gets a blank
m
Chris,
sorry for the email trouble, this is a new phenomenon and I
don't know what is causing it, if you can identify the bad
header please let me know. We updated our mailhost a few months
ago, but my MUA (mutt) has not changed nor has my editor (emacs).
My "large" directories are exceptions, e
hose by my mail
client -- Thunderbird 17.0.5.
I changed the dump type to not use compression. If tif files are not going to compress anyway, then
I might as well not even ask Amanda to try. However, it never gets to the dump, because it gets "all
estimate timed out."
I will try breaki
not even ask Amanda to
try. However, it never gets to the dump, because it gets "all estimate
timed out."
I will try breaking it into multiple DLE's and also changing it to
"server estimate". But, until I know what is really causing the
problem, I'm not optimistic
ly a weirdness in
the headers coming from Brian, but it could also be some misbehavior in response to those by my
mail client -- Thunderbird 17.0.5.
I changed the dump type to not use compression. If tif files are not going to compress anyway,
then I might as well not even ask Amanda to try. However, i
On 04/04/2013 02:48 PM, Chris Hoogendyk wrote:
I may just quietly go nuts. I'm trying to run the command directly. In
the debug file, one example is:
Mon Apr 1 08:05:49 2013: thd-32a58: sendsize: Spawning
"/usr/local/libexec/amanda/runtar runtar daily
/usr/local/etc/amanda/tools/gtar --creat
On Thu, Apr 04, 2013 at 17:48:46 -0400, Chris Hoogendyk wrote:
> If I exchange the two commands so that I'm using gtar directly rather
> than runtar, then I get:
>
>/usr/sfw/bin/gtar: Cowardly refusing to create an empty archive
>Try `/usr/sfw/bin/gtar --help' or `/usr/sfw/bin/gtar --usage
On Thu, Apr 04, 2013 at 17:48:46 -0400, Chris Hoogendyk wrote:
> So, I created a script working off that and adding verbose:
>
>#!/bin/ksh
>
>OPTIONS=" --create --file /dev/null --numeric-owner --directory
> /export/herbarium
>--one-file-system --listed-incremental";
>OPTIONS="${
On 04/05/2013 12:09 PM, Chris Hoogendyk wrote:
OK, folks, it is the "--sparse" option that Amanda is putting on the
gtar. This is /usr/sfw/bin/tar version 1.23 on Solaris 10. I have a
test script that runs the runtar and a test directory with just 10 of
the tif files in it.
Without the "--spa
Chris,
I don't know what tif files look like internally, don't know how
they compress.
Just of out left field... does your zpool have compression
enabled? I realized zfs will compress or not on a per block
basis, but I don't know what if any overhead is being incurred,
if the tif files are not c
OK, folks, it is the "--sparse" option that Amanda is putting on the gtar. This is /usr/sfw/bin/tar
version 1.23 on Solaris 10. I have a test script that runs the runtar and a test directory with just
10 of the tif files in it.
Without the "--sparse" option, time tells me that it takes 0m0.57s
Thank you!
Not sure why the debug file would list runtar in the form of a parameter, when it's not to be used
as such. Anyway, that got it working.
Which brings me back to my original problem. As indicated previously, the filesystem in question
only has 2806 files and 140 directories. As I wa
Just to follow up on this. Amanda backups have been running smoothly for a week
now.
For this one DLE, I set up amgtar and disabled the sparse option. It ran, but took most of Saturday
to complete. Then, having a full backup of that, I broke it up into 6 DLE's using excludes and
includes. I ad
On Fri, Apr 12, 2013 at 12:59:39 -0400, Chris Hoogendyk wrote:
> As a followup, in case anyone cares to discuss technicalities and
> examples, has anyone run into this before? It seems any site doing
> lots of sizable scanned images, or GIS systems with tiff maps, would
> have run into it. I don't
Thank you, Nathan. Informative.
The "Total bytes written:" was identical with and without the --sparse option (right down to the
last byte ;-) ). It was the time taken to arrive at that estimate that was so very different:
Total bytes written: 2086440960 (2.0GiB, 11MiB/s)
real3m14.91s
Tot
On Fri, Apr 12, 2013 at 17:09:11 -0400, Chris Hoogendyk wrote:
> The "Total bytes written:" was identical with and without the
> --sparse option (right down to the last byte ;-) ). It was the time
> taken to arrive at that estimate that was so very different:
>
> Total bytes written: 2086440960 (2
Hi all,
I use amanda 2.5.2p1 on a Ubuntu 8.04 server to back up several machines. The
backup of /one/ disk from /one/ machine, which worked flawlessly for years, now
regularly throws the message
FAILURE AND STRANGE DUMP SUMMARY:
srv-erp3 /mnt1 lev 0 FAILED [disk /mnt1, all estimate timed
FAILED [disk /mnt1, all estimate timed out]
planner: ERROR Request to srv-erp3 failed: timeout waiting for REP
in the report, but the other disks are written properly:
srv-erp3 /boot 1 0 0 320.00:00 10.0 0:01 24.8
srv-erp3 /home 0 0 0 160.0
ND STRANGE DUMP SUMMARY:
> srv-erp3 /mnt1 lev 0 FAILED [disk /mnt1, all estimate timed out]
> planner: ERROR Request to srv-erp3 failed: timeout waiting for REP
>
> in the report, but the other disks are written properly:
Did this ever got resolved? How?
Since a few days, I'm g
for
>> years, now regularly throws the message
>>
>> FAILURE AND STRANGE DUMP SUMMARY:
>> srv-erp3 /mnt1 lev 0 FAILED [disk /mnt1, all estimate timed out]
>> planner: ERROR Request to srv-erp3 failed: timeout waiting for REP
>>
>> in the report, but
26 matches
Mail list logo