Running KopiaUI and Kopia Repo Server on same PC

I think I managed to corrupt my repository by using or configuring Kopia wrong. I have Kopia Repository Server running on Windows connected to my local file system. I also have KopiaUI running and connected to the Repo Server. I realized that both the Repo Server instance and the KopiaUI instance were running the same snapshots at the same time. I ran the command:

kopia snapshot fix invalid-files --verify-files-percent=100

On my 3.6TB repository and it found quite a few corrupt files. About 78 files or so. It seems to be mostly large files that got corrupted. I forgot the –commit flag though so I have to run it again. But I guess my question really is, since Kopia is going to remove the invalid files, once the snapshot runs again will the invalid files be re-snapshotted or do I need to trash this repo and start over?

Sample invalid file output below:

removing invalid file External SD/DCIM/Camera/20210905_174147.mp4 due to: error reading object Ixff75ed3b79dd817507acac3fbd0d1c25: unable to read data: unexpected content error: invalid checksum at p464eaf59ff516fb6ea979cba93c2306a-s710b97a37ddc7f7a13b offset 20483934 length 8388636/8388636: decrypt: unable to decrypt content: cipher: message authentication failed

For future me and/or others, after much trial and error I finally figured out what I need to do to get the Kopia Repo server and Kopia UI to play nice with each other. I added a new user to the Kopia repo server with a different hostname than the one I use to run snapshots. So, instead of user@mycomputer I added a user called system@reposerver-mycomputer. I had to use a different hostname and not just a different username, otherwise, the repo server would try to execute the snapshots.

Then I assigned the system@reposerver-mycomputer as the maintenance user. So far, this seems to be working ok and the repo server no longer tries to run backups at the same time as KopiaUI. I think I will need to re-create the repo though as there are quite a few corrupted blobs that the built-in commands didn’t fix.

Following up further on this saga, I’ve narrowed the corruption problem down to what I believe to be a buggy/failing SATA controller or SATA cable. Right now I am leaning heavily towards it being the SATA controller unfortunately since it appears to be two drives that are affected.