[Borgbackup] "borg check --repair" problem

Thomas Waldmann tw at waldmann-edv.de
Sun Jul 26 16:17:06 EDT 2020


Hi,

> ID: 024126ba2e8883b2c36b505fa2217a80479e4334faa659b4a4ff09918e316a5c
> rebuilt index: <not found>      committed index: (417, 455027472)
>  ending with : "Completed repository check, errors found."

That means that your old on disk index ("committed") referred to chunks
which are not there any more in the on-disk segment files, from which it
built the rebuilt-index.

> I deleted the index for the repository and then did a "borg check
> --repair",  and, even though there was a warning that this was an
> experimental feature,

We are currently changing this message. Read it rather as "no
warranties" and "make a backup of the repo if it is important".

> I plan on deleting the 3 backups in the repository and hope for the
> best.  Is this a good plan?

After you check --repair the repo, you could run backups that have
(maybe) the same data as in these archives.

And then check --repair again. If you are lucky, borg will heal the
files IF the chunks that were gone have re-appeared due to the backups
after the first repair.

> Data integrity error: Segment entry checksum mismatch [segment 417,
> offset 33880751]

If that was after the index repair, it means corruption in a on-disk
file (segment file number 417).

> user-2020-06-30T18:02:21: FILE1: New missing file chunk detected (Byte
> 1497238-3698398). Replacing with all-zero chunk.

And that was maybe that corrupt chunk.

So, the root cause is unclear. Corruption can have multiple reasons,
like on-disk bit rot or defective RAM or ...

I assume you read the advisory at the top of the changelog of borg 1.1.13?

Cheers, Thomas

-- 

GPG ID: 9F88FB52FAF7B393
GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393


More information about the Borgbackup mailing list