This feature allows multiple repositories to share deduplication-relevant secrets (id_key and chunk_seed) while maintaining secure, independent encryption keys.
`borg key export-related-secrets <REPO> <SPATH>` to export the secrets to a JSON file.
`borg init --import-related-secrets <SPATH> <REPO>` to initialize a new repository using the secrets from the JSON file.
Both repositories must use the same chunk id algorithm (both HMAC-SHA256 or both BLAKE2b).
If you create related repositories with borg 1.4.x, you can later transfer their archives
to one or multiple related new borg2 repositories without breaking deduplication.
But please note that we might remove BLAKE2b support for new borg2 repos, see #8867,
so this might only work for HMAC-SHA256 in the end.
Add `--quick-stats` to `borg create` and `borg import-tar`.
This is a lightweight alternative to `--stats`: it prints the existing
per-archive statistics, but skips repository-wide cache statistics such as
"All archives" and the chunk index summary. Those repository-wide stats can be
slow because they may require walking archive metadata.
Keep existing `--stats` and `--json` behavior unchanged.
With `--json --quick-stats`, emit archive stats but omit the top-level `cache`
object so JSON output does not trigger cache stats calculation.
Reject `--stats --quick-stats` as ambiguous. Ignore `--quick-stats` with
`--dry-run`, matching the existing `--stats` dry-run behavior.
Consolidate key backup documentation into `borg key export` and reference
it from Quickstart and FAQ to avoid duplication and inconsistency.
Clarify that while `repokey` or `authenticated` mode stores the key in the
repo, a separate backup is still recommended to protect against repository
corruption or data loss.
Added a small proof of concept for a pull mechanism implementation.
Works fine for simple test cases, but probably needs many improvements
to be useful for more complex usage scenarios.
when borg mount is used without -f/--foreground (so that the FUSE
borg process was started daemonized in the background), it did not
display the rc of the main process, even when --show-rc was used.
now it does display the rc of the main process.
note that this is rather a consistency fix than being super useful,
because the main "action" happens in the background daemon process,
not in the main process.
use borg diff --sort-by=spec1,spec2,spec2 for enhanced sorting.
keep legacy --sort behaviour (sort by path) for compatibility,
but deprecate it.
Co-authored-by: Daniel Rudolf <github.com@daniel-rudolf.de>
control how borg detects whether a file has changed while it was backed up, valid modes are ctime, mtime or disabled.
ctime is the safest mode and the default.
mtime can be useful if ctime does not work correctly for some reason
(e.g. OneDrive files change their ctime without the user changing the file).
disabled (= disabling change detection) is not recommended as it could lead to
inconsistent backups. Only use if you know what you are doing.
- Mention zstd as the best general choice when not using lz4
(as often acknowledged by public benchmarks)
- Mention 'auto' more prominently as a good heuristic to improve
speed while retaining good compression
- Link to compression options
(cherry picked from commit f656f6b1f2)
