It’s good start, however I’m not sure it’s much more thorough than the verification done before the backup.
If you decide you want to ensure pulling down all the files for a check against records, the test command would let you set as high a number as you like (or all). It can be run in a Commandline adapted for test
Verifying gently per-backup can be done with backup-test-samples or backup-test-percentage options.
Since you have upload-verification-file, the fastest way to check file integrity is on-remote-server script run using one of the DuplicatiVerify scripts in the Duplicati utility-scripts folder. I guess you use the Python one.
Nothing quite replaces a test restore of some sort. You should use no-local-blocks to guarantee download. Alternatively Direct restore from backup files on another machine can’t copy original source blocks, and it also has to create a partial temporary database, which proves that will work. If you really want to, a Repair after temporarily renaming your Database will let you see how it does. These are like DR tests in advance.
I think you can change it any time you like, however you’d have to measure the speed differences yourself. Heavier compression would presumably use more CPU but maybe upload slightly faster. What limits you?
Thank you for that. There are some rather experienced volunteers, but more (at any level) would help a lot.