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:[EMAIL PROTECTED]
