On Aug 24, 2015, at 1:49 PM, Seann <nombran...@tsukinokage.net> wrote:
> On 8/24/2015 11:57 AM, Debra S Baddorf wrote: >> On Aug 23, 2015, at 5:45 PM, Seann <nombran...@tsukinokage.net> wrote: >> >>> On 8/19/2015 11:12 PM, Gerrit A. Smit wrote: >>>> Debra S Baddorf schreef op 18-08-15 om 23:21: >>>>> Thank you, Mr Troll, for complaining about our posting techniques (is >>>>> this better?) but >>>>> giving no actual help. >>>> And you think this is appropiate? >>>> >>> With regards to the posting style, as 90% of my clients use a client that >>> top posts (Microsoft exchange, and it's companion client Outlook) I tend to >>> top post, when my response is in top posting. >>> >>> As I use Thunderbird for my main non-professional account (this account) it >>> is a little out of the way, but makes it easier to search and follow when >>> using one of the above mentioned MUA/client pairing. >>> >>> That being said, I have not made much progress on my situation, but I also >>> haven't had the bandwidth to do the deeper digging that is needed. >>> >>> I know the configuration works, per say, as it worked when all the >>> server/client bundles were on the 2.x branch, and that worked for two >>> years, without any changes. >>> >>> I upgraded to CentOs7, migrated the Amanda configurations from the backup >>> disk (original hard drives, now used solely for virtual tapes) and massaged >>> the configuration up to being able to pass the amcheck on the configuration. >>> (This is one of the first place I am looking as it is the most likely place >>> for errors, in the amanda.conf, and disklist configuration files) >>> >>> As all the Amanda logs just stop, on both the client and server, and trying >>> to figure out which server was the last one to check in, or have any >>> activity takes a bit of time, only to see it being identical to a server >>> that completed the backup tasks, makes it hard to troubleshoot. >>> >>> I am looking over the release notes, and documentation to see if there is a >>> way to make it easier to log amanda dump messages, and maybe send them to >>> syslog, so I can run it through something like Graylog, and parse down from >>> there. >>> >>> >>> Regards, >>> Seann >>> >>> >> Have you tried enabling only ONE client, so that you have only one log to >> compare with the server’s log? Or does it work fine with only one client >> - which would imply that no permissions are wong at any rate, and that it is >> more of a timing issue. >> >> For a shor time, you can add these parameters to amanda.conf files. Read >> the web site I reference for info about them, but I think the default value >> is 0 , so setting these things all the way to 5 will give you LOTS more >> debug info and fill up log files quickly. There may be lower numbers you >> can set them to, but why waste time doing intermittent steps, is my >> philosophy. If I am adding debug print lines, I’ll set the value to 5. >> I suggest adding these when you are only trying one client, due to volume >> of data issues (which you are already talking about, if needing help with >> parsing). >> >> #### client type, I think >> #debug_amandad 5 >> #debug_auth 5 >> #debug_event 5 >> #debug_protocol 5 >> #debug_selfcheck 5 >> #debug_sendsize 5 >> #debug_driver 5 >> #debug_amrecover 5 >> #debug-amidxtaped 5 >> #debug-amindexd 5 >> >> ## temp settings, SERVER type >> #debug-auth 5 >> #debug-protocol 5 >> #debug-planner 5 >> #debug-driver 5 >> ##debug-event 5 ## adds LOTS of text, but try it anyway, with caution >> #debug-holding 5 >> #debug-dumper 5 >> #debug-chunker 5 >> #debug-taper 5 >> #debug-recovery 5 >> ### see http://wiki.zmanda.com/man/amanda.conf.5.html >> >> Some of them won’t be activated (like, the recovery ones) but try some or >> all. It can pinpoint exactly WHERE amanda is stopping. >> >> Deb Baddorf >> (going away the end of this week, sorry) >> >> > > Deb, > > I have tried with one client, I have also tried with all clients enabled. > > A Manual run, logged in as the root user, using the command sudo -u > amandabackup amdump DailySet1 works, 100% of the time. > > The only errors for the manual run are 'Strange' errors, related to files > that either have been removed during backup, or files (log files mainly) that > have changed during the tar process. > > I updated my cron tasks last night, to run out of the root cron, under the > amandabackup username, as a test to see if that changes anything. > > I was running top on all of my clients during the manual backup yesterday, > and I saw the sendbackup task, and tar tasks running on the client, and gzip > and taper running on the server, as I would expect. > > Watching the same clients during the nightly cron, didn't show any sendbackup > tasks, nor any tar tasks running on the clients, and no taper process or gzip > task running on the server. > > A quick process check showed the dumpers processes running, and a lot of idle > taper processes, but nothing was running. This was an hour and a half after > the backup started, and the manual run completed after about two and a half > hours. > > It is starting to look a lot like how the cron runs, versus how Amanda is > configured for the backup session. > > Regards, > Seann > > I really suggest turning off all but one client, turning on some of the debug lines above, and run just the cron job. You know it runs manually, so don’t bother with the manual run again. In fact, see if it fails with only one DLE requested from the client, but from a cron job on the server. Heck, if you pick a small DLE, you don’t have to wait for overnight to try it, perhaps? Then READ the log files, on the server and on the one client. One of the two should have something, probably towards the bottom (where things stop happening) that you can report to us. It sounds like the clients are not being asked to perform the backup, only the estimate. If you can find the log files, perhaps the real experts will get back (they seem to be away?? Jean-Louis, etc?) I only run amanda. They’ve *written* it. It’s not uncommon for something to have changed in the config when you make a major version change like you did. We just have to find the right tidbit. You’ve found and fixed much of it, but something is still hiding. (I think) Deb Baddorf
