Hello, Jon,
Montag, 05. Jänner 2004, 18:56 you wrote:
JL> On Mon, Jan 05, 2004 at 05:39:57PM +0100, Stefan G. Weichinger wrote:
>> In the last days I get problems at one client´s site when AMANDA runs
>> into degraded mode. This happens more often right now because of all
JL> Not really degraded mode.
JL> Degraded mode is only when there is no longer enough holding disk to do
JL> the needed level 0's. Then it degrades by only doing incrementals even
JL> for those scheduled for fulls.
You are right on this. Once again :) that´s why I ask my questions
here.
>> I noticed that I try to take /dev/st0 offl instead of /dev/nst0.
>> Does that matter?
JL> ???
I assume this means you agree with me on "This does NOT matter".
It was just some detail I noticed when building up my posting.
>> I assume I should write some small script that removes the "&&" from
>> my crontab.
JL> A state diagram
JL> State # Dump Succeeded Tape Succeeded Return Code
JL> 1 Yes Yes 0 (success)
JL> 2 No No non-zero (failure)
JL> 3 Yes No ???
JL> The && only operates on 2 states, success or failure.
JL> You are expecting state 3 to be considered a failure.
JL> Apparently someone coding amdump considered it more a success than you do.
Yeah, amverify should only be run when amdump successfully dumped TO
TAPE. But amdump seems to give back 0 even when it wrote to the
holdingdisk only. Seems ok from the point of view that amdump ran
through and did not exactly FAIL.
Could not find errorcodes in amdump- and amanda-manpages.
Aside from that I am surprised that amcheck does not notice the
running amdump- and amverify-processes.
JL> Separate topic: I'm putting together a little "dump vs tar" note.
JL> Take a peek, it is pretty short at this point. In thinking about it,
JL> the tar "pro's" are generally mirrored by the dump "con's" and visa versa.
JL> So I've not yet filled in the tar section.
JL> If you get a chance take a peek at the attached doc. Let me know if you
JL> have any other items to add.
Hm, what about these:
GNU tar PROs:
- excluding multiple items using a file/directory-based approach.
- splitting filesystems into DLEs.
- portable. We don´t need the same OS/FS/dump-combination to restore.
- (not really, just for the current implementation):
access to SMB-shares.
(I would like to see a third PROGRAM like : DUMP/GNUTAR/SMBCLIENT)
DUMP CONs:
- is said to be undependable on Linux (according to Linus Torvalds)
which is pretty important news to the many Linux-users.
(question: if dump works on fs-level, how to get a level1-backup?? I
assume I overlook something right now, my head is still somewhat sick
...)
---
Maybe more comes to my head when the cold is gone ... I will let you
know.
I am thinking about writing some good (for sure ...)
AMANDA-SAMBA-HOWTO. Containing stuff like setup, version-issues (the
Samba-3-stuff), excluding things, DLE-styling (like in my request
today), and such. Maybe you have suggestions.
And I fell over the xinetd-entries needed for AMANDA these days. I
think there should be example-files and some lines about that in the
docs/INSTALL-file. Does not look good to force new users into googling
for examples.
---
Pretty much in my ill head ;) I continue coughing and blowing and look
forward to your answer.
---
best regards,
Stefan G. Weichinger
mailto:monitor AT oops.co DOT at
|
