Ok, on Thurday night at 21:00 I kicked off a backup job that should span
over 2 tapes. I wasn't in the office on Friday, but this morning the
first tape was ejected, and amstatus tells me the following:
server:/whatever/clients 0127494663k writing to tape (9:43:32)
I believe then that amanda
Johan Booysen wrote:
Ok, on Thurday night at 21:00 I kicked off a backup job that should span
over 2 tapes. I wasn't in the office on Friday, but this morning the
first tape was ejected, and amstatus tells me the following:
server:/whatever/clients 0127494663k writing to tape (9:43:32)
I
Yes, they are the last lines in changer.debug. Unfortunately no times
or dates are recorded.
I can't really see if the tape drive is writing anything. Usually it
has a little light on it that flickers when there's activity, but now
it's just shining all the time and that's no good.
Is there
Is it adding new lines to changer.debug?
If yes, then something is buggy, try to kill the script: kill 11652
Jean-Louis
Johan Booysen wrote:
Yes, they are the last lines in changer.debug. Unfortunately no times
or dates are recorded.
I can't really see if the tape drive is writing anything.
Hi,
No - it's doing absolutely nothing at all. I did a tail -f on the file
but it hasn't changed since almost an hour ago.
Last timestamp on the file is Jun 6 12:12, anyway.
Oh dear...
:(
-Original Message-
From: Jean-Louis Martineau [mailto:[EMAIL PROTECTED]
Sent: 09 June 2008
Hello Jean-Louis,
Am Mittwoch, den 04.06.2008, 20:07 +0200 schrieb Dominik Schips:
Hello Jean-Louis,
Am Mittwoch, den 04.06.2008, 09:34 -0400 schrieb Jean-Louis Martineau:
A bug in amstatus should not prevent your backup to run correctly.
Changing amdump.1 can't help to start a backup run
Don't know if this will be considered helpful, but . . .
Back when I had to deal with manual tape changing and spanning, we made
a point of scheduling the backups so that the first tape would complete,
and the request for the second would occur, when someone had arrived at
work and could do
Thanks for your reply. I'll have a couple more tries and see if I can figure
things out.
Maybe this time I should use the latest Amanda version as opposed to the latest
Red Hat Amanda version...
I'll let everyone know if I can resolve this, for future reference.
Thanks again.
-Original
Can you send
your whole amflush log, as well as the taper debug log?
Sure. Here is amflush.1, taper.20080609100127.debug follows:
amdump#58; start at Mon Jun 9 10#58;01#58;26 MDT 2008
amdump#58; datestamp 20080609
amdump#58; starttime 20080609100126
amdump#58; starttime-locale
is amflush.1, taper.20080609100127.debug follows:
amdump#58; start at Mon Jun 9 10#58;01#58;26 MDT 2008
amdump#58; datestamp 20080609
amdump#58; starttime 20080609100126
amdump#58; starttime-locale-independent 2008-06-09 10#58;01#58;26 MDT
planner#58; pid 31982 executable /usr/libexec/amanda/planner
Johaan,
I looked back over the postings in this thread but may have
missed the answer to this question. Have you exercised your
chg-manual script with the amtape command? Everything I
see is the result of amdump/amcheck runs which adds a layer
of complexity to seeing if your changer script is
On Sun, Jun 8, 2008 at 11:13 PM, Dustin J. Mitchell [EMAIL PROTECTED] wrote:
This is a result of an error-messaging bug in the 2.6.0. Basically,
config error messages go to stderr, which xinetd routes to the server.
The bug has been fixed in trunk, but on double-checking, it hasn't
been
Once or twice a week my amanda backups are failing when a dumper exits
on signal 6, SIGABRT:
Jun 5 23:27:38 scotch kernel: pid 82566 (dumper), uid 0: exited on signal 6
Jun 8 19:53:43 scotch kernel: pid 96672 (dumper), uid 0: exited on signal 6
In looking at the source there clearly are
Douglas,
Are there any details regarding this issue in the /tmp/amanda debug files for
this dumper?
--Ian
On Monday 09 June 2008 17:11:51 Douglas K. Rand wrote:
Once or twice a week my amanda backups are failing when a dumper exits
on signal 6, SIGABRT:
Jun 5 23:27:38 scotch kernel:
Ian Are there any details regarding this issue in the /tmp/amanda
Ian debug files for this dumper?
Nothing that I saw. Here is the dumper.*.debug file for that pid. I
also uploaded all of the debug files for that run from the server to:
http://meridian-enviro.com/rand/amanda/
dumper: debug 1
Did something bad, but not sure what. I had a tape with a bar code
label but apparently no Amanda label. So I labeled it and hoped the
next backup would write to it. It did not. It was tape #28 and I had
already passed that number in the sequence (Tape #30). So I figured I
did something
16 matches
Mail list logo
