I have a filesystem repository on a USB external hard drive that had some errors. I suspect a bumped cable. (I do plan to change this later.)
When I run kopia snapshot verify --verify-files-percent=100, I receive:
Processed 22199 objects.
ERROR unable to add 33142a2bc4e80c95d96fd49ed8862b61.0.3.0 to contents: can't get mod time for file "/var/cache/kopia/contents/33/142a2bc4e80c95d96fd49ed8862b61.0.3.0.f": stat /var/cache/kopia/contents/33/142a2bc4e80c95d96fd49ed8862b61.0.3.0.f: no such file or directory
Processed 22450 objects.
I have a S3 remote that I regularly sync-to, and my first thought was to reverse that sync. The first time I did so, it wanted to re-download almost the entire repository. I let that run, ran maintenance, and found the problem was still present. Doing it again now seems much more reasonable:
Source: S3: endpoint-redacted.com bucket-redacted
Destination: Filesystem: /home/backups/data/kopia
NOTE: By default no BLOBs are deleted, pass --delete to allow it.
Looking for BLOBs to synchronize...
Found 11815 BLOBs in the destination repository (269.6 GB)
Found 11933 BLOBs (269.8 GB) in the source repository, 268 (3.3 GB) to copy
Found 0 BLOBs to delete (0 B), 11665 in sync (266.5 GB)
However, this did not result in restoring the missing blobs.
When I tried using kopia repository repair filesystem --path ..., I received
looking for format blob...
format blob already exists, not recovering, pass --recover-format=yes
I have not lost any data on the source systems. I don’t need to restore (today…), but I want to bring the repository back into a clean state for the future.
How can I get the repository back into a clean state?
I’ve now also tried
kopia snapshot fix invalid-files --verify-files-percent=100 --commit
to no effect.
kopia snapshot verify --verify-files-percent=100
still shows a ton of
ERROR unable to add d816xxxxxxxxxxxxxxxxxxxxxxxx78ee.1100.3.0 to contents: can't get mod time for file "/var/cache/kopia/contents/d8/16xxxxxxxxxxxxxxxxxxxxxxxx78ee.1100.3.0.f": stat /var/cache/kopia/contents/d8/16xxxxxxxxxxxxxxxxxxxxxxxx78ee.1100.3.0.f: no such file or directory
and yet running fix invalid-files again shows the same errors and leaves the snapshots unchanged.
Why would the repository still be trying to reference invalid objects after they were removed from all snapshots? Why is fix invalid-files both encountering missing objects and not stubbing them out as requested?
Well, I get the same errors, while verification:
ERROR cache unable to add f692fc351f8e0755ddb4827fb5cdaf90.1100.2.0 to contents: can’t get mod time for file “C:\Users\xxx\AppData\Local\kopia\05e5535357e49791\contents/f6/92fc351f8e0755ddb4827fb5cdaf90.1100.2.0.f”: CreateFile C:\Users\xxx\AppData\Local\kopia\05e5535357e49791\contents/f6/92fc351f8e0755ddb4827fb5cdaf90.1100.2.0.f: The system cannot find the file specified.
ERROR cache unable to add 27b174791e77a6a598304cd2ae1c8f6a.1100.2.0 to contents: can’t get mod time for file “C:\Users\xxx\AppData\Local\kopia\05e5535357e49791\contents/27/b174791e77a6a598304cd2ae1c8f6a.1100.2.0.f”: CreateFile C:\Users\xxx\AppData\Local\kopia\05e5535357e49791\contents/27/b174791e77a6a598304cd2ae1c8f6a.1100.2.0.f: The system cannot find the file specified.
But what it means exactly, I’m not sure. Something with cache (?) because those missing (?) files are in the local cache directory.
If the files exist for you, it may not be the same problem I have.
If your repository is not otherwise corrupt, try deleting your cache and seeing what happens.
I find it odd that it switches from windows \ path separators to linux / ones half-way though. I wonder if that’s related/expected.
Repository seems to be OK. Apart of those errors, nothing else happens. Repository sits on the usb, so cache is always created from scratch before backup/verification.