|
Re: Amanda 2.5.0 spanning
2008-06-09 11:10:59
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 it. We would shift the schedule forward several hours
just to avoid a 4 hour wait for the next tape. Waiting for 3 days for
it's next tape seems rather extraordinary. A lot can happen on a
computer in 3 days. Especially if it is a busy server. Regardless of
what Amanda might be willing to wait for, ufsdump or gnutar or whatever
might get confused as things change underneath and around it while it
pauses in mid stride for 3 days. Ufsdump's wait period is typically
rather short, and I had to jack it up with command line parameters just
to get 2 hours.
Especially if you are having problems and trying to debug, schedule it
to avoid delays. Once you have it working you can figure out what sort
of delay you can get away with. Of course, I don't want to stop the
developers from taking this head on and trying to make Amanda even more
robust.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogendyk AT bio.umass DOT edu>
---------------
Erdös 4
Johan Booysen wrote:
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:martineau AT zmanda DOT com]
Sent: 09 June 2008 14:37
To: Johan Booysen
Cc: Amanda user's group
Subject: Re: Amanda 2.5.0 spanning
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. 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 anywhere else I can check to see if the job is actively and
running? Or whether the tape drive is actually writing something?
What is strange is that mt -f /dev/nst0 status reports:
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x49 (Quantum SDLT320).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
But I'm sure that while writing it usually comes back with:
/dev/nst0: Device or resource busy
So, alas, I don't think it's doing anything.
Any other suggestions at all?
Thanks.
-----Original Message-----
From: Jean-Louis Martineau [mailto:martineau AT zmanda DOT com]
Sent: 09 June 2008 13:25
To: Johan Booysen
Cc: Amanda user's group
Subject: Re: Amanda 2.5.0 spanning
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 believe then that amanda wrote stuff to tape until 09:43 on Friday
morning, and then filled up the first tape, ejected it, and has been
patiently waiting for the second tape. Or will it have timed out by
now?
So I inserted the second tape this morning, and nothing seems to be
happening at all. It certainly does not appear to be writing
anything
to the second tape...
What's the best way of seeing what amanda's doing now?
I've tried the following:
Amcheck skips the tape check, and tells me that amdump or amflush is
running.
Changer.debug contains lots of these (lots and lots):
-> rewind /dev/nst0
/dev/nst0 rewind failed: Input/output error
-> status /dev/nst0
/dev/nst0 status failed: Input/output error
-> loaded <>
chg-manual check regularly if you put a tape in the drive, if you put
a
valid tape in the driver then it should succeed, are they the latest
lines of the files?
Maybe try another tape.
Jean-Louis
|
|
|
