borg [common options] check [options] [REPOSITORY_OR_ARCHIVE]
positional arguments | ||
REPOSITORY_OR_ARCHIVE |
repository or archive to check consistency of | |
optional arguments | ||
--repository-only |
only perform repository checks | |
--archives-only |
only perform archives checks | |
--verify-data |
perform cryptographic archive data integrity verification (conflicts with --repository-only ) |
|
--repair |
attempt to repair any inconsistencies found | |
--save-space |
work slower, but using less space | |
Archive filters — Archive filters can be applied to repository targets. | ||
-P PREFIX , --prefix PREFIX |
only consider archive names starting with this prefix. | |
-a GLOB , --glob-archives GLOB |
only consider archive names matching the glob. sh: rules apply, see “borg help patterns”. --prefix and --glob-archives are mutually exclusive. |
|
--sort-by KEYS |
Comma-separated list of sorting keys; valid keys are: timestamp, name, id; default is: timestamp | |
--first N |
consider first N archives after other filters were applied | |
--last N |
consider last N archives after other filters were applied |
The check command verifies the consistency of a repository and the corresponding archives.
First, the underlying repository data files are checked:
--archives-only
option.Second, the consistency and correctness of the archive metadata is verified:
--repository-only
option.The --verify-data
option will perform a full integrity verification (as opposed to
checking the CRC32 of the segment) of data, which means reading the data from the
repository, decrypting and decompressing it. This is a cryptographic verification,
which will detect (accidental) corruption. For encrypted repositories it is
tamper-resistant as well, unless the attacker has access to the keys.
It is also very slow.