Skip to content

borg2: improve borg check #9696

Closed
Closed

Description

@ThomasWaldmann

borg 1.x

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!

... to be continued ...

Activity

  1. ThomasWaldmann commented on Jun 26, 2026

    @ThomasWaldmann
    MemberAuthor

    @mr-raj12 Guess the non-repair part is done, right?

  2. mr-raj12 commented on Jun 27, 2026

    @mr-raj12
    Contributor

    @mr-raj12 Guess the non-repair part is done, right?

    yes, the non-repair part is already done and is now on master

    #9794
    #9783
    #9789
    only --repair is left

  3. ThomasWaldmann commented on Jun 27, 2026

    @ThomasWaldmann
    MemberAuthor

    big repository facts

    • 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.
  4. added this to the 2.0.0b23 milestone on Jul 2, 2026
  5. ThomasWaldmann commented on Oct 5, 2026

    @ThomasWaldmann
    MemberAuthor

    Closing: the read-only and the repair parts are both in master now.

    The remaining check work (#10479, #2397, #9825, #10410, #10397, #6584) is tracked in #9998.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions