On Saturday 15 April 2006 13:15, Jon LaBadie wrote:
>On Sat, Apr 15, 2006 at 05:31:39PM +0100, Anne Wilson wrote:
>> On Saturday 15 April 2006 16:49, stan wrote:
>> > On Sat, Apr 15, 2006 at 04:14:29PM +0100, Anne Wilson wrote:
>> > > I have a working amanda, now, but I'm not sure that it is
>> > > optimally set up. I'm backing up from hda to hdb on the same
>> > > host, but splitting into vtapes of 4GB, so that they can be
>> > > burned onto a DVD. That part seems to be working fine.
>> > >
>> > > What I'm not so sure about is that within each vtape I see the
>> > > data split into 10MB chunks, which seems small to me, given the
>> > > amount of data. Is this sensible/desirable? If not, which
>> > > parameter is controlling this?
>> >
>> > I'm pretty certain that is chunksize.
>>
>> I did look at that, but two things convinced me that it isn't.
>> First, the man page says that chunksize is in the 'holding disk'
>> section, and the holding disk is defined as the buffer area, so
>> output wouldn't be in the vtapes. Second, chunksize is actually
>> defined as 1GB, which is also the default.
>>
>> So if it's not that, what else could it be?
>
>Maybe these from the amanda.conf manpage?
>
>tape_splitsize int
>
> Default: none. Split dump file on tape into pieces of a
> specified size. This allows dumps to be spread across
> multiple tapes, and can potentially make more efficient
> use of tape space. Note that if this value is too large
> (more than half the size of the average dump being
> split), substantial tape space can be wasted. If too
> small, large dumps will be split into innumerable tiny
> dumpfiles, adding to restoration complexity. A good
> rule of thumb, usually, is 1/10 of the size of your
> tape.
>
>split_diskbuffer string
> Default: none. When dumping a split dump in PORT-WRITE
> mode (usually meaning "no holding disk"), buffer the
> split chunks to a file in the directory specified by
> this option.
Humm, on analisys, isn't this another way of using a holding disk
without actually calling it that?
>fallback_splitsize int
> Default: 10M. When dumping a split dump in PORT-WRITE
> mode, if no split_diskbuffer is specified (or if we
> somehow fail to use our split_diskbuffer), we must
> buffer split chunks in memory. This specifies the
> maximum size split chunks can be in this scenario, and
> thus the maximum amount of memory consumed for
> in-memory splitting. The size of this buffer can be
> changed from its (very conservative) default to a value
> reflecting the amount of memory that each taper process
> on the dump server may reasonably consume.
So, assuming say 4 spindles in the disklist, and a gig of ram, one could
set this to something in the 100-200 megabyte range? Other ram sizes
accordingly, and also dependent on what else the machine may be doing
ATM?
And is it safe to say that it only applies when the holding disk is not
in use?
In that event, it certainly makes using a holding disk of sufficient
size rather appetizing.
All of which tells the whole world I haven't looked at a manpage for
amanda in 2-3 years, and I need to refresh myself on it, thanks Jon.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
|
