mirror of
https://github.com/borgbackup/borg.git
synced 2024-09-11 12:36:12 +03:00
commit
8825bd961b
@ -171,8 +171,8 @@ The best check that everything is ok is to run a dry-run extraction::
|
||||
Changelog
|
||||
=========
|
||||
|
||||
Version 1.2.0a6 (not released yet)
|
||||
----------------------------------
|
||||
Version 1.2.0a6 (2019-04-22)
|
||||
----------------------------
|
||||
|
||||
Please note:
|
||||
|
||||
@ -218,6 +218,7 @@ Compatibility notes:
|
||||
Fixes:
|
||||
|
||||
- delete / prune: consider part files correctly for stats, #4507
|
||||
- fix "all archives" stats considering part files, #4329
|
||||
- create: only run stat_simple_attrs() once
|
||||
- create: --stats does not work with --dry-run, exit with error msg, #4373
|
||||
- give "invalid repo" error msg if repo config not found, #4411
|
||||
@ -237,6 +238,8 @@ Other changes:
|
||||
|
||||
- travis: use py 3.5.3 and 3.6.7 on macOS to get a pyenv-based python
|
||||
build with openssl 1.1
|
||||
- vagrant: use py 3.5.3 and 3.6.8 on darwin64 VM to build python and
|
||||
borg with openssl 1.1
|
||||
- pytest: -v and default XDISTN to 1, #4481
|
||||
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH BORG-BENCHMARK-CRUD 1 "2019-03-21" "" "borg backup tool"
|
||||
.TH BORG-BENCHMARK-CRUD 1 "2019-04-22" "" "borg backup tool"
|
||||
.SH NAME
|
||||
borg-benchmark-crud \- Benchmark Create, Read, Update, Delete for archives.
|
||||
.
|
||||
|
@ -1,6 +1,6 @@
|
||||
.\" Man page generated from reStructuredText.
|
||||
.
|
||||
.TH BORG-BENCHMARK 1 "2019-03-21" "" "borg backup tool"
|
||||
.TH BORG-BENCHMARK 1 "2019-04-22" "" "borg backup tool"
|
||||
.SH NAME
|
||||
borg-benchmark \- benchmark command
|
||||
.
|
||||
|
@ -100,6 +100,7 @@ First, the underlying repository data files are checked:
|
||||
- If you use a remote repo server via ssh:, the repo check is executed on the
|
||||
repo server without causing significant network traffic.
|
||||
- The repository check can be skipped using the ``--archives-only`` option.
|
||||
- A repository check can be time consuming. Partial checks are possible with the ``--max-duration`` option.
|
||||
|
||||
Second, the consistency and correctness of the archive metadata is verified:
|
||||
|
||||
@ -123,6 +124,16 @@ Second, the consistency and correctness of the archive metadata is verified:
|
||||
- The archive checks can be time consuming, they can be skipped using the
|
||||
``--repository-only`` option.
|
||||
|
||||
The ``--max-duration`` option can be used to split a long-running repository check into multiple partial checks.
|
||||
After the given number of seconds the check is interrupted. The next partial check will continue where the
|
||||
previous one stopped, until the complete repository has been checked. Example: Assuming a full check took 7
|
||||
hours, then running a daily check with --max-duration=3600 (1 hour) would result in one full check per week.
|
||||
|
||||
Attention: Partial checks can only do way less checks than a full check (only the CRC32 checks on segment file
|
||||
entries are done) and cannot be combined with ``--repair``. Partial checks may therefore be useful only with very
|
||||
large repositories where a full check would take too long. Doing a full repository check aborts a partial check;
|
||||
the next partial check will start from the beginning.
|
||||
|
||||
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,
|
||||
|
Loading…
Reference in New Issue
Block a user