Merge pull request #4521 from ThomasWaldmann/rel120a6

release 1.2.0a6
This commit is contained in:
TW 2019-04-22 18:12:27 +02:00 committed by GitHub
commit 8825bd961b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 18 additions and 4 deletions

View File

@ -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

View File

@ -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.
.

View File

@ -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
.

View File

@ -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,