Re: problem with amflush?
The "DUMPS DID NOT COMPLETE" message comes when no FINISH log message (except planner) is seen. If you compare the logfile in the previous emails to your own, successful logfiles, you'll see that line is missing. The most likely cause is a segfault or other bug in the driver. The task, then, is to find it. Andre, can you send along your debug logs for the driver? Also, what version of Amanda are you running on the server? (and as always, my apologies if you've already specified) Dustin -- Storage Software Engineer http://www.zmanda.com
Re: problem with amflush?
Andre Brandt wrote:
> Sure :)
>
> Logfile:
>
> DISK amflush test.mynet /data
> DISK amflush srv1.mynet /data
> DISK amflush srv1.mynet /etc
> DISK amflush srv1.mynet /var
> START amflush date 20080807082315
> START driver date 20080807082315
> STATS driver startup time 0.012
> START taper datestamp 20080807082315 label DailySet1-001 tape 0
> SUCCESS taper test.mynet /data 20080729 1 [sec 6.938 kb 2944 kps 424.3 {wr:
> writers 92 rdwait 0.000 wrwait 0.036 filemark 6.901}]
> SUCCESS taper srv1.mynet /data 20080729 2 [sec 34.533 kb 641856 kps 18586.6
> {wr: writers 20058 rdwait 0.743 wrwait 29.223 filemark 4.506}]
> SUCCESS taper srv1.mynet /var 20080729 2 [sec 27.319 kb 517664 kps 18948.8
> {wr: writers 16177 rdwait 0.691 wrwait 24.682 filemark 1.895}]
> SUCCESS taper srv1.mynet /etc 20080729 1 [sec 1.909 kb 96 kps 50.3 {wr:
> writers 3 rdwait 0.000 wrwait 0.004 filemark 1.905}]
> INFO taper tape DailySet1-001 kb 1162560 fm 4 [OK]
>
>
>
> Report mail:
>
> *** THE DUMPS DID NOT FINISH PROPERLY!
>
> The dumps were flushed to tape DailySet1-001.
> The next tape Amanda expects to use is: DailySet1-002.
>
>
> STATISTICS:
> Total Full Incr.
>
> Estimate Time (hrs:min)0:00
> Run Time (hrs:min) 0:01
> Dump Time (hrs:min)0:00 0:00 0:00
> Output Size (meg) 0.00.00.0
> Original Size (meg) 0.00.00.0
> Avg Compressed Size (%) -- -- --
> Filesystems Dumped0 0 0
> Avg Dump Rate (k/s) -- -- --
>
> Tape Time (hrs:min)0:01 0:00 0:01
> Tape Size (meg) 1135.30.0 1135.3
> Tape Used (%) 0.60.00.6 (level:#disks ...)
> Filesystems Taped 4 0 4 (1:2 2:2)
>
> Chunks Taped 0 0 0
> Avg Tp Write Rate (k/s) 16443.8-- 16443.8
>
> USAGE BY TAPE:
> Label Time Size %NbNc
> DailySet1-001 0:01 1162560k0.6 4 0
>
>
> NOTES:
> taper: tape DailySet1-001 kb 1162560 fm 4 [OK]
>
>
> DUMP SUMMARY:
>DUMPER STATS TAPER STATS
> HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s
> -- - -
> test.mynet /data 1 N/A2944-- N/AN/A0:07 424.3
> srv1.mynet /data 2 1651560 641856 38.9N/AN/A0:35
> 18586.6
> srv1.mynet /etc1 N/A 96-- N/AN/A0:02 50.3
> srv1.mynet /var2 836610 517664 61.9N/AN/A0:27
> 18948.8
>
> (brought to you by Amanda version 2.5.1p1)
>
>
> Any ideas?
>
Any chance you have an incomplete dump image in your holdingdisk?
It may be telling you that all the complete dumps were flushed to
tape, but incomplete ones were not. When that has happened to
me, I've just had amflush offer me those dates to flush, but when
I selected them it would write nothing to tape and tell me the
flush failed. At least in the older versions I have used, parts
of Amanda just check for the existence of subdirectories in your
holdingdisk, while other parts actually check to see if they
contain valid (complete) dumps.
Frank
--
Frank Smith [EMAIL PROTECTED]
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
Re: problem with amflush?
Andre Brandt wrote:
At the moment, I've 3 backups that has been flushed. At all three of
them, amanda show me "*** THE DUMPS DID NOT FINISH PROPERLY!". But all
logfiles seems to be okay:
DISK amflush test.mynet /data
DISK amflush srv1.mynet /data
DISK amflush srv1.mynet /etc
DISK amflush srv1.mynet /var
START amflush date 20080807082315
START driver date 20080807082315
STATS driver startup time 0.012
START taper datestamp 20080807082315 label DailySet1-001 tape 0
SUCCESS taper test.mynet /data 20080729 1 [sec 6.938 kb 2944 kps 424.3
{wr: writers 92 rdwait 0.000 wrwait 0.036 filemark 6.901}]
SUCCESS taper srv1.mynet /data 20080729 2 [sec 34.533 kb 641856 kps
18586.6 {wr: writers 20058 rdwait 0.743 wrwait 29.223 filemark 4.506}]
SUCCESS taper srv1.mynet /var 20080729 2 [sec 27.319 kb 517664 kps
18948.8 {wr: writers 16177 rdwait 0.691 wrwait 24.682 filemark 1.895}]
SUCCESS taper srv1.mynet /etc 20080729 1 [sec 1.909 kb 96 kps 50.3 {wr:
writers 3 rdwait 0.000 wrwait 0.004 filemark 1.905}]
INFO taper tape DailySet1-001 kb 1162560 fm 4 [OK]
Well, I'm confused
Well, I'm somewhat confused too.
When you first posted this, I thought the mail report looked fine. You
weren't doing any dumps, so those statistics in the report showed 0. The
flushes and writes to tape looked like they worked. But then there is
that message at the top in all caps saying the dumps did not finish
properly. hmm.
Do you have the reports from when the dumps were run? Is it possible
that they were incomplete? And that amanda is reporting on that? I
wouldn't think that Amanda would be complaining about dumps not
finishing properly when it wasn't doing any dumps. But it does have
statistics about those dumps that are now being flushed to tape.
If someone on the list who is closer to the code could comment on this,
it might help resolve the confusion. The question is really, Why is that
all caps line about dumps at the top of the mail message? (below)
I typically have autoflush set so that if anything is ever left on the
holding disk it will just go out with the next dump. So I'm not in the
habit of just running amflush by itself.
---
Chris Hoogendyk
-
O__ Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~ - University of Massachusetts, Amherst
<[EMAIL PROTECTED]>
---
Erdös 4
Paul Yeatman schrieb:
Hi, I'm not often running amflush but I would still expect a log file
to be generated in your log directory with more info. How many backups
on holding disk were you expecting this to have been flushing?
Paul
->>In response to your message<<-
--received from Andre Brandt--
Hi List!
I've setup my amanda backup server and everything seems to be fine -
running for some weeks without any problem. (Using amanda 2.5.p1 with a
HP tape library - 8 tapes). Well, because of a mistake - I've done - one
tape was missing an so, amanda wrote all dumps to the holding disk.
(like it should do)
After starting amflush, I got the following email:
*** THE DUMPS DID NOT FINISH PROPERLY!
The dumps were flushed to tape DailySet1-005.
The next tape Amanda expects to use is: DailySet1-001.
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:01
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:01 0:00 0:01
Tape Size (meg) 568.20.0 568.2
Tape Used (%) 0.30.00.3 (level:#disks ...)
Filesystems Taped 4 0 4 (1:2 2:2)
Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) 12663.8-- 12663.8
USAGE BY TAPE:
Label Time Size %NbNc
DailySet1-005 0:01 581888k0.3 4 0
NOTES:
taper: tape DailySet1-005 kb 581888 fm 4 [OK]
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
-
test.mynet /data 1 N/A2944-- N/AN/A0:07 425.6
srv1.mynet /data 2 N/A 97600-- N/AN/A0:11 8652.0
srv1.mynet /etc1 N/A 96-- N/AN/A0:02 50.3
srv1.mynet /var2 N/A 481248-- N/AN/A0:26
18620.1
Re: problem with amflush?
Sure :)
Logfile:
DISK amflush test.mynet /data
DISK amflush srv1.mynet /data
DISK amflush srv1.mynet /etc
DISK amflush srv1.mynet /var
START amflush date 20080807082315
START driver date 20080807082315
STATS driver startup time 0.012
START taper datestamp 20080807082315 label DailySet1-001 tape 0
SUCCESS taper test.mynet /data 20080729 1 [sec 6.938 kb 2944 kps 424.3 {wr:
writers 92 rdwait 0.000 wrwait 0.036 filemark 6.901}]
SUCCESS taper srv1.mynet /data 20080729 2 [sec 34.533 kb 641856 kps 18586.6
{wr: writers 20058 rdwait 0.743 wrwait 29.223 filemark 4.506}]
SUCCESS taper srv1.mynet /var 20080729 2 [sec 27.319 kb 517664 kps 18948.8 {wr:
writers 16177 rdwait 0.691 wrwait 24.682 filemark 1.895}]
SUCCESS taper srv1.mynet /etc 20080729 1 [sec 1.909 kb 96 kps 50.3 {wr:
writers 3 rdwait 0.000 wrwait 0.004 filemark 1.905}]
INFO taper tape DailySet1-001 kb 1162560 fm 4 [OK]
Report mail:
*** THE DUMPS DID NOT FINISH PROPERLY!
The dumps were flushed to tape DailySet1-001.
The next tape Amanda expects to use is: DailySet1-002.
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:01
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:01 0:00 0:01
Tape Size (meg) 1135.30.0 1135.3
Tape Used (%) 0.60.00.6 (level:#disks ...)
Filesystems Taped 4 0 4 (1:2 2:2)
Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) 16443.8-- 16443.8
USAGE BY TAPE:
Label Time Size %NbNc
DailySet1-001 0:01 1162560k0.6 4 0
NOTES:
taper: tape DailySet1-001 kb 1162560 fm 4 [OK]
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s
-- - -
test.mynet /data 1 N/A2944-- N/AN/A0:07 424.3
srv1.mynet /data 2 1651560 641856 38.9N/AN/A0:35 18586.6
srv1.mynet /etc1 N/A 96-- N/AN/A0:02 50.3
srv1.mynet /var2 836610 517664 61.9N/AN/A0:27 18948.8
(brought to you by Amanda version 2.5.1p1)
Any ideas?
Re: problem with amflush?
Andre Brandt schrieb:
At the moment, I've 3 backups that has been flushed. At all three of
them, amanda show me "*** THE DUMPS DID NOT FINISH PROPERLY!". But all
logfiles seems to be okay:
DISK amflush test.mynet /data
DISK amflush srv1.mynet /data
DISK amflush srv1.mynet /etc
DISK amflush srv1.mynet /var
START amflush date 20080807082315
START driver date 20080807082315
STATS driver startup time 0.012
START taper datestamp 20080807082315 label DailySet1-001 tape 0
SUCCESS taper test.mynet /data 20080729 1 [sec 6.938 kb 2944 kps 424.3
{wr: writers 92 rdwait 0.000 wrwait 0.036 filemark 6.901}]
SUCCESS taper srv1.mynet /data 20080729 2 [sec 34.533 kb 641856 kps
18586.6 {wr: writers 20058 rdwait 0.743 wrwait 29.223 filemark 4.506}]
SUCCESS taper srv1.mynet /var 20080729 2 [sec 27.319 kb 517664 kps
18948.8 {wr: writers 16177 rdwait 0.691 wrwait 24.682 filemark 1.895}]
SUCCESS taper srv1.mynet /etc 20080729 1 [sec 1.909 kb 96 kps 50.3 {wr:
writers 3 rdwait 0.000 wrwait 0.004 filemark 1.905}]
INFO taper tape DailySet1-001 kb 1162560 fm 4 [OK]
Well, I'm confused
Show us the report mail as well.
Stefan
Re: problem with amflush?
At the moment, I've 3 backups that has been flushed. At all three of
them, amanda show me "*** THE DUMPS DID NOT FINISH PROPERLY!". But all
logfiles seems to be okay:
DISK amflush test.mynet /data
DISK amflush srv1.mynet /data
DISK amflush srv1.mynet /etc
DISK amflush srv1.mynet /var
START amflush date 20080807082315
START driver date 20080807082315
STATS driver startup time 0.012
START taper datestamp 20080807082315 label DailySet1-001 tape 0
SUCCESS taper test.mynet /data 20080729 1 [sec 6.938 kb 2944 kps 424.3
{wr: writers 92 rdwait 0.000 wrwait 0.036 filemark 6.901}]
SUCCESS taper srv1.mynet /data 20080729 2 [sec 34.533 kb 641856 kps
18586.6 {wr: writers 20058 rdwait 0.743 wrwait 29.223 filemark 4.506}]
SUCCESS taper srv1.mynet /var 20080729 2 [sec 27.319 kb 517664 kps
18948.8 {wr: writers 16177 rdwait 0.691 wrwait 24.682 filemark 1.895}]
SUCCESS taper srv1.mynet /etc 20080729 1 [sec 1.909 kb 96 kps 50.3 {wr:
writers 3 rdwait 0.000 wrwait 0.004 filemark 1.905}]
INFO taper tape DailySet1-001 kb 1162560 fm 4 [OK]
Well, I'm confused
Andre
Paul Yeatman schrieb:
> Hi, I'm not often running amflush but I would still expect a log file
> to be generated in your log directory with more info. How many backups
> on holding disk were you expecting this to have been flushing?
>
> Paul
>
> ->>In response to your message<<-
> --received from Andre Brandt--
> >
> > Hi List!
> >
> > I've setup my amanda backup server and everything seems to be fine -
> > running for some weeks without any problem. (Using amanda 2.5.p1 with a
> > HP tape library - 8 tapes). Well, because of a mistake - I've done - one
> > tape was missing an so, amanda wrote all dumps to the holding disk.
> > (like it should do)
> >
> > After starting amflush, I got the following email:
> >
> > *** THE DUMPS DID NOT FINISH PROPERLY!
> >
> > The dumps were flushed to tape DailySet1-005.
> > The next tape Amanda expects to use is: DailySet1-001.
> >
> >
> > STATISTICS:
> > Total Full Incr.
> >
> > Estimate Time (hrs:min)0:00
> > Run Time (hrs:min) 0:01
> > Dump Time (hrs:min)0:00 0:00 0:00
> > Output Size (meg) 0.00.00.0
> > Original Size (meg) 0.00.00.0
> > Avg Compressed Size (%) -- -- --
> > Filesystems Dumped0 0 0
> > Avg Dump Rate (k/s) -- -- --
> >
> > Tape Time (hrs:min)0:01 0:00 0:01
> > Tape Size (meg) 568.20.0 568.2
> > Tape Used (%) 0.30.00.3 (level:#disks
> > ...)
> > Filesystems Taped 4 0 4 (1:2 2:2)
> >
> > Chunks Taped 0 0 0
> > Avg Tp Write Rate (k/s) 12663.8-- 12663.8
> >
> > USAGE BY TAPE:
> > Label Time Size %NbNc
> > DailySet1-005 0:01 581888k0.3 4 0
> >
> > NOTES:
> > taper: tape DailySet1-005 kb 581888 fm 4 [OK]
> >
> >
> > DUMP SUMMARY:
> >DUMPER STATS TAPER
> > STATS
> > HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS
> > KB/s
> > -- -
> > -
> > test.mynet /data 1 N/A2944-- N/AN/A0:07
> > 425.6
> > srv1.mynet /data 2 N/A 97600-- N/AN/A0:11
> > 8652.0
> > srv1.mynet /etc1 N/A 96-- N/AN/A0:02
> > 50.3
> > srv1.mynet /var2 N/A 481248-- N/AN/A0:26
> > 18620.1
> >
> > (brought to you by Amanda version 2.5.1p1)
> >
> >
> > Well, what is wrong? I don't understand, what amanda want's to tell me :(
> >
> > Thx!
> >
> > Andre
> >
> >
> >
>
>
Re: problem with amflush?
Hi, I'm not often running amflush but I would still expect a log file to be generated in your log directory with more info. How many backups on holding disk were you expecting this to have been flushing? Paul ->>In response to your message<<- --received from Andre Brandt-- > > Hi List! > > I've setup my amanda backup server and everything seems to be fine - > running for some weeks without any problem. (Using amanda 2.5.p1 with a > HP tape library - 8 tapes). Well, because of a mistake - I've done - one > tape was missing an so, amanda wrote all dumps to the holding disk. > (like it should do) > > After starting amflush, I got the following email: > > *** THE DUMPS DID NOT FINISH PROPERLY! > > The dumps were flushed to tape DailySet1-005. > The next tape Amanda expects to use is: DailySet1-001. > > > STATISTICS: > Total Full Incr. > > Estimate Time (hrs:min)0:00 > Run Time (hrs:min) 0:01 > Dump Time (hrs:min)0:00 0:00 0:00 > Output Size (meg) 0.00.00.0 > Original Size (meg) 0.00.00.0 > Avg Compressed Size (%) -- -- -- > Filesystems Dumped0 0 0 > Avg Dump Rate (k/s) -- -- -- > > Tape Time (hrs:min)0:01 0:00 0:01 > Tape Size (meg) 568.20.0 568.2 > Tape Used (%) 0.30.00.3 (level:#disks ...) > Filesystems Taped 4 0 4 (1:2 2:2) > > Chunks Taped 0 0 0 > Avg Tp Write Rate (k/s) 12663.8-- 12663.8 > > USAGE BY TAPE: > Label Time Size %NbNc > DailySet1-005 0:01 581888k0.3 4 0 > > NOTES: > taper: tape DailySet1-005 kb 581888 fm 4 [OK] > > > DUMP SUMMARY: >DUMPER STATS TAPER > STATS > HOSTNAME DISKL ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS > KB/s > -- - > - > test.mynet /data 1 N/A2944-- N/AN/A0:07 > 425.6 > srv1.mynet /data 2 N/A 97600-- N/AN/A0:11 > 8652.0 > srv1.mynet /etc1 N/A 96-- N/AN/A0:02 > 50.3 > srv1.mynet /var2 N/A 481248-- N/AN/A0:26 > 18620.1 > > (brought to you by Amanda version 2.5.1p1) > > > Well, what is wrong? I don't understand, what amanda want's to tell me :( > > Thx! > > Andre > > > -- Paul Yeatman (858) 534-9896[EMAIL PROTECTED] == ==Proudly brought to you by Mutt== ==
Re: Problem with amflush
Hi, Paul Bijnens, on Montag, 09. Februar 2004 at 13:56 you wrote to amanda-users: PB> Rohit wrote: >>>And, more generally: Should amcheck complain about that? >> >> Yes, I think it should with appropriate message. PB> If you don't put cruft in the amanda holdingdisk directory, PB> then there is no problem. (It did complain about the cruft, PB> didn't it?) It stalled because of the permissions on the cruft. And it complained about the cruft, not the permissions, which is fine. Looking at it from the improve-the-docs-angle I suggest adding some lines to the docs/INSTALL-file (which seems to be a common start-point for new AMANDA-users) that recommend to do the following: - create a unique dir for each config's holdingdisk, so that the files for multiple configs don't get mixed up. e.g. /amanda_hold/ /amanda_hold/ - give the holdingdisk to the AMANDA-user - chown -R /amanda_hold - chgrp -R /amanda_hold - chmod -R 660 /amanda_hold (or any other permission you like/need/want, just make sure has r/w-access). - leave the holdingdisk to AMANDA alone. Nothing else should go in there. If AMANDA complains about cruft, go and have a look. (Re)move it. Cruft can lead to strange behavior of amflush, for example. -- The docs/INSTALL-file does not contain any tips on creating holdingdisks. Maybe it should. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
Rohit wrote: And, more generally: Should amcheck complain about that? Yes, I think it should with appropriate message. If you don't put cruft in the amanda holdingdisk directory, then there is no problem. (It did complain about the cruft, didn't it?) -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Problem with amflush
> Rohit, I don't remember that exactly: > > Didn't amcheck complain about that? No, it didn't > And, more generally: Should amcheck complain about that? Yes, I think it should with appropriate message. Thanks! Rohit
Re: Problem with amflush
Hi, Rohit, on Montag, 09. Februar 2004 at 11:39 you wrote to amanda-users: R> Finally caught the culprit: R> 1) Changed group permissions for backup directory to 'disk' R> 2) Changed permissions for 'windows' directory to 'amanda.disk' R> Now amflush runs fine. R> Thanks a lot group for assisting me in finding solution to this problem! All this reminds me of some episode of "Two stupid dogs". There was this big family and after each small incident the mother asked the children: "So what have we learned?". I am a bit ashamed to not have seen this permission-problem ... In my recent AMANDA-installations I developed the behavior of doing chown -R amanda chgrp -R disk (assuming the use of the group disk) Rohit, I don't remember that exactly: Didn't amcheck complain about that? And, more generally: Should amcheck complain about that? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
> # pwd > / > > # ls -l > drwxrwxr-x 10 amanda root 4096 Feb 5 00:30 backup > > # cd backup/ > # pwd > /backup > > # ls -l > drwxrwx---4 root root 4096 Oct 23 12:26 windows > > > PS. to avoid complaints about cruft concerning the lost+found > > directory, make a subdir on that disk (/disk/amandahold/TheConfig) > > and specify that subdir as holdingdisk directory in amanda.conf. > Finally caught the culprit: 1) Changed group permissions for backup directory to 'disk' 2) Changed permissions for 'windows' directory to 'amanda.disk' Now amflush runs fine. Thanks a lot group for assisting me in finding solution to this problem! Rohit
Re: Problem with amflush
Hi, Christoph, on Donnerstag, 05. Februar 2004 at 13:13 you wrote to amanda-users: CS> Hi, CS> i remember i had a simmilar problem about a year ago with amanda. CS> But i didn't have the time to dig deeper in it, as the customer CS> got a bit nervous about not getting flushed his archiv-dumps. CS> So my first try was upgrading amanda to 2.4.4, but that didn't do CS> the trick. CS> Then i moved some amanda-files out of the holding disk, and suddenly CS> it started flushing. Seemd as amada didn't like one of the images in CS> the holdingdisk. CS> So i moved these archives back into the holdingarea, tried to flush CS> again and ... all was flushed fine to tape. CS> So it looks like there a some strange situations in linux which make CS> amflush fail with a specific combination of dumps in the holdingdisk. CS> This problem seems not to be easyly reproduceable, and it seldom CS> occures. Interesting to hear that. I am pretty curious to know what is the problem here. After your mail I would try to move a holdingdisk-dump-dir and see what happens if I was in Rohit's situation. thank you. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
Rohit wrote: No core dump was generated. Maybe because the default "ulimit" for core files is 0 (do not generate core files. (try "ulimit -c" in bash) When a program does something illegal, unix dumps it's memory into a file, for the programmers to do some postmortem analysis on the problem. The core file is generated in the current working directory. For amanda that could be: the directory where you started the amflush, or /tmp/amanda, or ~amanda/TheConfig directory (where the amflush.1 file is). I'm not sure which one of the three it is. Try: strace -p pid-of-the-process "strace" (as root or as amanda), shows you the live system calls a program calling. A strong indication of what is is doing (sleep? reading disk? waiting for input on the tty?). (for amflush and driver) Which one is taking CPU? I guess amflush. amflush So I would like to have a core file of amflush. We can force a crash and core dump of a program by sending it signal number 3. First we have to enable the maximum size of a core dump (in this session only, and all the children started by this session). We do this by using the bash builtin command below. Try to examine a core file to find out what it was doing: $ ulimit -c unlimited Then we start amflush as usual. $ amflush Your description of the problem indicates it is now sitting there, doing nothing useful, but taking cpu. So now we force a core dump: and in another window, as amanda or root: $ kill -3 pid-of-amflush and then, cd to where the core file is found (current directory, or /tmp/amanda or ~amanda/TheConfig, I'm not sure), and get a stacktrace: If we have found the core dump (a file with the name "core" in one of those three directories), you can verify if it is indeed a core file of the right program: $ file core core: ELF 32-bit LSB core file of 'amflush' (signal 3), Intel 80386... And then we take the debugger, and have a look in which function the program was, when the hammer hit it. $ gdb /usr/sbin/amflush core gdb> bt I'm not very clear on what you are asking me to do. Can you please elaborate? Here is a typescript: $ ulimit -c unlimited $ ls -l core ls: core: No such file or directory $ sleep 60 & [1] 29644 # We have 60 seconds time to kill that process, the '&' puts it # in the background and bash tells us the pid too # For amflush you'll have to open a different window, and find # the pid by "ps -ef". $ ps -fp 29644 UIDPID PPID C STIME TTY TIME CMD paul 29644 29201 0 16:46 pts/13 00:00:00 sleep 60 $ kill -3 29644 # hit enter here one more time to synchronise the msg: [1]+ Quit(core dumped) sleep 60 $ ls -l core -rw---1 paulnuts90112 Feb 5 16:46 core $ file core core: ELF 32-bit LSB core file of 'sleep' (signal 3), Intel 80386... $ gdb /usr/bin/sleep core GNU gdb 5.2 Copyright 2002 Free Software Foundation, Inc. ... Core was generated by `sleep 60'. Program terminated with signal 3, Quit. ... #0 0x400c75d1 in __libc_nanosleep () at __libc_nanosleep:-1 -1__libc_nanosleep: No such file or directory. in __libc_nanosleep (gdb) # It was in the function nanosleep, and get a backtrace: (gdb) bt #0 0x400c75d1 in __libc_nanosleep () at __libc_nanosleep:-1 #1 0x400c7568 in __sleep (seconds=60) at [...]/linux/sleep.c:85 #2 0x08048972 in error () at error.c:227 #3 0x4003d17d in __libc_start_main (main=0x8048868 , argc=2, ubp_av=0xb694, init=0x8048584, fini=0x8048bfc , rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xb68c) at ../sysdeps/generic/libc-start.c:129 (gdb) quit And if we had the source, we have maybe a clue what was going on (satisfaction *not* garanteed, but for open source software, you do have access to the source!). -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Problem with amflush
> You'll have to find out why there is no schedule generated. > The schedule is generated by "amflush" and piped into "driver". > Is there a core dump in /tmp/amanda or in ~/amanda/TheConfig ? > Can you find out if they are running? And what it's doing? No core dump was generated. > Try: strace -p pid-of-the-process > > (for amflush and driver) > Which one is taking CPU? I guess amflush. amflush > Try to examine a core file to find out what it was doing: >$ ulimit -c unlimited >$ amflush > and in another window, as amanda or root: > >$ kill -3 pid-of-amflush > > and then, cd to where the core file is found (current directory, > or /tmp/amanda or ~amanda/TheConfig, I'm not sure), and > get a stacktrace: > >$ gdb /usr/sbin/amflush core >gdb> bt I'm not very clear on what you are asking me to do. Can you please elaborate? Thanks! Rohit
Re: Problem with amflush
On Thursday 05 February 2004 00:59, Rohit wrote: >> OK, please take that to the next logical step. >> >> Amanda is telling you you have "cruft directories" as well >> as "apparently good amanda directories". Is there anything >> in those directories? Perhaps your apparently good directories >> also contain "cruft", and only cruft *** . >> >> At the end of an amdump run amanda tries to remove the directory >> it was using. It "should" have already removed all files from >> those directories so a basic "rmdir" type remove should work. >> But if any "cruft" is left behind, the "rmdir" action will not >> remove the directory and it will "look like" there is still >> something needing flushing. > >I just checked all the directories begining with 2004* in the > holding disk and yes all of them have amanda backup dumps in them. > >There is one more non amanda directory called "windows". I use this >directory to backup windows servers [non amanda backup process - > manual] > >Thanks! I *think* that would be considered a cruft directory by amanda. Amanda expects to have total control over its holding disk area, so I think I'd move that one out off amanda's playpen. That might solve your problems, given enough flush time and tapes. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: Problem with amflush
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 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
Re: Problem with amflush
Rohit wrote: 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? No, unless you don't have any chunked files. The header of contination chunk file in holdingdisk contains an abolute pathname (that way amanda could place chunks of one backup over different holdingdisks). 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[19] at 0x4016d000 taper: buffer structures at 0x40175000 for 240 bytes Somewhere around these lines, I would expect the instructions like FLUSH host /d/l/e 20040204 /holding/disk/20040204/host._d_l_e.0 These are missing... And of course, nothing happens. 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 Then it sits idle, still waiting for the above instructions... And almost 2 hours gives up: driver: start time 6317.511 inparallel 4 bandwidth 2000 diskspace 572408 dir ... You'll have to find out why there is no schedule generated. The schedule is generated by "amflush" and piped into "driver". Is there a core dump in /tmp/amanda or in ~/amanda/TheConfig ? Can you find out if they are running? And what it's doing? Try: strace -p pid-of-the-process (for amflush and driver) Which one is taking CPU? I guess amflush. Try to examine a core file to find out what it was doing: $ ulimit -c unlimited $ amflush and in another window, as amanda or root: $ kill -3 pid-of-amflush and then, cd to where the core file is found (current directory, or /tmp/amanda or ~amanda/TheConfig, I'm not sure), and get a stacktrace: $ gdb /usr/sbin/amflush core gdb> bt And send me this output. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Problem with amflush
> R> Ok. Can I create one more directory under /backup, set permissions, move > R> all dumps from /backup into the new directory and run amflush again? Will > R> that be okay? > > Yes, this should work. I did this, created another directory under /backup called "amanda_hold" and inside it one more directory called "DailySet1". I moved all amanda stuff from /backup to /backup/amanda_hold/DailySet1 directory. I then changed directory permissions [for the new directories which I have created and also windows directory] to amanda.disk. But still amflush does not work. Here is the output of amflush -f $ /usr/sbin/amflush -f DailySet1 Scanning /backup/amanda_hold/DailySet1... 20031230: found Amanda directory. 20040130: found Amanda directory. 20040131: found Amanda directory. 20040201: found Amanda directory. 20040203: found Amanda directory. 20040205: found Amanda directory. Multiple Amanda directories, please pick one by letter: A. 20031230 B. 20040130 C. 20040131 D. 20040201 E. 20040203 F. 20040205 Select directories to flush [A..F]: [ALL] BCDEF Today is: 20040205 Flushing dumps in 20040130, 20040131, 20040201, 20040203, 20040205 to tape drive "/dev/nst0". Expecting tape Set-1-10 or a new tape. (The last dumps were to tape Set-1-09) Are you sure you want to do this [yN]? y amflush: datestamp 20040205 driver: pid 26065 executable driver version 2.4.3 driver: send-cmd time 0.208 to taper: START-TAPER 20040205 driver: adding holding disk 0 dir /backup/amanda_hold/DailySet1 size 572400 reserving 572400 out of 572400 for degraded-mode dumps taper: pid 26067 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-09' date `20040205' Since I ran amflush so many times now, I put the same tape which ran with amflush about an hour ago. How do I force amanda to use the tape which I put in the drive? I know nothing was written to the tape, but amanda still thinks that it wrote something to the tape and it asks for the new tape when I run amflush again.
Re: Problem with amflush
Hi, Rohit, on Donnerstag, 05. Februar 2004 at 08:09 you wrote to amanda-users: >> 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? R> No. It was installed via RPM and it one and only amanda installation I R> have on that machine. Ok. >> What does a simple "find / -name amflush -type f" give you? R> # find / -name amflush -type f R> find: /proc/4059/fd: No such file or directory R> find: /proc/10993/fd: No such file or directory R> /usr/sbin/amflush R> /var/lib/amanda/DailySet1/amflush Seems fine to me. R> Ok. Can I create one more directory under /backup, set permissions, move R> all dumps from /backup into the new directory and run amflush again? Will R> that be okay? Yes, this should work. >> Also check permissions and stuff. R> Checked that. You can refer to my post in reply to Paul's post. I gave some R> details there. Try and chown that windows directory to amanda or at least "chgrp disk" it. Right now amanda can't do anything in there, and we should eliminate the possibility of that being the problem. How is your holdingdisk defined? /backup? Then amanda could fall over the cruft in form of /backup/windows being non-readable. Mv the contents to maybe /backup/amanda_hold/ and set your holdingdisk to that. SO you my add another -subdir later for another amanda-conf and the files won't get confused. >> 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. R> Here are the contents of amflush: R> amflush: datestamp 20040205 R> driver: pid 7545 executable driver version 2.4.3 R> driver: send-cmd time 0.098 to taper: START-TAPER 20040205 ... R> taper: DONE [idle wait: 6316.544 secs] Hm, this all looks pretty fine. I can only compare it to my tes-install right now which uses chg-disk and has nothing to flush right now. Please try to chown/chgrp that windows-dir or mv it out of the way. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
> 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
Re: Problem with amflush
> Well, that's strange! Why does amflush need to to do an estimate??? > My 28 Gbyte flush on monday morning takes 0:00 estimate time. > There isn't even an estimate phase when doing amflush (skimmed quickly > in the source, correct me if I missed it.) Strange for me too! > Are you sure you execute the correct amflush command? Some people > have many versions (the system supplied one, maybe version 2.4.1 > in /usr/sbin, some other version in /usr/local/sbin, and/or a > self compiled in ~amanda/sbin ... # rpm -qa | grep "amanda" amanda-client-2.4.3-4 amanda-server-2.4.3-4 amanda-2.4.3-4 # locate amflush /usr/sbin/amflush /usr/share/man/man8/amflush.8.gz /var/lib/amanda/DailySet1/amflush.2 /var/lib/amanda/DailySet1/amflush.1 /var/lib/amanda/DailySet1/amflush.3 /var/lib/amanda/DailySet1/amflush.6 and so on till amflush.24 /var/lib/amanda/DailySet1/amflush.log.20040204 > Just checking... your holdingdisk and it's subdirectories > are local disks AND are owned by amanda? And you do run > amdump and amflush as user amanda? # pwd / # ls -l drwxrwxr-x 10 amanda root 4096 Feb 5 00:30 backup # cd backup/ # pwd /backup # ls -l total 44 drwxrwxr-x2 amanda disk 4096 Dec 30 01:12 20031230 drwx--2 amanda disk 4096 Jan 30 01:25 20040130 drwx--2 amanda disk 4096 Jan 31 01:25 20040131 drwx--2 amanda disk 4096 Feb 1 01:24 20040201 drwx--2 amanda disk 4096 Feb 3 01:30 20040203 drwx--2 amanda disk 4096 Feb 5 01:51 20040205 drwxrwxr-x2 amanda root16384 Sep 27 15:28 lost+found drwxrwx---4 root root 4096 Oct 23 12:26 windows > PS. to avoid complaints about cruft concerning the lost+found > directory, make a subdir on that disk (/disk/amandahold/TheConfig) > and specify that subdir as holdingdisk directory in amanda.conf. Sure, I can do that.
Re: Problem with amflush
> OK, please take that to the next logical step. > > Amanda is telling you you have "cruft directories" as well > as "apparently good amanda directories". Is there anything > in those directories? Perhaps your apparently good directories > also contain "cruft", and only cruft *** . > > At the end of an amdump run amanda tries to remove the directory > it was using. It "should" have already removed all files from > those directories so a basic "rmdir" type remove should work. > But if any "cruft" is left behind, the "rmdir" action will not > remove the directory and it will "look like" there is still > something needing flushing. I just checked all the directories begining with 2004* in the holding disk and yes all of them have amanda backup dumps in them. There is one more non amanda directory called "windows". I use this directory to backup windows servers [non amanda backup process - manual] Thanks!
Re: Problem with amflush
Hello, Jon, Mittwoch, 04. Februar 2004, 22:44 you wrote: JL> On Wed, Feb 04, 2004 at 09:54:17PM +0100, Stefan G. Weichinger wrote: >> >> R> $amflush -fs DailySet1 >> R> /usr/sbin/amflush: invalid option -- s >> >> Hmmm. I don't exactly know when this option came into game. >> JL> It has to be rea recent. JL> It is not in my 8 month old 2.4.4 (6/2003) snapshot. I got kind of a snapshot-hunter in the last few months ;) JL> What does it do? man amflush : -s Write log to stdout/stderr instead of the amflush log file. Require the -f option. -f Run amflush in foreground. ... Would be helpful for Rohit, I assume ... -- best regards, Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
Hi, Rohit, on Mittwoch, 04. Februar 2004 at 15:41 you wrote to amanda-users: >> Run >> >> amflush -fs DailySet1 >> >> so you get the messages to stdout. >> Gives a load of info ... R> $amflush -fs DailySet1 R> /usr/sbin/amflush: invalid option -- s Hmmm. I don't exactly know when this option came into game. 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? What does a simple "find / -name amflush -type f" give you? 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. Verify that you have ONE binary. If more, verify the execution of each of them. If you find out that one works, get rid of the others. In case of several mixed-up installs I would take the effort and recompile a clean and fresh 2.4.4p2 after removing the old AMANDA-binaries. -- Also verify what Jon and Paul assumed: Check if the directories contain something useful or if the contain something that does not belong there. What is the "windows"-dir there? 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 ;) Also check permissions and stuff. 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. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
Rohit wrote:
Maybe looks like not. I ran amflush around 2 hours ago. As before, nothing
happened. I killed amanda processes and ran amcleanup. This is the email
which I got from amanda:
The dumps were flushed to tape Set-1-07.
The next tape Amanda expects to use is: Set-1-08.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)2:31
Well, that's strange! Why does amflush need to to do an estimate???
My 28 Gbyte flush on monday morning takes 0:00 estimate time.
There isn't even an estimate phase when doing amflush (skimmed quickly
in the source, correct me if I missed it.)
Are you sure you execute the correct amflush command? Some people
have many versions (the system supplied one, maybe version 2.4.1
in /usr/sbin, some other version in /usr/local/sbin, and/or a
self compiled in ~amanda/sbin ...
Just checking... your holdingdisk and it's subdirectories
are local disks AND are owned by amanda? And you do run
amdump and amflush as user amanda?
PS. to avoid complaints about cruft concerning the lost+found
directory, make a subdir on that disk (/disk/amandahold/TheConfig)
and specify that subdir as holdingdisk directory in amanda.conf.
--
Paul Bijnens, XplanationTel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...*
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***
same here, was: Re: Problem with amflush
I am having the same problem here. My /data/amanda directory cleary contains data. I
am running:
amflush -f DailySet1 and this is what I get
Today is: 20040204
Flushing dumps in 20031209, 20031210, 20031218, 20040103, 20040115, 20040121,
20040123, 20040124 to tape drive "/dev/nst0".
Expecting tape DMP13 or a new tape. (The last dumps were to tape DMP12)
Are you sure you want to do this [yN]? y
amflush: datestamp 20040204
driver: pid 22039 executable driver version 2.4.3
taper: pid 22040 executable taper version 2.4.3
taper: page size is 4096
taper: buffer size is 32768
taper: buffer[00] at 0x400db000
taper: buffer[01] at 0x400e3000
taper: buffer[02] at 0x400eb000
taper: buffer[03] at 0x400f3000
taper: buffer[04] at 0x400fb000
taper: buffer[05] at 0x40103000
taper: buffer[06] at 0x4010b000
taper: buffer[07] at 0x40113000
taper: buffer[08] at 0x4011b000
taper: buffer[09] at 0x40123000
taper: buffer[10] at 0x4012b000
taper: buffer[11] at 0x40133000
taper: buffer[12] at 0x4013b000
taper: buffer[13] at 0x40143000
taper: buffer[14] at 0x4014b000
taper: buffer[15] at 0x40153000
taper: buffer[16] at 0x4015b000
taper: buffer[17] at 0x40163000
taper: buffer[18] at 0x4016b000
taper: buffer[19] at 0x40173000
taper: buffer structures at 0x4017b000 for 240 bytes
driver: send-cmd time 0.018 to taper: START-TAPER 20040204
driver: adding holding disk 0 dir /data/amanda size 3145728
reserving 3145728 out of 3145728 for degraded-mode dumps
taper: read label `DMP13' date `20040108'
taper: wrote label `DMP13' date `20040204'
So, amflush writes the tapelable and than just stops. The tape is good (tested), it
does that with all 25 Tapes in my tapecycle. Nothing is written in the /temp/amanda
log directory. If I kill the amflush process I get an email telling me that the dump
didn't end correctly.
Axel
> On Wed, Feb 04, 2004 at 07:01:31PM +0530, Rohit wrote:
> > > Is there actually anything in the holdingdisk?
> > > Does amflush show you dumps to flush?
> >
> > -bash-2.05b$ /usr/sbin/amflush -f DailySet1
> > Scanning /backup...
> > lost+found: skipping cruft directory, perhaps you should delete
> it.> windows: skipping cruft directory, perhaps you should delete
> it.> 20040130: found Amanda directory.
> > 20040131: found Amanda directory.
> > 20031230: found Amanda directory.
> > 20040201: found Amanda directory.
> > 20040203: found Amanda directory.
> >
> > Multiple Amanda directories, please pick one by letter:
> > A. 20031230
> > B. 20040130
> > C. 20040131
> > D. 20040201
> > E. 20040203
> > Select directories to flush [A..E]: [ALL]
> >
>
> OK, please take that to the next logical step.
>
> Amanda is telling you you have "cruft directories" as well
> as "apparently good amanda directories". Is there anything
> in those directories? Perhaps your apparently good directories
> also contain "cruft", and only cruft *** .
>
> At the end of an amdump run amanda tries to remove the directory
> it was using. It "should" have already removed all files from
> those directories so a basic "rmdir" type remove should work.
> But if any "cruft" is left behind, the "rmdir" action will not
> remove the directory and it will "look like" there is still
> something needing flushing.
>
>
>
>
> ***
> cruft /kruhft/ [very common; back-formation from {crufty}]
> 1. n. An unpleasant substance.
> The dust that gathers under your bed is cruft;
> the TMRC Dictionary correctly noted that attacking it with
> a broom only produces more.
> 2. n. The results of shoddy construction.
> 3. vt. [from `hand cruft', pun on `hand craft'] To write
> assembler code
> for something normally (and better) done by a compiler (see
> {hand-hacking}).
> 4. n. Excess; superfluous junk; used esp. of redundant or
> superseded code.
> 5. [University of Wisconsin] n. Cruft is to hackers as gaggle is
> to geese;
> that is, at UW one properly says "a cruft of hackers".
>
> Source: Jargon File (4.3.0, 30 APR 2001)
>
> --
> Jon H. LaBadie [EMAIL PROTECTED]
> JG Computing
> 4455 Province Line Road(609) 252-0159
> Princeton, NJ 08540-4322 (609) 683-7220 (fax)
>
Re: Problem with amflush
On Wed, Feb 04, 2004 at 07:01:31PM +0530, Rohit wrote:
> > Is there actually anything in the holdingdisk?
> > Does amflush show you dumps to flush?
>
> -bash-2.05b$ /usr/sbin/amflush -f DailySet1
> Scanning /backup...
> lost+found: skipping cruft directory, perhaps you should delete it.
> windows: skipping cruft directory, perhaps you should delete it.
> 20040130: found Amanda directory.
> 20040131: found Amanda directory.
> 20031230: found Amanda directory.
> 20040201: found Amanda directory.
> 20040203: found Amanda directory.
>
> Multiple Amanda directories, please pick one by letter:
> A. 20031230
> B. 20040130
> C. 20040131
> D. 20040201
> E. 20040203
> Select directories to flush [A..E]: [ALL]
>
OK, please take that to the next logical step.
Amanda is telling you you have "cruft directories" as well
as "apparently good amanda directories". Is there anything
in those directories? Perhaps your apparently good directories
also contain "cruft", and only cruft *** .
At the end of an amdump run amanda tries to remove the directory
it was using. It "should" have already removed all files from
those directories so a basic "rmdir" type remove should work.
But if any "cruft" is left behind, the "rmdir" action will not
remove the directory and it will "look like" there is still
something needing flushing.
***
cruft /kruhft/ [very common; back-formation from {crufty}]
1. n. An unpleasant substance.
The dust that gathers under your bed is cruft;
the TMRC Dictionary correctly noted that attacking it with
a broom only produces more.
2. n. The results of shoddy construction.
3. vt. [from `hand cruft', pun on `hand craft'] To write assembler code
for something normally (and better) done by a compiler (see {hand-hacking}).
4. n. Excess; superfluous junk; used esp. of redundant or superseded code.
5. [University of Wisconsin] n. Cruft is to hackers as gaggle is to geese;
that is, at UW one properly says "a cruft of hackers".
Source: Jargon File (4.3.0, 30 APR 2001)
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Problem with amflush
> Run > > amflush -fs DailySet1 > > so you get the messages to stdout. > Gives a load of info ... $amflush -fs DailySet1 /usr/sbin/amflush: invalid option -- s Thanks!
Re: Problem with amflush
On Wednesday 04 February 2004 07:20, Rohit wrote: >> Have you tried to test your tapes and tape-device by just manually >> tarring stuff onto tapes? > >Will this work without overwriting tape label? > >$tar -cvf /dev/nst0 ~/home/user/testdirectory/* > >Thanks! >Rohit Start with a "dd if=/dev/nst0 off=scratch bs=32768 count=1" then do the "tar -cvf /dev/nst0" etc. Then to check the recovery, rewind the tape, then do "dd if=/dev/nst0 bs=32768 count=1" which will read the label out to the screen so you can see its still there, then do the tar test recovery from there without rewinding the tape. Thats one way. One could also use the kept scratch file by using /dev/st0 which will rewind the tape, then do the tar -cvf stuffs, check the tar test recovery, and when done, rewind and do a "dd if=scratch of=/dev/st0" which will restore the tapes label. The difference is that in the second instance, the label will be over-written so you must restore it, the first instance will not so it shouldn't need restoration on the tape. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: Problem with amflush
Hi, Rohit, on Mittwoch, 04. Februar 2004 at 14:31 you wrote to amanda-users: >> Is there actually anything in the holdingdisk? >> Does amflush show you dumps to flush? R> -bash-2.05b$ /usr/sbin/amflush -f DailySet1 R> Scanning /backup... R> lost+found: skipping cruft directory, perhaps you should delete it. R> windows: skipping cruft directory, perhaps you should delete it. R> 20040130: found Amanda directory. R> 20040131: found Amanda directory. R> 20031230: found Amanda directory. R> 20040201: found Amanda directory. R> 20040203: found Amanda directory. R> Multiple Amanda directories, please pick one by letter: R> A. 20031230 R> B. 20040130 R> C. 20040131 R> D. 20040201 R> E. 20040203 R> Select directories to flush [A..E]: [ALL] Ok. Just tried this for the first time, but maybe it helps: Run amflush -fs DailySet1 so you get the messages to stdout. Gives a load of info ... -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
> Is there actually anything in the holdingdisk? > Does amflush show you dumps to flush? -bash-2.05b$ /usr/sbin/amflush -f DailySet1 Scanning /backup... lost+found: skipping cruft directory, perhaps you should delete it. windows: skipping cruft directory, perhaps you should delete it. 20040130: found Amanda directory. 20040131: found Amanda directory. 20031230: found Amanda directory. 20040201: found Amanda directory. 20040203: found Amanda directory. Multiple Amanda directories, please pick one by letter: A. 20031230 B. 20040130 C. 20040131 D. 20040201 E. 20040203 Select directories to flush [A..E]: [ALL] > And your report: > > amflush has no need to estimate anything. Yes not to estimate, but shouldn't it show dump statistics? > Generally: Version of AMANDA/OS ? Amanda: 2.4.3-4 OS: RH 9.0 Kernel: 2.4.20-20.9
Re: Problem with amflush
Hi, Rohit, on Mittwoch, 04. Februar 2004 at 14:02 you wrote to amanda-users: >> Maybe the problem is not AMANDA at all. R> Maybe looks like not. I ran amflush around 2 hours ago. As before, nothing R> happened. I killed amanda processes and ran amcleanup. This is the email R> which I got from amanda: R> The dumps were flushed to tape Set-1-07. R> The next tape Amanda expects to use is: Set-1-08. R> STATISTICS: R> Total Full Daily R> R> Estimate Time (hrs:min)2:31 R> Run Time (hrs:min) 2:31 R> Dump Time (hrs:min)0:00 0:00 0:00 R> Output Size (meg) 0.00.00.0 R> Original Size (meg) 0.00.00.0 R> Avg Compressed Size (%) -- -- -- R> Filesystems Dumped0 0 0 R> Avg Dump Rate (k/s) -- -- -- R> Tape Time (hrs:min)0:00 0:00 0:00 R> Tape Size (meg) 0.00.00.0 R> Tape Used (%) 0.00.00.0 R> Filesystems Taped 0 0 0 R> Avg Tp Write Rate (k/s) -- -- -- R> NOTES: R> taper: tape Set-1-07 kb 0 fm 0 [OK] R> DUMP SUMMARY: R> R> R> I checked all logs to see if any tape error occurred, but none of them R> indicate any errors. That was the reason why I was not completely ruling out R> problem with amanda. What could have happened? Is there actually anything in the holdingdisk? Does amflush show you dumps to flush? And your report: amflush has no need to estimate anything. Generally: Version of AMANDA/OS ? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
Hi, Rohit, on Mittwoch, 04. Februar 2004 at 13:20 you wrote to amanda-users: >> Have you tried to test your tapes and tape-device by just manually >> tarring stuff onto tapes? R> Will this work without overwriting tape label? R> $tar -cvf /dev/nst0 ~/home/user/testdirectory/* No... Take a non-AMANDA-tape for this ... -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
> Maybe the problem is not AMANDA at all.
Maybe looks like not. I ran amflush around 2 hours ago. As before, nothing
happened. I killed amanda processes and ran amcleanup. This is the email
which I got from amanda:
The dumps were flushed to tape Set-1-07.
The next tape Amanda expects to use is: Set-1-08.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)2:31
Run Time (hrs:min) 2:31
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
NOTES:
taper: tape Set-1-07 kb 0 fm 0 [OK]
DUMP SUMMARY:
I checked all logs to see if any tape error occurred, but none of them
indicate any errors. That was the reason why I was not completely ruling out
problem with amanda. What could have happened?
Thanks!
Rohit
Re: Problem with amflush
> Have you tried to test your tapes and tape-device by just manually > tarring stuff onto tapes? Will this work without overwriting tape label? $tar -cvf /dev/nst0 ~/home/user/testdirectory/* Thanks! Rohit
Re: Problem with amflush
Hi, Rohit, on Mittwoch, 04. Februar 2004 at 12:40 you wrote to amanda-users: >> I have to assume that amdump is not working, either. R> Backups which run in the night seems to be running fine. For example R> yesterday's night backup ran well before spitting out Input/Output tape R> errors [I'm assuming its a bad tape problem - I'm planning to replace such R> tapes] Have you tried to test your tapes and tape-device by just manually tarring stuff onto tapes? Stress the tape and assure that the device is working. Clean the drives heads. Replace worn-out tapes Maybe the problem is not AMANDA at all. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Problem with amflush
> I don't know what you have been told before. > > As you wrote > > R>> I still have close to 4 to 5 backup > R>> dumps created by amanda in my holding space [which failed across various > R>> weeks]. > > I have to assume that amdump is not working, either. Backups which run in the night seems to be running fine. For example yesterday's night backup ran well before spitting out Input/Output tape errors [I'm assuming its a bad tape problem - I'm planning to replace such tapes] > How many amanda-processes are running already? amanda 23560 97.5 0.0 2124 20 ?R15:51 72:30 ./amflush DailySet1 amanda 23561 0.0 0.0 21324 ?S15:51 0:00 driver DailySet1 nodump amanda 23562 0.0 0.0 27844 ?S15:51 0:00 taper DailySet1 amanda 23563 0.0 0.0 28084 ?S15:51 0:00 taper DailySet1 root 26989 0.0 0.2 3576 644 pts/4S17:05 0:00 grep amanda > Try to kill all the amdump/amflush-processes, they seem to lock each > other. Run amcleanup afterwards, then amcheck. I do this: 1) Kill all the processes which belong to amanda 2) Run amcleanup 3) Run amflush again, but it slowly eats away CPU and amflush gets stuck. > After that amflush should run fine. Well, in my case, it doesn't :)
Re: Problem with amflush
Hi, Rohit, on Mittwoch, 04. Februar 2004 at 11:43 you wrote to amanda-users: R> I have been getting this problem for quite some time now. Even my repeated R> attempts failed to resolve this problem. I still have close to 4 to 5 backup R> dumps created by amanda in my holding space [which failed across various R> weeks]. I try to run amflush, it just sits there doing nothing [happly R> eating away my CPU time]. Tape drive shows no indication that it is running R> [lights don't blink]. But when I try to access tape device from outside [mt R> status] -- it says "device is busy". R> I don't really know what is happening. I tried running amflush several R> times, but still does not work, the only thing which happens is amanda keeps R> asking for new tapes without actually writing anything on to it! R> Any anyone give me any pointers? I don't know what you have been told before. As you wrote R>> I still have close to 4 to 5 backup R>> dumps created by amanda in my holding space [which failed across various R>> weeks]. I have to assume that amdump is not working, either. How many amanda-processes are running already? Try to kill all the amdump/amflush-processes, they seem to lock each other. Run amcleanup afterwards, then amcheck. After that amflush should run fine. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
RE: Problem with amflush
John LaBadie wrotes: > That report suggests to me that there were no "partitions" to dump. > > You noted it has been running for an hour. When I run amflush, > there is an interactive Q&A session that, after I give the final > confirmation, shifts amflush to the background noting it will send > me a mail message when completed. Is that what you saw too? Yes, if i start amflush without -f option, then he asks me this way and I see the same output. > Did you get a mail message? What were its contents? "amflush failed" or something like this. This don't make me wonder, because I killed the amflush-process. I needed the taper for the next backup at night and wanted to leave off work ;-). > Do you have things to flush? amflush, during the Q&A, shows what > amdumps might be available for flushing. If you go to the holding > disk, are there files for dumping there? Maybe that's the problem. There are not really flushable things. But why is there no error-message and it runs and runs and runs and runs ...? This make me worry. Our amanda-version is 2.4.3-4. > Do you think that you have something to flush because an amdump > report said (IIRC) "some dumps MAY have been left in the > holding disk". > Note that "MAY", it is a key word. There 'may not' have been anything > left either. At the point amanda adds that info to the amdump report > it can't tell. > > Did you run an amdump since the problem run? I ask as there is an > "autoflush" option in amanda.conf that causes anything that needs > flushing to be flushed at the start of the next amdump run. The autoflush-option is set to "no", because we would have problems with our backup-strategy. Thanks for help. I will see, how amanda works next times. Best regards Bernd
Re: Problem with amflush
On Fri, Jan 30, 2004 at 04:23:44PM +0100, Postaremczak Bernd wrote: > Hello, > > my storage with amanda this night failed because there was a time-problem > with two concurrent jobs. The dumps are there where they should be (in the > dump-directory). Now I will run amflush, but it doesn't seem to work. The > Process has maximum CPU-Usage, but there is no writing on tape. > > I have no idea where I can begin to search. > > The logfiles don't say anything for errors. amstatus says, that the dumper > will work (see output below), but the process runs about 1 hour. Normally > the writing to tape goes only 13 minutes, so he should hav been finished > now. > > -bash-2.05b$ amstatus levap03-do > Using /var/log/amanda/levap03-do/amflush > > > SUMMARY part real estimated > size size > partition : 0 > estimated : 0 0k > flush : 00k > failed : 0 0k ( 0.00%) > wait for dumping: 0 0k ( 0.00%) > dumping to tape : 0 0k ( 0.00%) > dumping : 00k0k ( 0.00%) ( 0.00%) > dumped : 00k0k ( 0.00%) ( 0.00%) > wait for writing: 00k0k ( 0.00%) ( 0.00%) > wait to flush : 00k0k (100.00%) ( 0.00%) > writing to tape : 00k0k ( 0.00%) ( 0.00%) > failed to tape : 00k0k ( 0.00%) ( 0.00%) > taped : 00k0k ( 0.00%) ( 0.00%) > all dumpers active > taper idle > > Or is there a misunderstanding in my point of view of working amflush? That report suggests to me that there were no "partitions" to dump. You noted it has been running for an hour. When I run amflush, there is an interactive Q&A session that, after I give the final confirmation, shifts amflush to the background noting it will send me a mail message when completed. Is that what you saw too? Did you get a mail message? What were its contents? Do you have things to flush? amflush, during the Q&A, shows what amdumps might be available for flushing. If you go to the holding disk, are there files for dumping there? Do you think that you have something to flush because an amdump report said (IIRC) "some dumps MAY have been left in the holding disk". Note that "MAY", it is a key word. There 'may not' have been anything left either. At the point amanda adds that info to the amdump report it can't tell. Did you run an amdump since the problem run? I ask as there is an "autoflush" option in amanda.conf that causes anything that needs flushing to be flushed at the start of the next amdump run. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
