This is often the best way out. I usually advise people not to have Duplicati be the only backup of long-term file history that they would really hate to lose. I used to get the “Unexpected difference” too often, on a production backup of a not-too-critical system, and abandon-and-restart was my usual approach.
“Unexpected difference in fileset” test case and code clue #3800 seems at least 100x better after a fix.
Empty source file can make Recreate download all dblock files fruitlessly with huge delay #3747 was a problem where “empty source file” and “fruitlessly” are they key points. They didn’t make a backup file, due to a design change, but the recreate code hadn’t been changed, so it looked everywhere for them. The fix took care of the bogus search, but a legitimate search can still occur as part of recreate design.
Looking everywhere is still possible if a block mentioned in a dlist file is actually missing, and there’s no option yet to say “just give up on those files”, which is basically what a version delete does (aiming with little precision), however a missing block can be in several versions because deduplication reuses them.
If your progress bar gets in the 70% to 100% range, it’s fetching dblocks. The last 10% is the heaviest. Downloads and uploads both pass through –tempdir, and some SSD users point that to a RAM disk… Duplicati used to be bad about leaving temporary files behind (named dup-<GUID>) but it’s better now.
I sure hope so. You might want to monitor release notice feedback if you keep taking Canary releases, or just change Settings back to Beta (or Experimental as a pre-Beta) to avoid unexpected surprises…