You’re of course right, errors won’t just vanish. But I’ve already gone through an odyssey of fixing these errors and the last one has just been fixed by Kopia 0.18, yay! (If you feel like going into it, here and here are two of the posts about my issues.)
I think the errors stemmed from the Google Drive time of the repo, but I’m not sure. I also have no idea what might have caused them. I might have some missing files in my repo now if I’m not mistaken. But this is the best I have now, aside from throwing the backup history out the window.
The main motivation to move the repo again comes from me wanting to be able to run verification regularly, which is unfeasible using WebDAV (you helped me figure this out here). But since WebDAV is my only option (for now) for the offsite copy of my repo, I was going to follow the advice of having a local repo that is verified daily and then synced to the offsite location using WebDAV. I hope WebDAV will be good enough for that - so far it has actually worked really well for the daily backup run, just not for verification.
Now that I’m getting into the details, the full story is actually that my current repo still has all those 32179 errors. I had copied it over to an external hard drive to be able to experiment with that copy. The copy is now error free (see first paragraph above). But my actual repo is not.
So now I see two paths forward:
- bring the hard drive containing my current repo back in-house, fix all errors, and
repository sync-toit to the offsite location via WebDAV, or - bring the hard drive containing my current repo back in-house,
snapshot migrateit to a new repo on another local hard drive, andrepository sync-tothat new repo to the offsite location using WebDAV.
Path 2 would, if I understand @jkowalski correctly here, eliminate all errors in the process - basically by dropping (and hence missing) some files. Which my error fixing probably also does, doesn’t it?
Sorry, I tried to be succinct, but this long text is the best summary I came up with. 