TW

BTW, as long as the chunk is logically deleted, it won't show as orphan. - PUT x, DEL x and nothing uses x == logically deleted, not an orphan -...

You could try this (it should decrypt and decompress as needed). It dumps ALL objects, so needs quite some space / time. ``` mkdir myrepo-dump cd myrepo-dump borg debug dump-repo-objs...

From the `borg check` docs: ``` In repair mode, when all the archives were checked, orphaned chunks are deleted from the repo. One cause of orphaned chunks are input file...

Yeah, guess that's right. Would be interesting to look at the plaintext of that chunk.

It's a bit hard to decipher due to the 16bit formatting with bytes swapped, but: ``` crc32 = 51fa3e63 len32 = 00000033 tag8 = 00 (PUT) id256 = 6b734ed388e7e086af7107847c6b6d3d34a29c20e7e539ded71b32606cb857bd compression...

It seems it is uncompressed data: ``` bytes.fromhex(d).decode() '\x00-0.328\n' ```

A theory how this could happen (see https://github.com/borgbackup/borg/issues/6687#issuecomment-1121333995): - borg check is ok - the repo loses the DEL somehow - the previously logically deleted chunk (which is not required...

@ams-tschoening maybe also some orphaned chunks due to errors when processing input files. You have a lot of debug msgs there, but for the repair I did not see the...

file-atomic is not enough. "complete or no change" would be best. In the end, it depends on the order of files being copied (and deleted), but I think this is...

OK, now I am curious: what led you to trusting borg's encryption more than restic's? I don't know these rsync options, but if the result is a 100% copy of...