[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