Well, I’ve now had a successful run after the database repair but with the “Keep all” policy. (Though the GUI display showed a 4 second run duration while the summary report showed 4 hours…:
- Last successful run: Yesterday at 9:19 PM (took 00:00:04)
- EndTime: 4/22/2018 9:19:42 PM (1524449982)
BeginTime: 4/22/2018 5:20:47 PM (1524435647)
Duration: 03:58:55.1801161
Anyway, I’m pretty confident that the issue is related to problems compacting the older 7zip files (that I USED to use - I switched to zip after reading about the possible issues with 7z files) during the retention policy cleanup.
After a few more (expected successful) test runs, I’ll flip back to using a retention policy at which point I expect I will again:
- have LZMA errors during post-backup compacting
- have the jobs treated as FAILED due to the post-backup compacting errors
- have “Found n files that are missing …” errors if I again switch to a “Keep all” retention policy
- have working backups if I do a database repair to resolve the missing files errors and stay with the “Keep all” policy
If all that goes as expected, I may try Duplicati.RecoveryTool.exe recompress (as described below) just to see what happens.