On 8/24/2015 11:57 AM, Debra S Baddorf wrote:
On Aug 23, 2015, at 5:45 PM, Seann <[email protected]> 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
