Amanda-Users

Re: Problem with amflush

2004-02-05 07:18:20
Subject: Re: Problem with amflush
From: Christoph Scheeder <christoph.scheeder AT scheeder DOT de>
To: Rohit <rohit AT genetechindia DOT com>
Date: Thu, 05 Feb 2004 13:13:18 +0100
Hi,
i remember i had a simmilar problem about a year ago with amanda.
But i didn't have the time to dig deeper in it, as the customer
got a bit nervous about not getting flushed his archiv-dumps.
So my first try was upgrading amanda to 2.4.4, but that didn't do
the trick.
Then i moved some amanda-files out of the holding disk, and suddenly
it started flushing. Seemd as amada didn't like one of the images in
the holdingdisk.
So i moved these archives back into the holdingarea, tried to flush
again and ... all was flushed fine to tape.
So it looks like there a some strange situations in linux which make
amflush fail with a specific combination of dumps in the holdingdisk.
This problem seems not to be easyly reproduceable, and it seldom
occures.
Christoph

PS: to make a tape reusable use

amrmtape <config> <tapename>

it deletes all references to this tape in the amanda database,
but does not touch the tape itself.
you won't have to relabel it, it will be recognised as a "new tape"
when you insert it.



Rohit schrieb:

As Paul assumed in another branch of this thread, you might have more
than one AMANDA-installation on your machine.

Have you tried several installations and maybe failed to remove one?


No. It was installed via RPM and it one and only amanda installation I
have on that machine.


What does a simple "find / -name amflush -type f" give you?


# find / -name amflush -type f
find: /proc/4059/fd: No such file or directory
find: /proc/10993/fd: No such file or directory
/usr/sbin/amflush
/var/lib/amanda/DailySet1/amflush


If you find more than one amflush, it is very likely that you call
"the wrong one". Maybe it was compiled with different directories and
such.


Looks like not.


Check if the directories contain something useful or if the contain
something that does not belong there. What is the "windows"-dir there?


There is one more non-amanda directory called "windows". I use this
directory to backup windows servers [non amanda backup process - manual]


In a properly configured holdingdisk there should not exist anything
else than files created by amdump.

"There shall not be anything beside me!", if you like it that way ;)


Ok. Can I create one more directory under /backup, set permissions, move
all dumps from /backup into the new directory and run amflush again? Will
that be okay?


Also check permissions and stuff.


Checked that. You can refer to my post in reply to Paul's post. I gave some
details there.


If the s-option of amflush does not work, check your amanda-logdir for
files like amflush.log (I assume it would be called like that as I
currently have no access to my testbox). This file should contain
useful information about what happens and how far the flush gets.


Here are the contents of amflush:

amflush: datestamp 20040205
driver: pid 7545 executable driver version 2.4.3
driver: send-cmd time 0.098 to taper: START-TAPER 20040205
taper: pid 7546 executable taper version 2.4.3
taper: page size is 4096
taper: buffer size is 32768
taper: buffer[00] at 0x400d5000
taper: buffer[01] at 0x400dd000
taper: buffer[02] at 0x400e5000
taper: buffer[03] at 0x400ed000
taper: buffer[04] at 0x400f5000
taper: buffer[05] at 0x400fd000
taper: buffer[06] at 0x40105000
taper: buffer[07] at 0x4010d000
taper: buffer[08] at 0x40115000
taper: buffer[09] at 0x4011d000
taper: buffer[10] at 0x40125000
taper: buffer[11] at 0x4012d000
taper: buffer[12] at 0x40135000
taper: buffer[13] at 0x4013d000
taper: buffer[14] at 0x40145000
taper: buffer[15] at 0x4014d000
taper: buffer[16] at 0x40155000
taper: buffer[17] at 0x4015d000
taper: buffer[18] at 0x40165000
taper: buffer[19] at 0x4016d000
taper: buffer structures at 0x40175000 for 240 bytes
taper: read label `Set-1-08' date `20040108'
taper: wrote label `Set-1-08' date `20040205'
driver: adding holding disk 0 dir /backup size 572408
reserving 572408 out of 572408 for degraded-mode dumps
driver: start time 6317.511 inparallel 4 bandwidth 2000 diskspace 572408 dir
OBSOLETE datestamp 20040205 driver: drain-ends tapeq LFFO big-dumpers ttt
driver: result time 6317.515 from taper: TAPER-OK
driver: state time 6317.515 free kps: 2000 space: 572408 taper: idle
idle-dumpers: 4 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 86400 driver-idle:
not-idle
driver: interface-state time 6317.515 if : free 600 if ETH0: free 400 if
LOCAL: free 1000
driver: hdisk-state time 6317.515 hdisk 0: free 572408 dumpers 0
driver: QUITTING time 6317.533 telling children to quit
driver: send-cmd time 6317.533 to taper: QUIT
taper: DONE [idle wait: 6316.544 secs]
taper: writing end marker. [Set-1-08 OK kb 0 fm 0]
driver: FINISHED time 6340.968



<Prev in Thread] Current Thread [Next in Thread>