Unexpected difference in fileset version 5: 7/28/2024 12:35:16 AM (database id: 603), found 868530 entries, but expected 868531 Unexpected difference in fileset version 4: 7/30/2024 12:25:17 AM (database id: 605), found 868622 entries, but expected 868623 Unexpected difference in fileset version 2: 8/1/2024 12:30:08 AM (database id: 607), found 868708 entries, but expected 868710 Unexpected difference in fileset version 1: 8/3/2024 12:27:54 AM (database id: 609), found 868739 entries, but expected 868741 Unexpected difference in fileset version 0: 8/4/2024 12:26:02 AM (database id: 610), found 868751 entries, but expected 868753
It’s interesting that version 3 did not get the error. Usually the way this gets fixed is by deleting the damaged versions. I might have heard a developer say they now know the cause, but I’m unsure.
The DELETE command can probably be run most easily in GUI Commandline. Delete the source paths and add version either from the dropdown or right in the now-empty box, e.g. --version=0 which always means the latest one (version numbers change as backups are created or deleted).
version is documented as taking some fancy multi-version syntax if you want to see if that will run.
I don’t know if I picked the best order, but I started with the highest version (5), deleted it and reran the backup. That backup failed reporting 4 as the highest issue. I repeated each time deleting the highest one, and re-running the backup. Finally only 0 was left, I deleted that and then the backup ran successfully.
Did I do this in the right order, or should I have started with 0, or does it matter?
I don’t think order matters as long as you get them all. Deleting from high to low as you did at least keeps them from renumbering themselves after your delete, e.g. if you delete 0, former 1 is now 0.