Re: [Dar-support] dar creating corrupted archives

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

Le 16/12/2025 à 09:05, Paul Neuwirth via Dar-support a écrit :
> affected/installed dar versions: dar-2.7.12-bp156.1.4 and
> dar-2.7.15-bp160.1.3 from official openSUSE repositories
> openSUSE Leap 15.6 and openSUSE Leap 16.0
> 
> Hello,

Hi,

> dar (on some of my backups, not all) creates corrupted archives:
> 

First, thanks for your feedback!

I have checked the Changelog since 2.7.12 was released, in case a known 
bug would have been fixed in that area, but could not find anything 
obviously relevant.

Version 2.7.12 is not very recent (Octobre 2023, latest are 2.7.19 and 
2.8.2) but this is not a problem to keep using it for the 
investigations. However what I wonder is what the "-bp156.1.4" suffix in 
the version name means in term of patching applied by Suse...

> ls and dar -t output (dar -l same output)
> # ls -l backup-roothome*
> -rw------- 1 root root       30 15. Dez 10:14 backup-roothomeDataBase
> -rw------- 1 root root 28427612 15. Dez 10:14 backup-roothomeFull.1.dar
> -rw------- 1 root root       68 15. Dez 10:14 backup-roothomeFull.1.dar.sha1
> -rw------- 1 root root    40873 15. Dez 10:14 backup-roothomeFull.cat.1.dar
> -rw------- 1 root root       72 15. Dez 10:14 backup-roothomeFull.cat.1.dar.sha1
> (0)(0)xxx:/backup # dar -t backup-roothomeFull
> Final memory cleanup...
> FATAL error, aborting operation: Cannot open catalogue: incoherent catalogue structure
> (2)(0)xxx:/backup # dar -t backup-roothomeFull.cat
> Final memory cleanup...
> FATAL error, aborting operation: Cannot open catalogue: incoherent catalogue structure
> 
> checksums are ok.

so this is not likely a file system issue nor a disk issue

> 
> exact command run:
> dar   -c /backup/backup-roothomeFull -@ /backup/backup-roothomeFull.cat
> -R //.localbackup-snapshots/localbackup-20251215-100708 -zbzip2:9 -m 0
> -v -D -N -w -Q --hash sha1 --user-comment '%h %d %c' --retry-on-change
> 3 -g"root" -P "*/.Trash*" -P ".Trash*" -P "*/.mozilla/*/[Cc]ache" -P
> "*/.opera/[Cc]ache*" -P "*/.pan/*/[Cc]ache" -P "*/.thumbnails" -P
> "*/.beagle" -P "root/.opera/" -P "root/.cache/" -P
> "root/clamav-quarantine/"  -an -Z "*.dar" -Z "*.crypt" -Z "*.arj" -Z
> "*.bz2" -Z "*.bz" -Z "*.Z" -Z "*.tgz" -Z "*.taz" -Z "*.cpio" -Z "*.deb"
> -Z "*.gtar" -Z "*.gz" -Z "*.lzh" -Z "*.lhz" -Z "*.rar" -Z "*.rpm" -Z
> "*.shar" -Z "*.sv4cpi" -Z "*.sv4crc" -Z "*.ustar" -Z "*.zoo" -Z "*.zip"
> -Z "*.jar" -Z "*.jpg" -Z "*.gif" -Z "*.mpg" -Z "*.mpeg" -Z "*.avi" -Z
> "*.ram" -Z "*.rm" -Z "*.7z" -Z "*.xz" -Z "*.lz" -Z "*.lzma" -Z "*.lz4"
> -Z "*.zst" -Z "*.txz" -Z "*.tbz" -Z "*.tbz2" -Z "*.apk" -Z "*.war" -Z
> "*.msi" -Z "*.cab" -Z "*.pkg" -Z "*.snap" -Z "*.jpeg" -Z "*.jpe" -Z
> "*.png" -Z "*.webp" -Z "*.tif" -Z "*.tiff" -Z "*.mp3" -Z "*.ogg" -Z
> "*.oga" -Z "*.opus" -Z "*.flac" -Z "*.m4a" -Z "*.aac" -Z "*.wma" -Z
> "*.mp4" -Z "*.m4v" -Z "*.mkv" -Z "*.mov" -Z "*.wmv" -Z "*.flv" -Z
> "*.webm" -Z "*.docx" -Z "*.xlsx" -Z "*.pptx" -Z "*.odt" -Z "*.ods" -Z
> "*.odp" -ac
> 
> (/.localbackup-snapshots/localbackup-20251215-100708/ in this case is
> a btrfs snapshot created by my backup script of the root filesystem)

btrfs and snapshot is not a problem, they appear to dar as normal 
filesystem to backup.

This is more the filesystem where dar backups are stored that are of 
interest here, which one it is?

> 
> dar returned 0, suggesting success, its output:
> No user target found on command line
> The following user comment will be placed in clear text in the archive:
> theta Mon Dec 15 10:07:13 2025 "dar" "-c" "/backup/backup-roothomeFull"
> "-@" "/backup/backup-roothomeFull.cat" "-R"
> "//.localbackup-snapshots/localbackup-20251215-100708" "-zbzip2:9" "-m"
> "0" "-v" "-D" "-N" "-w" "-Q" "--hash" "sha1" "--user-comment" "%h %d
> %c" "--retry-on-change" "3" "-groot" "-P" "*/.Trash*" "-P" ".Trash*"
> "-P" "*/.mozilla/*/[Cc]ache" "-P" "*/.opera/[Cc]ache*" "-P"
> "*/.pan/*/[Cc]ache" "-P" "*/.thumbnails" "-P" "*/.beagle" "-P"
> "root/.opera/" "-P" "root/.cache/" "-P" "root/clamav-quarantine/" "-an"
> "-Z" "*.dar" "-Z" "*.crypt" "-Z" "*.arj" "-Z" "*.bz2" "-Z" "*.bz" "-Z"
> "*.Z" "-Z" "*.tgz" "-Z" "*.taz" "-Z" "*.cpio" "-Z" "*.deb" "-Z"
> "*.gtar" "-Z" "*.gz" "-Z" "*.lzh" "-Z" "*.lhz" "-Z" "*.rar" "-Z"
> "*.rpm" "-Z" "*.shar" "-Z" "*.sv4cpi" "-Z" "*.sv4crc" "-Z" "*.ustar"
> "-Z" "*.zoo" "-Z" "*.zip" "-Z" "*.jar" "-Z" "*.jpg" "-Z" "*.gif" "-Z"
> "*.mpg" "-Z" "*.mpeg" "-Z" "*.avi" "-Z" "*.ram" "-Z" "*.rm" "-Z" "*.7z"
> "-Z" "*.xz" "-Z" "*.lz" "-Z" "*.lzma" "-Z" "*.lz4" "-Z" "*.zst" "-Z"
> "*.txz" "-Z" "*.tbz" "-Z" "*.tbz2" "-Z" "*.apk" "-Z" "*.war" "-Z"
> "*.msi" "-Z" "*.cab" "-Z" "*.pkg" "-Z" "*.snap" "-Z" "*.jpeg" "-Z"
> "*.jpe" "-Z" "*.png" "-Z" "*.webp" "-Z" "*.tif" "-Z" "*.tiff" "-Z"
> "*.mp3" "-Z" "*.ogg" "-Z" "*.oga" "-Z" "*.opus" "-Z" "*.flac" "-Z"
> "*.m4a" "-Z" "*.aac" "-Z" "*.wma" "-Z" "*.mp4" "-Z" "*.m4v" "-Z"
> "*.mkv" "-Z" "*.mov" "-Z" "*.wmv" "-Z" "*.flv" "-Z" "*.webm" "-Z"
> "*.docx" "-Z" "*.xlsx" "-Z" "*.pptx" "-Z" "*.odt" "-Z" "*.ods" "-Z"
> "*.odp" "-ac"

[...]

> 
> everything looks fine besides these "Failed resaving uncompressed
> the inode data", but the created .dar files are unusable!?

Then "Failed resaving uncompressed" are effectively weird:
- when a compressed file takes more space than its uncompressed size, 
dar truncates the dar backup to the location where the backup for that 
file was starting and then restart the backup without compression that 
particular file.

Either truncate() system call failed, or something in the lower libdar 
layers (caching layer, here there is no slicing so this is even simpler)

Can you try reading/testing the corrupted backup in sequential read mode 
(add --sequential-read option when testing the archive)?


> I have the same problem on 2 different computers/servers with the above
> mentioned versions/distributions for two different backups (one machine
> backup /root/ false, on the other backup /etc/ fails (same Failure
> mode).

this good that the problem is reproducible, it will be easier to 
understand and fix.

> Never had the issue before. I created a new backup script, which runs
> fine on an older install and dar-2.4.18-2.3. and deployed it after
> much testing to other machines. what essentially changed from before
> is compression (from gzip to bzip2) and the use of btrfs snapshots.

at current point of investigation I would not target at btrfs (as source 
of the backup). Compression and resaving uncompressed are the most 
probable cause of the problem, though this is something that exists for 
long and used by may users... but who knows.

> It happens both with -c and -A (differential to older, not-corrupted
> Full-backup)

yes, this is not related to what to decide to backup but how the 
selected data to backup is stored/compressed on filesystem.

> 
> Do you have any idea? consulting search machines and chatGPT didn't
> result in anything useful.

Well ChatGPT is good to make relations between existing information and
find the statistical most probable answer... but not to investigate nor
to solve problems that no one else ever met so far ;)

My suggestions (ChatDenis's suggestions):

1/ Could you try reading in sequential read mode (add --sequential-read 
option when testing the archive)?

2/ Could you use the official 2.7.19 dar_static version to build your 
backup.
https://dar.edrusb.org/dar.linux.free.fr/Releases/Dar_static/

We will see the next step with the result of these two suggestions.

> 
> Thank you,
> 
> Paul
> 


Cheers,
Denis