Re: [Dar-support] Need help determining sliced archive corruption

[Denis C. <dar...@fr...>]

Le 27/05/2026 à 00:47, mannino a écrit :
> I have two different systems that back up data using incremental 
> archives. Those incremental archives (there's about 200 of them) are 
> fine according to dar -t. However, base (full) archives produced on both 
> systems at different times are reported as corrupted.
> 
> Adding -va to -t provides little insight into what's going on:
> 
>    # dar version 2.7.17
> 
>    Auto detecting min-digits to be 2
>    Opening archive aa ...
>    Opening the archive using the multi-slice abstraction layer...
>    Reading the archive trailer...
>    Final memory cleanup...
>    FATAL error, aborting operation: Unexpected value while reading 
> archive version

this means that the format version field is not properly formatted and 
dar cannot know which is the internal structure of the archive.

> 
>    # dar version 2.7.15
> 
>    Opening archive aa ...
>    Opening the archive using the multi-slice abstraction layer...
>    Reading the archive trailer...
>    Final memory cleanup...
>    FATAL error, aborting operation: Unexpected value while reading 
> archive version

same thing here

> 
> When creating archives, I don't use any fancy options, just -zgzip, -A/- 
> @ and -s/-E. I do have isolated catalogues in addition to the archives 
> themselves but adding -A to -t or -l doesn't change anything.

I have double checked the Changelog since version 2.7.17 to 2.7.21 
(latest of branch 2.7) and could not find any known bug that could 
explain this behavior, so its OK to keep 2.7.17 for further 
investigations. And you are not using complicated mix of options that 
could have gone through non-regression tests without a problem being 
reported.

> 
> Archives are stored on a separate machine; it's possible that a 
> corruption indeed took place when those archives were being transferred 
> from hosts but those hosts are different enough to make it unlikely that 
> that would happen to both at once.

that's a possibility: you can eliminate this possible cause by 
transferring --- exactly as you did for the backups --- any *binary* 
file (like /bin/bash for example) and transferring it back to the hosts 
*beside* its original copy (but do not overwrite it!!!), then check with 
'diff -s <original> <copy>' that the file are reported as identical.

> 
> I tried checking with strace to see what files dar -t opens. For both 
> archives, it starts with the last one in the directory, then opens some 
> seemingly random one in the 2/3rd of the set (I have ~30 and ~100 slices 
> so it opens the ~30th/~70th respectively), then after a bunch of seeks 
> it fails.

Weird, the archive version information is fetched very early in the 
archive reading process, if this field is corrupted, dar should open the 
last slice only and fail with the message you reported.

> 
> I tried -t -0. It resulted in an entry like so for 4 files:
> 
>    can't read data CRC: No escape mark found for that file
> 
> ...followed by this output:
> 
>    --------------------------------------------
>    1619434 item(s) treated
>    4 item(s) with error
>    0 item(s) ignored (excluded by filters)
>    --------------------------------------------
>    Total number of items considered: 1619438
>    --------------------------------------------
>    Final memory cleanup...
>    Some files are corrupted in the archive and it will not be possible 
> to restore them
>    +++ exited with 5 +++

the final error is probably because the archive has been interrupted or 
because the disk was full when it was created and dar was not in 
interactive mode (it was run from as a cron job, for example).

This would also explain why without -0 (--sequential-read) option dar is 
not able to find the archive version within a proper format, because 
this information is lacking at the end of the last slice.

But the data at the end of the archive seems having a normal terminator 
and slice trailer is present (else the error would have been different)...

The good thing however is that you should be able to restore 1619434 
files and directories from your backup using the --sequential-read mode.

> 
> No other errors were logged. None were logged for the first and last 
> slices.

When testing the backup in sequential-read mode (-0/--sequential-read 
option) could you add the following option:
	-E "echo reading slice %N"
and report the last slice being reported as being read by this added -E 
option, before the failure takes place?
Also could you tell me the number of the last slice available?

 > > Does it indicate that the archive is fine sans for 4 files' data? Then
> what's with that "Unexpected value" error in direct mode?

it indicates that before the data corruption (= Unexpected value) you 
can restore 1619434 files and directories and 4 entries (probably 4 
nested directories opened but not closed (?)) are reported as having an 
error.

Doesn't dar report the entry names of that 4 failed entries???

But pay attention: if your backup has been truncated or disk space was 
lacking (and you did not pay attention to the error message/exit code 
dar reported), you may lack much more files that could not be saved.

> 
> I also tried some combinations of -l and it really puzzled me.
> 
> -l alone; -l -q: fail just like -t.

this is normal, seen the reported error (corrupted archive format field)

> 
> -l -0: after some output, fails with Error while listing archive 
> contents: can't read data CRC: No escape mark found for that file

normal, it follows the same path as '-t -0' and fails for the same 
reason. The only difference is that it does not check crc of data and EA 
but skips over to reach the next metadata interleaved with the data, 
using so called "escape marks".

> 
> -l -q -0: fails with (???):
> 
>    Sorry, file size is unknown at this step of the program.
>    The last file of the set is not present in file:///, please provide it.

interesting, this gives weight to the scenario of the truncated backup...

> 
> Finally, I tried -al to no avail:
> 
>    LAX MODE: Failed to read the archive format version.
>    LAX MODE: Please provide the format MAJOR number: 11
>    LAX MODE: Please provide the format MINOR number: 3
>    LAX MODE: Using archive format "11.3"? [return = YES | Esc = NO]
>    Continuing...

OK so we dar continues as if the format field was correct

>    LAX MODE: Unknown compression algorithm used, assuming data 
> corruption occurred. Please help me, answering with one of the following 
> words "none", "gzip", [...] at the next prompt:gzip

This means that not only the archive format field is corrupted but also 
the compression algo field...

>    Unknown crypto algorithm used in archive, ignoring that field and 
> simply assuming the archive has been encrypted, if not done you will 
> need to specify the crypto algorithm to use in order to read this archive
>    Error met while reading archive of reference slicing layout, ignoring 
> this field and continuing
>    Aborting due to exception: Badly formed "infinint" or not supported 
> format

Here you could get one step further adding '-K none:' on command-line to 
tell dar that the archive was not encrypted (if it was not, of course).

> 
> One plausible cause is that I have mixed up the slices (lost or 
> duplicated some intermediate slices). It seems dar header can't help me 
> here (it doesn't store slice index) but other evidence suggests it's not 
> the case (`file *.dar` outputs the same label, slices' file sizes and 
> times look sane, etc.).

When you have mixed slices of different backups under the same basename, 
dar reports that. In each slice header is present an 'internal name' 
which is a random string based on the current time (UTC) computed at 
backup creation time. There is little chance (not to say no chance at 
all), that two different backups have the same internal name.

 From the first slice opened, dar record this internal name then 
compares it with subsequent slices it opens for that backup, if it does 
not match, dar stop and reports this inconsistency.

> 
> Is -t -0 guaranteed to catch the situation when slices are mixed up?

yes, this works the same (as explained just above) with and without -0 
option. And also, files will not be restored if the embedded CRC in the 
archive does not match the expected one (also stored in the archive).

> 
> For good measure, I tried -t'esting with dar 2.7.x and 2.8.x but results 
> were the same.
> 
> I really don't know what to make of this or what else to try.

You should be confident on the data you can restore from the backup when 
you use -0 option, but you must consider some data (maybe more than 
'some' and probably more than the 4 failed reported entries) are missing 
from this "full" backup.

Do you still have the isolated catalog of the full backups?

If so you could try the following command:
dar -t <backup> -A <isolated cat> -affs

the -affs is necessary because the last slice is obviously corrupted, 
this lead dar to read the archive header format and other important 
stuff from the copy located in the first slice. This option/feature was 
added in 2.8.x.

Doing so will give you an exact picture of the amount of data you are 
missing from your backup.

> 
> Any help on finding the cause for corruption is much appreciated.
> 

As you did differential backups after the full backup, it means that at 
that time the full backup was sane, else you would not have been able to 
create an isolated catalogue or to directly use the full backup as 
reference to build such differential/incremental backup, well except if 
you did an on-fly isolation and could find some available storage to 
have it written down.

If you are lucky, the missing files are not so much and/or most of them 
have a more recent version available somewhere in a differential backup. 
So you wish can get back most of your data.

Regards,
Denis