Many borg users will use regularly scheduled borg create and borg check jobs to create and verify their backups.
If there is a lot of data in the repo, borg check will take a long time, but that should not be a problem because it runs unattended and also its runtime can be limited.
BUT, if there are issues with a repository (e.g. the check job detecting something), usually the repo admin will try to fix issues interactively and interactive operations should be fast.
That means:
- we should not need to run a full
borg check again (processing all packs / all objects in the repo)
borg check [--repair] should re-use intelligence that previous borg check runs have gathered (e.g. IDs of corrupt packs, IDs of corrupt or missing objects)borg create could have a special treatment (re-chunk them!) for paths of files that were noted as corrupted or containing missing chunks by borg check.
Many borg users will use regularly scheduled
borg createandborg checkjobs to create and verify their backups.If there is a lot of data in the repo,
borg checkwill take a long time, but that should not be a problem because it runs unattended and also its runtime can be limited.BUT, if there are issues with a repository (e.g. the check job detecting something), usually the repo admin will try to fix issues interactively and interactive operations should be fast.
That means:
borg checkagain (processing all packs / all objects in the repo)borg check [--repair]should re-use intelligence that previousborg checkruns have gathered (e.g. IDs of corrupt packs, IDs of corrupt or missing objects)borg createcould have a special treatment (re-chunk them!) for paths of files that were noted as corrupted or containing missing chunks byborg check.