Re: Corrupted output on errors

On Sat, Nov 20 2021, Denis Corbin wrote:

>> Now that this is cleared up, I can see the errors:
>>
>> Restoration of FSA for /bakfs/other-backups/dar/ada/var/log/sysstat aborted: Skipping backward is not possible on a pipe
>> Error while restoring data: Error while reading FSA from archive: Reached end of file before all data could be read
>> Final memory cleanup...
>> Error while restoring data: Error while reading FSA from archive: Reached end of file before all data could be read
>>
>> It then exits with error 5.
>>
>> This archive was generated by dar 2.6.13 on a Raspberry Pi running ext4 and unpacked
>> by 2.7.2 on x86_64 running ZFS.

I'm going to add that I have now also experienced this on a sender that
is x86_64 running dar 2.6.13 atop ext4.  The receiver is 2.7.2 on x86_64
with ZFS in both cases.

>
> This error can come from a corrupted transfer between hosts or from dar
> itself (bug). Could you thus:

The dar file itself was piped to zstd and then gpg (for encryption)
prior to transmission, so I think it is highly unlikely that corruption
occurred in transit.

> - check that the backup testing (dar -t <backup>) succeeds with dar
> 2.6.13 on Raspberry?

I didn't happen to have the file from the Raspberry still around, but I
did have the one from the x86_64 sender that triggered the same kind of
issue, so I tried it there:

After decrypting the file:

zstdcat foo.dar.zst | dar --sequential-read -t -

 --------------------------------------------
 204381 item(s) treated
 0 item(s) with error
 0 item(s) ignored (excluded by filters)
 --------------------------------------------
 Total number of items considered: 204381
 --------------------------------------------

(without --sequential-read, I got an error about corrupted data; though
I note I did use --sequential-read on the command I gave)

> - make a sha1 sum of the dar backup on Raspberry?
> - check this sha1 sum against the dar backup on the x86_64

These backups were made by nightly automated scripts, which didn't save
the files on the source machine, but due to the wrapping in zstd and
gpg -- plus integrity checks at the transport layer -- I think
corruption in transit is highly unlikely.

> - test the backup on x86_64 (dar -t <backup>) using dar 2.7.2 ?

Same result as on the source.

You also asked about if there was any other output from dar prior to the
error.  There was only this line:

No terminal found for user interaction. All questions will be assumed a negative answ
er (less destructive choice), which most of the time will abort the program.

Thanks!

- John

>
> This should clarify whether the problem comes from dar or not.
>
>>
>> The extraction command was:
>>
>> dar --dirty-behavior no-warn --sequential-read -w -x - -R /bakfs/other-backups/dar/ada
>>
>> And it was generated with:
>>
>> Running dar -q -c - --aux /var/local/dar/1637242636 -A \
>> /var/local/dar/1637182897 -R /baksnap --empty-dir \
>> --retry-on-change 0 -P run -P tmp -P proc -P sys -P dev \
>> -P var/tmp -P var/cache/apt/archives -P media -P mnt \
>> -P cdrom -P var/cache/apt -P var/lib/mlocate -P var/lib/apt/lists \
>> -P var/log/journal -P var/spool/nncp -P var/local/dar \
>> -P var/cache/apt -P mythmount -P */no-backup -P home/*/.cache \
>> -P var/log/*log
>
> Thanks for that, I have no Rapberry board to test with, but I will check
> this configuration between a 32 bits and 64 bits Debian OS.
>
>>
>> There was no reference to var/log/sysstat at generation time, though I
>> did get a number of messages like this:
>>
>> SECURITY WARNING! SUSPICIOUS FILE /baksnap/var/spool/anacron/cron.monthly: ctime changed since archive of reference was done, while no other inode information changed
>> SECURITY WARNING! SUSPICIOUS FILE /baksnap/var/spool/anacron/cron.weekly: ctime changed since archive of reference was done, while no other inode information changed
>>
>
> This warning shows when you do differential backup and dar suspects file
> to have been modified with the intention to hide the modification...
> this is an heuristic that may give false positive. You can disable it
> adding the -asecu option on command-line, but in anycase it does not
> impact the backup content.
>
>> - John
>>
>>
>
> Cheers,
> Denis