Hi!
Thanks to Jon for the quick answer.
Jon LaBadie wrote:
Ok. It IS TOO BIG, but now my questions:
.) Why did this dump even got created ?
A 12.1GB dump with a stated tape capacity of 11.7GB.
Not a large difference. The pre-dump estimates are just that,
estimates. Plus the capacity is not an 'absolute' number.
Now, if the estimate had been 24GB, you would have gotten a
message in your report about "way too big". I don't know
what the fudge factor is and where amanda considers it too big.
Thats what confused me. But also amflush tries to put it on tape,
and at this point, the 12GB > 11.7GB comparison is evident!
Furthermore, it does not try to put the smaller dumps resting on
the holding disk, resulting from the follow up amdump at the
night after the desaster ....
Maybe the planner etc. could be made even more clever to
figure out this situation.
.) How do I remove it - I know I have to split this area to
backup it with amanda but I dont want to break the whole system
and start from scatch...
Not certain, but probably 'rm' it and then run amcleanup.
Others may chime in here with alternatives.
Ok. I will move it somewhere else for the first try.
At the moment there is another amflush running which most
probably will not manage to put it on tape .. lets see what happens
if I stop this one.
For the split, you will have to delete the current DLE, or add
some indication to never back it up. The create two or more
new DLE's. The new DLE's will have to get level 0 dumps the
first time amanda encounters them. Perhaps introduce them on
different days.
Of course I did this with several other areas before ... even
this DLE is only part of the real /silo1 ...
.) What about this switching DDSx DAT tapes from compressed to
uncompressed ? Somebody mentioned a script I cant find.
Do you have reason to believe your tapes have already been
written with hardware compression turned on? That is the
time it is needed.
Definitely YES
Look for past-postings by Gene Heskett for the script.
Ok. now I found it - the write som MBs to force buffer flush I missed.
... And there
is no way to stick in command to turn it off after that.
Thats what I was looking for....
.) Why does amanda produce "empty" tapes if a dump is too big ?
It would be nice if the tape would be at least be reused for the
other dumps waiting to get taped ...
Thinking it "might just fit" (only a bit too big) amanda writes
as much as it can, hits the end and fails. Since there is not a
"complete" dump on the tape, that part of the tape is "wasted".
But that's the problem. As it was the only dump to be put on tape,
is obvious now, that this dump will NEVER fit on a tape, so I think
it should be marked to be left out on future runs of amdump or amflush..
Otherwise it keeps blocking amanda writing anything to tape!
And now to something completely different:
Is there any way to execute a command "just before and after" a
"disk" is backuped ? This would be nice to e.g. shut down and start
servers which may change this data inbetween ...
See above comment on crontab.
Not exactly, since there are several DLEs and I would prefer to be
triggered just before and after the single DLE is touched. Furthermore
starting and stopping some servers has to be done on the client side
so being triggered by te amanda client would be easier since the
triggered code is called on the relevant system allready...
Or wrappers. Replace amdump with a script. Or replace the backup
program(s) you use, gnutar or dump, with a script.
If you don't want to turn things off just before dumping,
i.e. not during estimates of during dump of other DLE's,
you can add code to do that too.
if (output device is /dev/null and not the tape device)
this is an estimate, call the backup program itself
else if (this is not a DLE of interest)
call the backup program itself
else
the action, stop the service, call the backup program,
save the return status, start the service, exit with
the saved status
Ok. I think I got it. But does the amanda client honor the PATH
variable in his environment? This would be a way to replace gnutar
with a wrapper - its not acceptable on my systems to replace the
general one since other programs and users need the original ...
... seems to be time for some experiments and research.
Thanks again for the answers,
Peter
WOTLmade
| 