On Sat, Dec 19, 2020 at 03:32:07 -0500, Gene Heskett wrote:
> But the problem is not fixed:
Well, at least this time it's a one-part dump file, so that may make
investigation at little easier....
>
> FAILURE DUMP SUMMARY:
> rpi4 /usr/lib lev 0 partial taper: source server crc (efe0c707:1538583893)
> and input server crc (fa79e777:1538583893)
> differ)
> rpi4 /usr/lib lev 0 was successfully retried
>
> But the failed dump is still in the holding disk:
>
> root@coyote:config-bak$ ls -l /sdb/dumps/20201219020104/
> total 1502560
> -rw------- 1 amanda amanda 1538616661 Dec 19 02:13 rpi4._usr_lib.0
>
> >From the emailed report:
>
> driver: rpi4 /usr/lib 20201219020104 0 [Will retry dump because of holding
> disk error: source server crc
> (efe0c707:1538583893) and input server crc (fa79e777:1538583893) differ)]
> taper: tape Dailys-24 kb 16495500 fm 79 [OK]
>
> and:
> rpi4 /usr/lib 0 3273 1467 -- 5:23 10366.4 0:01 1502523.0 PARTIAL FLUSH
> 5:11 4831.3
>
> Even the sizes don't match so of course the crc's won't either.
Note that the two sizes mentioned in the error message do match
(1538583893), so I think the full file is getting transfered.
(The file on the holding disk is 32kiB larger, i.e. the size of the
Amanda header: 1538616661-1538583893=32768 .)
What's the header of that holding-disk file look like? (e.g.
$ sudo dd if=/sdb/dumps/20201219020104/rpi4._usr_lib.0 bs=32k count=1
)
Do you get any hits when you grep the Amanda debug and log files for
those two CRC values ( efe0c707 and fa79e777 )?
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [email protected] - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
