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,
Still getting blank emails on a test reply (just to myself) to Brian's emails. So, I'm replying to
my own email to the list and then pasting in the reply to Brian. It's clearly a weirdness in the
headers coming from Brian, but it could also be some misbehavior in response to those by my mail
Reply using thunderbird rather than mutt.
Any way to vet the zfs file system? Make sure its sane and doesn't
contain some kind of a bad
link causing a loop?
If you where to run the command used by estimate, which I believe
displays in the debug file,
can you run that successfully on the
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 --create --file /dev/null --numeric-owner --directory
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}
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
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
20 matches
Mail list logo
