To download the whole backup could take awhile, which is an issue any way you do it because having files change underneath the verification is a good way to get some complaints about the files that are verified…
backup-test-samples and the below can boost the testing after every backup (as an alternative).
Backup Test block selection logic describes the method, which tries to avoid an all-at-once test,.
--backup-test-percentage (Integer): The percentage of samples to test after
a backup
After a backup is completed, some (dblock, dindex, dlist) files from the
remote backend are selected for verification. Use this option to specify
the percentage (between 0 and 100) of files to test. If the
backup-test-samples option is also provided, the number of samples tested
is the maximum implied by the two options. If the no-backend-verification
option is provided, no remote files are verified.
* default value: 0
Great. BTW I was having second thoughts on Python 3 before checking availability on old LTS releases.
I know I had to specifically install the end-of-life Python 2 on my rather recent test system, but it existed.
This is actually a great practice, as it proves that it can be done in a timely manner. One can seemingly have a perfectly “intact” (meaning good hashes) set of destination files that can’t actually achieve that…
Large backups with default 100 KB blocksize can surprise people, but at least that’s predictable (but too late sometimes because it’s a one-time setting at first backup), but other inconsistencies can cause the entire backup to be read, instead of just dlist and dindex files. This is also often a futile search for data…