Re: [bis] discrepency between amadmin, logs and tape content?
Jean-Francois Malouin wrote: However amadmin info' still reports only one tape at level 0. Is this the expected behaviour? It's expected behavior, 'amadmin info' reports only the tape for the last PART. Jean-Louis
Re: [bis] discrepency between amadmin, logs and tape content?
Replying to myself...see at the bottom... * Jean-Francois Malouin <[EMAIL PROTECTED]> [20080305 11:30]: > Ok, here I go again. amanda-2.5.2p1 server and client debian/etch. > > I have seen this in the past (last Oct iirc) and I remember that > Jean-Louis provided me with a patch but that was for the case of a > succesfully retried DLE. > In this particular case there was no retry but nevertheless amadmin > and amfetchdump both claims that only the last tape containing the > spanning dump is needed. > > Has that patch been back-ported to 2.5.2p1 before I recompile the > server from scratch? (Can't seem to find the patch!) > > Here is the relevent info: > > # /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 \ > bigbrain BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - > 1 tape(s) needed for restoration > The following tapes are needed: av24-1_left1_S00025L3 > Press enter when ready > > But I know for a fact that the following tapes are needed: > av24-1_left1_S00025L3 > av24-1_left1_S00024L3 > av24-1_left1_S00014L3 > av24-1_left1_S00013L3 > > as I can extract the chunks manually or with amrestore. > > # su amanda -c "/opt/amanda/sbin/amadmin \ > left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: > Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 > Incremental: 120.0, -1.0, -1.0 > compressed size, Full: -100.0%,-100.0%,-100.0% > Incremental: -100.0%,-100.0%,-100.0% > Dumps: lev datestmp tape file origK compK secs > 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 > > # su amanda -c "/opt/amanda/sbin/amadmin left1 \ > find bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L31 158 OK > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L32 159 OK > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L33 160 OK > > regards, > jf > -- > <° >< I solved this by recompiling amanda from a fresh tarball and it is ok now as amfetchdump requests all the tapes: /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 bigbrain \ BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - 4 tape(s) needed for restoration The following tapes are needed: av24-1_left1_S00013L3 av24-1_left1_S00014L3 av24-1_left1_S00024L3 av24-1_left1_S00025L3 Press enter when ready However amadmin info' still reports only one tape at level 0. Is this the expected behaviour? su amanda -c "/opt/amanda/sbin/amadmin \ left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 Incremental: 120.0, -1.0, -1.0 compressed size, Full: -100.0%,-100.0%,-100.0% Incremental: -100.0%,-100.0%,-100.0% Dumps: lev datestmp tape file origK compK secs 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 1 20080308 av24-1_left1_S00028L3 8 120 120 0 regards, jf -- <° ><
Re: [bis] discrepency between amadmin, logs and tape content?
Jean-Francois, It's a known bug in amrecover, (will be fixed in 2.6.0b3). it try to recover from dump even if not all part are available. From amdadmin, only part 158, 159 and 160 are available. You said all the parts are available on tapes, but why amadmin doesn't list them? Did it gives a warning about those tapes? Did you overwrite the tape or amrmtape them? Jean-Louis Jean-Francois Malouin wrote: Anyone on this please? I know, it's not as sexy as 2.6.x :) * Jean-Francois Malouin <[EMAIL PROTECTED]> [20080305 12:30]: Ok, here I go again. amanda-2.5.2p1 server and client debian/etch. I have seen this in the past (last Oct iirc) and I remember that Jean-Louis provided me with a patch but that was for the case of a succesfully retried DLE. In this particular case there was no retry but nevertheless amadmin and amfetchdump both claims that only the last tape containing the spanning dump is needed. Has that patch been back-ported to 2.5.2p1 before I recompile the server from scratch? (Can't seem to find the patch!) Here is the relevent info: # /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 \ bigbrain BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - 1 tape(s) needed for restoration The following tapes are needed: av24-1_left1_S00025L3 Press enter when ready But I know for a fact that the following tapes are needed: av24-1_left1_S00025L3 av24-1_left1_S00024L3 av24-1_left1_S00014L3 av24-1_left1_S00013L3 as I can extract the chunks manually or with amrestore. # su amanda -c "/opt/amanda/sbin/amadmin \ left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 Incremental: 120.0, -1.0, -1.0 compressed size, Full: -100.0%,-100.0%,-100.0% Incremental: -100.0%,-100.0%,-100.0% Dumps: lev datestmp tape file origK compK secs 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 # su amanda -c "/opt/amanda/sbin/amadmin left1 \ find bigbrain BIG_BRAIN_pm3903_postmortem_tif" 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 av24-1_left1_S00025L31 158 OK 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 av24-1_left1_S00025L32 159 OK 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 av24-1_left1_S00025L33 160 OK regards, jf -- <° ><
Re: [bis] discrepency between amadmin, logs and tape content?
Bcc: Subject: Re: [bis] discrepency between amadmin, logs and tape content? Reply-To: In-Reply-To: <[EMAIL PROTECTED]> * Dustin J. Mitchell <[EMAIL PROTECTED]> [20080306 13:56]: > On Thu, Mar 6, 2008 at 12:24 PM, Jean-Francois Malouin > <[EMAIL PROTECTED]> wrote: > > Anyone on this please? > > I know, it's not as sexy as 2.6.x :) > > I'm confused. I was hoping someone else understood the problem and would > reply. > > > > # /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 \ > > > bigbrain BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - > > > 1 tape(s) needed for restoration > > > The following tapes are needed: av24-1_left1_S00025L3 > > > Press enter when ready > > OK, so amfetchdump wants just tape 25. and that is the prblem...read on... > > > > But I know for a fact that the following tapes are needed: > > > av24-1_left1_S00025L3 > > > av24-1_left1_S00024L3 > > > av24-1_left1_S00014L3 > > > av24-1_left1_S00013L3 > > > > > > as I can extract the chunks manually or with amrestore. > > What do you mean by that? That dle is 800GB and amtoc reported 4 tapes were used so when I attempted to test-restore with amfetchdump and only one tape was requested I found it rather strange. I then manually restored all the chunks of that DLE using amrestore and the 4 tapes that amtoc reported were used (160 of them at 5GB each) and manually cat them together followed by a gnutar extract. It helps to have a 2TB hold disk :) > > > # su amanda -c "/opt/amanda/sbin/amadmin \ > > > left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > > > > > Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: > > > Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 > > > Incremental: 120.0, -1.0, -1.0 > > > compressed size, Full: -100.0%,-100.0%,-100.0% > > > Incremental: -100.0%,-100.0%,-100.0% > > > Dumps: lev datestmp tape file origK compK secs > > > 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 > > OK -- there's a level 0 on tape 25. > > > > # su amanda -c "/opt/amanda/sbin/amadmin left1 \ > > > find bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > > > > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > > av24-1_left1_S00025L31 158 OK > > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > > av24-1_left1_S00025L32 159 OK > > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > > av24-1_left1_S00025L33 160 OK > > And again -- a level 0 (in three parts) on tape 25. no, the 3 parts 1,2,3 are the first tape files on the tape but if you look closely, the next column shows 158,159,160: those are the last 3 chunks of that dle. The 157 previous ones are on the 3 other tapes that amfetchdump and amadmin don't report correctly. thanks! jf > > Dustin > > -- > Storage Software Engineer > http://www.zmanda.com -- <° ><
Re: [bis] discrepency between amadmin, logs and tape content?
On Thu, Mar 6, 2008 at 12:24 PM, Jean-Francois Malouin <[EMAIL PROTECTED]> wrote: > Anyone on this please? > I know, it's not as sexy as 2.6.x :) I'm confused. I was hoping someone else understood the problem and would reply. > > # /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 \ > > bigbrain BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - > > 1 tape(s) needed for restoration > > The following tapes are needed: av24-1_left1_S00025L3 > > Press enter when ready OK, so amfetchdump wants just tape 25. > > But I know for a fact that the following tapes are needed: > > av24-1_left1_S00025L3 > > av24-1_left1_S00024L3 > > av24-1_left1_S00014L3 > > av24-1_left1_S00013L3 > > > > as I can extract the chunks manually or with amrestore. What do you mean by that? > > # su amanda -c "/opt/amanda/sbin/amadmin \ > > left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > > > Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: > > Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 > > Incremental: 120.0, -1.0, -1.0 > > compressed size, Full: -100.0%,-100.0%,-100.0% > > Incremental: -100.0%,-100.0%,-100.0% > > Dumps: lev datestmp tape file origK compK secs > > 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 OK -- there's a level 0 on tape 25. > > # su amanda -c "/opt/amanda/sbin/amadmin left1 \ > > find bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L31 158 OK > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L32 159 OK > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L33 160 OK And again -- a level 0 (in three parts) on tape 25. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: [bis] discrepency between amadmin, logs and tape content?
Anyone on this please? I know, it's not as sexy as 2.6.x :) * Jean-Francois Malouin <[EMAIL PROTECTED]> [20080305 12:30]: > Ok, here I go again. amanda-2.5.2p1 server and client debian/etch. > > I have seen this in the past (last Oct iirc) and I remember that > Jean-Louis provided me with a patch but that was for the case of a > succesfully retried DLE. > In this particular case there was no retry but nevertheless amadmin > and amfetchdump both claims that only the last tape containing the > spanning dump is needed. > > Has that patch been back-ported to 2.5.2p1 before I recompile the > server from scratch? (Can't seem to find the patch!) > > Here is the relevent info: > > # /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 \ > bigbrain BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - > 1 tape(s) needed for restoration > The following tapes are needed: av24-1_left1_S00025L3 > Press enter when ready > > But I know for a fact that the following tapes are needed: > av24-1_left1_S00025L3 > av24-1_left1_S00024L3 > av24-1_left1_S00014L3 > av24-1_left1_S00013L3 > > as I can extract the chunks manually or with amrestore. > > # su amanda -c "/opt/amanda/sbin/amadmin \ > left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: > Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 > Incremental: 120.0, -1.0, -1.0 > compressed size, Full: -100.0%,-100.0%,-100.0% > Incremental: -100.0%,-100.0%,-100.0% > Dumps: lev datestmp tape file origK compK secs > 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 > > # su amanda -c "/opt/amanda/sbin/amadmin left1 \ > find bigbrain BIG_BRAIN_pm3903_postmortem_tif" > > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L31 158 OK > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L32 159 OK > 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 > av24-1_left1_S00025L33 160 OK > > regards, > jf > -- > <° >< -- <° ><
[bis] discrepency between amadmin, logs and tape content?
Ok, here I go again. amanda-2.5.2p1 server and client debian/etch. I have seen this in the past (last Oct iirc) and I remember that Jean-Louis provided me with a patch but that was for the case of a succesfully retried DLE. In this particular case there was no retry but nevertheless amadmin and amfetchdump both claims that only the last tape containing the spanning dump is needed. Has that patch been back-ported to 2.5.2p1 before I recompile the server from scratch? (Can't seem to find the patch!) Here is the relevent info: # /opt/amanda/sbin/amfetchdump -p -d /dev/nrst0 left1 \ bigbrain BIG_BRAIN_pm3903_postmortem_tif 20080303 | tar -xpvf - 1 tape(s) needed for restoration The following tapes are needed: av24-1_left1_S00025L3 Press enter when ready But I know for a fact that the following tapes are needed: av24-1_left1_S00025L3 av24-1_left1_S00024L3 av24-1_left1_S00014L3 av24-1_left1_S00013L3 as I can extract the chunks manually or with amrestore. # su amanda -c "/opt/amanda/sbin/amadmin \ left1 info bigbrain BIG_BRAIN_pm3903_postmortem_tif" Current info for bigbrain BIG_BRAIN_pm3903_postmortem_tif: Stats: dump rates (kps), Full: 67481.3, 81007.6, -1.0 Incremental: 120.0, -1.0, -1.0 compressed size, Full: -100.0%,-100.0%,-100.0% Incremental: -100.0%,-100.0%,-100.0% Dumps: lev datestmp tape file origK compK secs 0 20080303 av24-1_left1_S00025L3 3 837780250 837780250 12415 # su amanda -c "/opt/amanda/sbin/amadmin left1 \ find bigbrain BIG_BRAIN_pm3903_postmortem_tif" 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 av24-1_left1_S00025L31 158 OK 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 av24-1_left1_S00025L32 159 OK 2008-03-03 19:10:01 bigbrain BIG_BRAIN_pm3903_postmortem_tif 0 av24-1_left1_S00025L33 160 OK regards, jf -- <° ><
Re: discrepency between amadmin, logs and tape content?
Jean-Francois Malouin wrote: * Jean-Louis Martineau <[EMAIL PROTECTED]> [20071030 10:40]: This bug is fixed in 2.5.3alpha, but the patch was not backported to 2.5.2p1. Can you try the attached patch? Looks like the patch did it. amadmin now reports correctly and amfetchdump can restore the dump. Thanks! jf Thanks for testing it. I committed it, today's snapshot will have the patch. Jean-Louis
Re: discrepency between amadmin, logs and tape content?
* Jean-Louis Martineau <[EMAIL PROTECTED]> [20071030 10:40]:
> This bug is fixed in 2.5.3alpha, but the patch was not backported to
> 2.5.2p1.
>
> Can you try the attached patch?
Looks like the patch did it.
amadmin now reports correctly and amfetchdump can restore the dump.
Thanks!
jf
>
> Jean-Louis
>
> Jean-Francois Malouin wrote:
> >Hi,
> >
> >With amanda-2.5.2p1 I did an archive a few days ago and trying to
> >restore it caused me a few problems: amfetchdump tells me that
> >there is no valid data to be restored for that date and amadmin
> >reports a connection timeout:
> >
> >grumpy: /opt/amanda/sbin/amfetchdump -p -d /dev/nst1 archive-nihpd3-right1
> >\
> >yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 | tar -tvf -
> >No matching dumps found
> >
> >grumpy: su amanda -c "/opt/amanda/sbin/amadmin archive-nihpd3-right1 \
> >find yorick /data/nihpd/nihpd3/data/mri_processing/1.1"
> >2007-10-22 yorick /data/nihpd/nihpd3/data/mri_processing/1.1 0
> >av24-1_archive-nihpd3-right1_T6L30 -- FAILED (dumper) [data
> >read: recv error: Connection timed out]
> >
> >However I was able to manually extract all the chunks on that tape
> >and, after reassembling them, to untar everything without a glitch.
> >Looking at the logs I see that it was retried with success:
> >
> >DISK planner yorick /data/nihpd/nihpd3/data/mri_processing/1.1
> >FAIL dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
> >0 [data read: recv error: Connection timed out]
> > sendbackup: start [yorick:/data/nihpd/nihpd3/data/mri_processing/1.1
> >level 0]
> >PARTIAL chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
> >0 [sec 9771.397 kb 105401080 kps 10786.7]
> >SUCCESS dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
> >0 [sec 10432.472 kb 113375650 kps 10867.6 orig-kb 113375650]
> >SUCCESS chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
> >0 [sec 10432.600 kb 113375650 kps 10867.4]
> >STATS driver estimate yorick /data/nihpd/nihpd3/data/mri_processing/1.1
> >20071022 0 [sec 8192 nkb 113375682 ckb 113375712 kps 13840]
> >CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 1 0
> >[sec 197.311 kb 5242848 kps 26571.5 {wr: writers 163840 rdwait
> >79.637 wrwait 112.112 filemark 4.930}]
> >CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 2 0
> >[sec 101.364 kb 5242848 kps 51722.7 {wr: writers 163840 rdwait
> >42.617 wrwait 57.238 filemark 1.013}]
> >
> >...
> >
> >CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 22
> >0 [sec 60.077 kb 3275872 kps 54527.8 {wr: writers 102372 rdwait
> >3.036 wrwait 55.529 filemark 1.051}]
> >CHUNKSUCCESS taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1
> >20071022 0 [sec 2313.467 kb 113376352 kps 49007.1 {wr: writers 102372
> >rdwait 3.036 wrwait 55.529 filemark 1.051}]
> >
> >what gives?
> >jf
> >
>
--
<° ><
Re: discrepency between amadmin, logs and tape content?
This bug is fixed in 2.5.3alpha, but the patch was not backported to
2.5.2p1.
Can you try the attached patch?
Jean-Louis
Jean-Francois Malouin wrote:
Hi,
With amanda-2.5.2p1 I did an archive a few days ago and trying to
restore it caused me a few problems: amfetchdump tells me that
there is no valid data to be restored for that date and amadmin
reports a connection timeout:
grumpy: /opt/amanda/sbin/amfetchdump -p -d /dev/nst1 archive-nihpd3-right1 \
yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 | tar -tvf -
No matching dumps found
grumpy: su amanda -c "/opt/amanda/sbin/amadmin archive-nihpd3-right1 \
find yorick /data/nihpd/nihpd3/data/mri_processing/1.1"
2007-10-22 yorick /data/nihpd/nihpd3/data/mri_processing/1.1 0
av24-1_archive-nihpd3-right1_T6L30 -- FAILED (dumper) [data
read: recv error: Connection timed out]
However I was able to manually extract all the chunks on that tape
and, after reassembling them, to untar everything without a glitch.
Looking at the logs I see that it was retried with success:
DISK planner yorick /data/nihpd/nihpd3/data/mri_processing/1.1
FAIL dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
0 [data read: recv error: Connection timed out]
sendbackup: start [yorick:/data/nihpd/nihpd3/data/mri_processing/1.1
level 0]
PARTIAL chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 9771.397 kb 105401080 kps 10786.7]
SUCCESS dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 10432.472 kb 113375650 kps 10867.6 orig-kb 113375650]
SUCCESS chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 10432.600 kb 113375650 kps 10867.4]
STATS driver estimate yorick /data/nihpd/nihpd3/data/mri_processing/1.1
20071022 0 [sec 8192 nkb 113375682 ckb 113375712 kps 13840]
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 1 0 [sec
197.311 kb 5242848 kps 26571.5 {wr: writers 163840 rdwait
79.637 wrwait 112.112 filemark 4.930}]
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 2 0 [sec
101.364 kb 5242848 kps 51722.7 {wr: writers 163840 rdwait
42.617 wrwait 57.238 filemark 1.013}]
...
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 22 0
[sec 60.077 kb 3275872 kps 54527.8 {wr: writers 102372 rdwait
3.036 wrwait 55.529 filemark 1.051}]
CHUNKSUCCESS taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 2313.467 kb 113376352 kps 49007.1 {wr: writers 102372
rdwait 3.036 wrwait 55.529 filemark 1.051}]
what gives?
jf
diff -u -r --show-c-function --new-file --exclude-from=/home/martinea/src.orig/amanda.diff --ignore-matching-lines='$Id:' amanda-2.5.2p1/server-src/amadmin.c amanda-2.5.2p1.find/server-src/amadmin.c
--- amanda-2.5.2p1/server-src/amadmin.c 2007-07-05 13:02:02.0 -0400
+++ amanda-2.5.2p1.find/server-src/amadmin.c 2007-10-29 13:16:16.0 -0400
@@ -,7 +,7 @@ find(
if(argc < 3) {
fprintf(stderr,
- "%s: expecting \"find [--sort ] [hostname []]*\"\n",
+ "%s: expecting \"find [--sort ] [hostname []]*\"\n",
get_pname());
usage();
}
@@ -1129,6 +1129,8 @@ find(
case 'K':
case 'd':
case 'D':
+ case 'f':
+ case 'F':
case 'l':
case 'L':
case 'p':
diff -u -r --show-c-function --new-file --exclude-from=/home/martinea/src.orig/amanda.diff --ignore-matching-lines='$Id:' amanda-2.5.2p1/server-src/find.c amanda-2.5.2p1.find/server-src/find.c
--- amanda-2.5.2p1/server-src/find.c 2007-05-23 07:56:31.0 -0400
+++ amanda-2.5.2p1.find/server-src/find.c 2007-10-29 13:23:48.0 -0400
@@ -39,7 +39,6 @@
int find_match(char *host, char *disk);
int search_logfile(find_result_t **output_find, char *label, char *datestamp, char *logfile);
void search_holding_disk(find_result_t **output_find);
-void strip_failed_chunks(find_result_t **output_find);
char *find_nicedate(char *datestamp);
static int find_compare(const void *, const void *);
static int parse_taper_datestamp_log(char *logline, char **datestamp, char **level);
@@ -114,8 +113,6 @@ find_dump(
search_holding_disk(&output_find);
-strip_failed_chunks(&output_find);
-
return(output_find);
}
@@ -198,76 +195,6 @@ find_log(void)
return(output_find_log);
}
-/*
- * Remove CHUNK entries from dumps that ultimately failed from our report.
- */
-void strip_failed_chunks(
-find_result_t **output_find)
-{
-find_result_t *cur, *prev = NULL, *failed = NULL, *failures = NULL;
-
-/* Generate a list of failures */
-for(cur=*output_find; cur; cur=cur->next) {
- if(!cur->hostname || !cur->diskname ||
- !cur->timestamp || !cur->label)
- continue;
-
- if(strcmp(cur->status, "OK")){
- failed = alloc(SIZEOF(find_result_t));
- memcpy(failed, cur, SIZEOF(find_result_t));
- failed->next = failures;
- failures = failed;
- }
-}
-
-/* Now if a CHUNK matches the parameters of a failed dump, remove it */
-for(f
discrepency between amadmin, logs and tape content?
Hi,
With amanda-2.5.2p1 I did an archive a few days ago and trying to
restore it caused me a few problems: amfetchdump tells me that
there is no valid data to be restored for that date and amadmin
reports a connection timeout:
grumpy: /opt/amanda/sbin/amfetchdump -p -d /dev/nst1 archive-nihpd3-right1 \
yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 | tar -tvf -
No matching dumps found
grumpy: su amanda -c "/opt/amanda/sbin/amadmin archive-nihpd3-right1 \
find yorick /data/nihpd/nihpd3/data/mri_processing/1.1"
2007-10-22 yorick /data/nihpd/nihpd3/data/mri_processing/1.1 0
av24-1_archive-nihpd3-right1_T6L30 -- FAILED (dumper) [data
read: recv error: Connection timed out]
However I was able to manually extract all the chunks on that tape
and, after reassembling them, to untar everything without a glitch.
Looking at the logs I see that it was retried with success:
DISK planner yorick /data/nihpd/nihpd3/data/mri_processing/1.1
FAIL dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
0 [data read: recv error: Connection timed out]
sendbackup: start [yorick:/data/nihpd/nihpd3/data/mri_processing/1.1
level 0]
PARTIAL chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 9771.397 kb 105401080 kps 10786.7]
SUCCESS dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 10432.472 kb 113375650 kps 10867.6 orig-kb 113375650]
SUCCESS chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 10432.600 kb 113375650 kps 10867.4]
STATS driver estimate yorick /data/nihpd/nihpd3/data/mri_processing/1.1
20071022 0 [sec 8192 nkb 113375682 ckb 113375712 kps 13840]
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 1 0 [sec
197.311 kb 5242848 kps 26571.5 {wr: writers 163840 rdwait
79.637 wrwait 112.112 filemark 4.930}]
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 2 0 [sec
101.364 kb 5242848 kps 51722.7 {wr: writers 163840 rdwait
42.617 wrwait 57.238 filemark 1.013}]
...
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 22 0
[sec 60.077 kb 3275872 kps 54527.8 {wr: writers 102372 rdwait
3.036 wrwait 55.529 filemark 1.051}]
CHUNKSUCCESS taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 2313.467 kb 113376352 kps 49007.1 {wr: writers 102372
rdwait 3.036 wrwait 55.529 filemark 1.051}]
what gives?
jf
--
<° ><
