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
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
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.0GiB,
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
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
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 to
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
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,
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 breaking it into multiple DLE's
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 about the possibility of a successful dump.
As I
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 breaking
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
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=${OPTIONS}
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 giving
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 on
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, which
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
flawlessly 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 the other disks are written properly:
Did
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 the other disks are written properly:
Did this ever got resolved? How?
Since a few days, I'm getting the same
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
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,
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:
$ amcheck -c DailySet1
25 matches
Mail list logo
