I did some more testing and I think this is a flaw in kopia compared to restic. It is very simple to reproduce and I would love to see some folks here trying to reproduce it.
- create a test repo
- create a source directory with just on bigger file to backup, e.g. in my case
/data/datatmp/aaa/debian-13.1.0-amd64-netinst.iso - backup with kopia
- remove a blob. If you happen to remove a blob from the repos manifest, the repo is broken and you have to repeat step 1-3 until you remove a blob that belongs to the file:
# kopia snap verify
Listing blobs...
Listed 113 blobs.
Processed 0 objects (0 B). Read 0 files (0 B).
error processing root@rakete:/data/datatmp/aaa@2026-02-27 15:03:34 CET/debian-13.1.0-amd64-netinst.iso: object Ix311a92280fcaa16d6edddd502003342f is backed by missing blob peffa77dd5109f1ae3d2ba4907485053b-s4f4827054c679c4613e
Finished processing 2 objects (821 MB). Read 0 files (0 B).
object Ix311a92280fcaa16d6edddd502003342f is backed by missing blob peffa77dd5109f1ae3d2ba4907485053b-s4f4827054c679c4613e
If I mount the repo I can copy the file to /tmp and do a diff with the original source. There is a diff, which is expected.
kopia can repair the repo with:
kopia snapshot fix invalid-files --verify-files-percent=100 --commit
but this does not repair the file. Up to this point kopia and restic basically behave the same. The file is gone. It can not be repaired.
Here is the big difference between kopia and restic:
kopia: If I do another backup of the folder /data/datatmp/aaa, the correct file which is still in the folder is not put back into the repo. The backup keeps the corrupt file debian-13.1.0-amd64-netinst.iso forever. No further backup will change that.
restic: The next backup puts the correct file debian-13.1.0-amd64-netinst.iso back into the repo. And that also fixes the older snapshot. Old and new snapshot are clean now with the correct file.
For me that looks like a flaw in kopia.