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