Hi, Brian,

(let's keep this thread inside this list, pls, it's easier to follow
things)

on Dienstag, 30. November 2004 at 15:43 you wrote to amanda-users:

>> you mean "holding disk" in AMANDA-terms?

BC> Yes, "holding disk". In more generic terms a "spooling" area for the 
dump/tar'd,
BC> possibly compressed files before they are DD'd to tape. Or, and this happens
BC> periodically, there is some subtletly to the term "spooling" that I've 
missed
BC> or forgetten ? (Which isn't to say the conversation wouldn't be smoother if 
I'd
BC> used to proper jargon in context)

It's Ok, no problem, I just wanted to be sure that we talk about the
same thing and not about any print-spooler or something. You know,
using the same terms helps ;-)

BC> Since there was no holding area and we where running direct to tape it seems
BC> that we where ok for any DLE that was both started and completed to a single
BC> output tape volume.

BC> However a DLE that "didn't fit" on the remaining tape didn't restart the TAR
BC> when the next tape volume was loaded in the drive nor was it completed in 
the
BC> holding area for a retry of the DD.

BC> At least that is what it looks like to me, a not very clearly noted failure.

BC> I'll forward the report to you.

BC> Unfortunately the raid array is occupied by large data sets (the users are
BC> analyzing RNA structures) and there is no knowing in advance how much data
BC> an individual will have nor how much of it has been changed between runs.

AFAI can see from your report this has been the second run of this
configuration as the planner added 13 out of 14 DLEs as "new disk".

So it is very likely that not all of your level 0 backups that have to
be done first for new DLEs will fit on your tapes.

I understand that you can't run this config every day as it seems to
have run for full 3 days this time.

Please show me your amanda.conf also so I can see your tapetype (seems
to be 160000 Mb "long") and dumptypes.

I am not sure right now if your AMANDA-version supports the parameter
"taperalgo" yet, also I am not sure if it helps you when you don't
have any holdingdisk.

>From your second posting I now see that you now have got a
holdingdisk, which will help you A LOT if it is of any reasonable
size. This will buffer things and enable AMANDA to retry things.

Gene wrote (in an off-list reply, as it seems):

>> >samar   /      comp-root
>> 
>> Here is the first biter I think.  Tar runs recursively thru the named 
>> directories, meaning the above line would also include all below, 
>> UNLESS you have added to the comp-root define in your amanda.conf, an 
>> "exclude file=/path/to/somefile" that names ./usr1 and ./user5 on 
>> seperate lines of that file.

And you wrote:

> ya know, I'm not seeing it explicitely but the default is to
> dump via xfsdump

GNUTAR or DUMP?

The first would be able to dump subdirectories, the latter dumps
partitions.

Run "amadmin samar disklist" and have a close look how AMANDA
interprets your whole config.

>From your report it seems to be clear that gnutar is run, but I don't
know if you know and want that.

Gene is right with pointing at the missing exclusion, you also see the
active exclusions in the output of the mentioned command.

BTW, also have a look at your "columnspec"-parameter to pretty up your
reports.

;-)

That much for a start, keep us informed.

-- 
best regards,
Stefan

Stefan G. Weichinger
mailto:monitor AT oops.co DOT at