On Wed, Nov 01, 2017 at 05:03:58PM -0400, Jean-Louis Martineau wrote:
> Jose,
>
> The report should report the error.
> The attached patch fix it.
The patch applied cleanly and I am now compiling it.
Kind regards
Jose M Calhariz
>
> Jean-Louis
>
> On 01/11/17 12:18 PM, Jose M Calhariz wrote:
> > On Wed, Nov 01, 2017 at 10:47:10AM -0400, Jean-Louis Martineau wrote:
> > > Jose,
> > >
> > > When amanda did the backup, it computed a crc of 6828c030.
> > > But it compute b8d66d3d when it read it from holding disk to flush it.
> > > Do you see that error in the report for all flush attempt?
> > Yes, I see.
> >
> >
> > > The holding disk file is not erase because of the crc mismatch.
> > > You can manually remove it (amadmin holding list, amadmin holding
> > > delete) from the holding disk and force a full backup of that dle.
> > >
> > > That's why a added the crc, these kind of errors where undetected
> > > before.
> > I hove only seen this error, because after an amdump I do:
> >
> > /usr/bin/time /usr/sbin/amcheckdump ${CONF}
> > ls -alF /backup/amanda/${CONF}/data/ | tail
> >
> > I have not seen any error on the report generated by amdump. Should
> > not be there a notice about this type of errors?
> >
> >
> > > Jean-Louis
> >
> > Kind reagards
> > Jose M Calhariz
> >
> >
> > > On 01/11/17 10:24 AM, Jose M Calhariz wrote:
> > > > Hi
> > > >
> > > > I am using amanda 3.5 on my personal server and started to investigate
> > > > a strange problem on my amanda installation.
> > > >
> > > > Since around 10 days ago when it runs the amdump during the nigth, it
> > > > flush the holdingdisk, by starting allways with the same big DLE.
> > > > This means after the DLE is on vTape is not deleted from the
> > > > holdingdisk and will be flushed on the next night.
> > > >
> > > > I found an interesting error message in amdump.20171101031517, I think
> > > > this error is related to the problematic DLE. And I noticed that the
> > > > file on vTape is broken too, it generates an error from gzip.
> > > >
> > > > driver: result time 549.166 from taper0: PARTIAL worker0-0 00-00001
> > > > INPUT-ERROR TAPE-GOOD "6828c030:54131462843" "[sec 548.000000 bytes
> > > > 54131462843 kps 96464.883212 orig-kb 53706460]" "source server crc
> > > > (6828c030:54131462843) and input server crc (b8d66d3d:54131462843)
> > > > differ)" ""
> > > >
> > > > This problem possibly was caused by an error on SATA that caused the
> > > > system disk to became read-only.
> > > >
> > > > What logs should I investigate? Because this is a personal
> > > > installation with private data, I will send the logs to the interested
> > > > persons, not to the list.
> > > >
> > > >
> > > > Kind regards
> > > > Jose M Calhariz
> > > >
> > > This message is the property of CARBONITE, INC. and may contain
> > > confidential or privileged information.
> > > If this message has been delivered to you by mistake, then do not copy or
> > > deliver this message to anyone. Instead, destroy it and notify me by
> > > reply e-mail
>
>
> diff --git a/perl/Amanda/Report/human.pm b/perl/Amanda/Report/human.pm
> index 0b80219..e6a700d 100644
> --- a/perl/Amanda/Report/human.pm
> +++ b/perl/Amanda/Report/human.pm
> @@ -667,7 +667,9 @@ sub output_error_summaries
> push @dump_failures, "$hostname $qdisk lev
> $try->{chunker}->{level} FAILED [$try->{chunker}->{error}]";
> $failed = 1;
> }
> - if ( exists $try->{taper} && exists $try->{dumper} && !exists
> $dle->{driver}
> + if ( exists $try->{taper}
> + && ((exists $try->{dumper} && !exists $dle->{driver})
> + || (!exists $try->{dumper} && !exists $dle->{driver}))
> && ( $try->{taper}->{status} eq 'fail'
> || ( $try->{taper}->{status} eq 'partial'))) {
> my $flush = "FLUSH";
--
--
A vaidade de ser tido como alguém que guarda segredos é geralmente um dos
principais motivos para revelá-los
--Samuel Johnson
