You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In borg 1.x, there was the repository check and the archives check.
Repository.check fulfilled 2 main purposes:
do a low-level check of the segment file's entries (crc32-check against corruption)
IIRC, it always did rebuild the repository index (it had to read/parse all segment entries anyway)
for client/server mode (ssh: repo with server-side borg process), the repo check ran on the server side!
Archives check:
read all archives
check if all chunks referenced from archive metadata stream items are in the index
with --verify-data, actually read/verify all these chunks
borg2: quick routine check, no --repair
In borg2 with packs, we should adapt to packs and optimize for server-side processing. There is no borg process on the server side, but borgstore has a generic Store.hash method:
Use Store.hash() method and compute the sha256 of each pack - it needs to match the pack_id. The REST backend optimizes this call and runs the hash computation on the server without transferring pack data to the client. If it matches, we KNOW that the pack is not accidentally corrupted. Do this for all packs and then we are DONE if --repository-only is given.
When using partial check mode, remember up to which pack id we did it, so the next partial check can start from there.
For a full run (no --repository-only), it would next check the index/ namespace and check each index part also (again: Store.hash). If all index parts are ok, iterate over all archives, check if all chunks refer to actually existing packs.
borg2: something is damaged or missing, we need --repair!
reading all the packs takes a lot of time for big repositories, so we should avoid having to do it repeatedly.
doing that as an automated cronjob (borg check, read-only, maybe even time-limited, partial checks) is less bad though than doing it interactively (an admin, doing borg check --repair and waiting for the result)
repair: only repair what we already know is broken
if borg check would report bad packs in an easily reusable way, we could feed that into borg check --repair so it does not have to scan all the packs again, but only repairs the (likely few) packs given.
used that way, it would assume the index is ok and just update it, not completely rebuild it by scanning all packs
index repair
if borg check told us that the index is corrupted (or we inferred it because borg crashed because it did not find an object after following pack information from the [incorrect] index), we need to repair the index
in that situation, guess we have no choice but to scan over all packs to rebuild an index from scratch
but, important: we do not have to read (or sha256) the complete pack files. only read/seek over the linked metadata pieces to get only what we need for the index.
commands, options, naming
borg 1.x: it mixed checking and repairing (mostly because a lot of the code was shared)
borg 1.x: it only differentiated between the low-level repository checksum check and repository index rebuild (--repository-only) and the high-level archives check (--archives-only)
borg2: guess we need a better split, we could even have borg check being ONLY the read-only checks and a separate borg repair for all sorts of repairs and rebuilds.
borg2 repair could have misc. options, like --packs and --index to just repair these.
Activity
ThomasWaldmann commentedon Jun 26, 2026
@mr-raj12 Guess the non-repair part is done, right?
mr-raj12 commentedon Jun 27, 2026
yes, the non-repair part is already done and is now on master
#9794
#9783
#9789
only --repair is left
ThomasWaldmann commentedon Jun 27, 2026
big repository facts
borg check, read-only, maybe even time-limited, partial checks) is less bad though than doing it interactively (an admin, doingborg check --repairand waiting for the result)repair: only repair what we already know is broken
borg checkwould report bad packs in an easily reusable way, we could feed that intoborg check --repairso it does not have to scan all the packs again, but only repairs the (likely few) packs given.index repair
borg checktold us that the index is corrupted (or we inferred it because borg crashed because it did not find an object after following pack information from the [incorrect] index), we need to repair the indexcommands, options, naming
borg checkbeing ONLY the read-only checks and a separateborg repairfor all sorts of repairs and rebuilds.check: keep the records of corrupt packs across check cycles
check: keep the records of corrupt packs across check cycles
check: keep the records of corrupt packs across check cycles
check: keep the records of corrupt packs across check cycles
ThomasWaldmann commentedon Oct 5, 2026
Closing: the read-only and the repair parts are both in master now.
index/andpacks/are verified viaStore.hash(server-side forrest:/ssh://), the index first, and the read-only check never rebuilds the index — repository: read-only check by hashing pack/index objects #9794, repository: make check and delete work at N=1 with sha256 pack ids #9783, repository: always name packs by sha256(pack) #9789.cache/checked-packs;--max-ageskips packs with a fresh intact result — check: keep pack check results, add --max-age to reuse them #9925.--repairre-verifies and salvages the packs recorded corrupt, and with--max-ageit reuses the intact results of earlier (e.g. cron) checks instead of re-hashing every pack — check: --repair salvages the packs recorded corrupt, refs #10026 #10455, check: --repair reuses the intact pack check results within --max-age, refs #10026 #10464. Example:borg check --repository-only --repair --max-age=4wafter routine checks.salvage_packkeeps every object that still authenticates and drops the rest — repository: add salvage_pack, keeping only the authenticated objects of a corrupt pack, refs #10026 #10419, borg2 check: implement repository repair (index and pack rebuild) #10026.borg check --repair.The remaining check work (#10479, #2397, #9825, #10410, #10397, #6584) is tracked in #9998.