I recently found out about Kopia, and I really like it so far. It combines usability and functionality in a nice package and ticks all the checkboxes.
One thing I particularly like is the ability to skip snapshotting when no data was changed. This feature is missing in many backup tools. When using frequent snapshot schedule, and then needing to restore, say, a deleted file, it would be time-consuming to go through all snapshots (imagine over 100 per day) in order to find the file. Or finding actually changed versions of the file.
However, there is one thing I donât understand about Kopia. My favorite test with backup tools is deleting a file at the destination and seeing what happens. When I did that with Kopia backup, it didnât detect anything. Upon reading documentation I ran âsnapshot verifyâ. It detected the missing blob. Good, but what do we do now? Subsequent snapshots happily take place without re-uploading the missing bits. The data is still there at the source. It should be a simple problem to fix.
There are several older discussions about the same issue, but no solution. I tried these (one at a time):
snapshot fix remove-files --object-id= --commit
snapshot fix invalid-files --verify-files-percent=100 --commit
It fixes the issue in terms of âsnapshot verifyâ no longer throwing errors, however, a) missing data is not uploaded, b) the next snapshot runs, after which âsnapshot verifyâ throws errors again, and rightfully so since the data is still missing.
I understand due to the nature of snapshots past snapshots wonât have the missing data. But surely there has to be a way to make Kopia back up missing data on the next run?
Kopia assumes the storage medium is stable and doesnât try uploading things it thinks it has completed successfully. There is no way to recover a blob from the repository. This missing blob may affect multiple files because Kopia is doing dedups
However, if the source is still available then you can tell kopia to check everything on its next snapshot. So something like âkopia snapshot create --force-hash=100â should make it rescan everything and upload the missing parts.
If it was truly gone then the solution would just be to delete the snapshot or let the snapshot age out.
Thank you for a quick reply. I just tried this command, and it didnât produce the desired outcomed. Even when running it wasnât showing enough data uploaded. Running âsnapshot verifyâ right afterwards shows the same âmissing blobâ error.
Do you have any other suggestions? It seems the only way is to wipe out the repository and start over. Even manually removing all snapshots and doing a new one with force-hash still didnât help. Kopia is just stuck thinking it has the missing blob no matter what I do.
I had the same problem: kopia snapshot verify reported a missing BLOB. I implemented a (proof-of-concept) recovery tool in Python that is able to recover missing or broken BLOB pack files. With that I was able to recover (i.e. regenerate) the missing BLOB file using the snapshotâs source directory (at least it worked for my case).
The tool is available at GitHub - patrsc/kopia-recover: Python tool to recover broken or missing kopia pack file BLOBs.
Thanks for sharing your tool. I stopped using Kopia since my last post here. I switched to restic + Backrest UI. Restic easily handled my test with deleted blobs, and I also found it better suited for my needs.
After hitting this problem several years ago I did these very same tests to see if things had improved. Not the case I see.
This is an unfortunate shortcoming of otherwise excellent kopia. An HDD developing a bad sector forcing you to throw away a full repo history is hard to accept.
If your repository is still missing data, then you can use the repair snapshots command to remove all inaccessible data from the snapshots. That is, this will result in a limited amount of data loss. Using the --forget option, the command will automatically remove the original, damaged snapshots.
Of course, it cannot recover data that is not there, no tool can do that. What I was referring to is the ability to back up data that is still present in the source location but was lost in the backup.
These simple steps did exactly what I would expect from a backup tool.
Delete some blobs in the backup destination.
Run this commands:
restic.exe check -r d:\test\restic
restic.exe repair index -r d:\test\restic
The next backup execution showed a warning about missing files but re-uploaded them. Problem solved.
Once again, if the data is lost in both source and target, no recovery is possible. However, if itâs lost in the backup, it should be easy enough to detect and back it up again. Kopia failed this same test when I posted the original message. With restic all I had to do was schedule a regular check with notifications so that I can address the issue if it arises.
Did you try to access or restore those files? I suspect that that silences Kopia about the missing data and broken snapshots, but it remains unavailable in newer snapshots.
Do you mean using restic? Yes, I did do a full end-to-end test with restoring data and doing a binary comparison to the original. If you are asking about Kopia, I tried every suggestion I could find in the manual or online. I donât remember exactly all the different things I tried back in 2024. Nothing worked.
I did my own tests and I need some help to understand the results. This is for kopia experts in this forum. Please help.
I created a kopia testrepo
I create an empty directory /data/datatmp/aaa for which I do the backup to the new kopia testrepo
I copied three files into the directory aaa . But after each file I created a snapshot. I ended up with 3 snapshots:
1st snap has only one file debian-13.1.0-amd64-netinst.iso
2nd snap has also ubuntu_cli_cheat_sheet_2025.pdf
and 3rd snap has also openBSD_install75.iso
# kopia snap list
root@rakete:/data/datatmp/aaa
2026-02-26 22:12:41 CET k7adbcdc292f46c80512da3b03feb966c 821 MB drwxr-xâ files:1 dirs:1 (latest-3)
2026-02-26 22:13:16 CET kb936d0dba18902ca9e8df2170a79fa21 821.2 MB drwxr-xâ files:2 dirs:1 (latest-2)
2026-02-26 22:13:51 CET k22751c4171ebb78d359e9f0e4bc75c06 1.5 GB drwxr-xâ files:3 dirs:1 (latest-1,hourly-1,daily-1,weekly-1,monthly-1,annual-1)
Interesting is, that the mounted repo still shows all three files. And I can retreive all 3 files and they match the original files. no diff.
This leaves me with a couple of questions:
Why are the files in the repo still correct? Specifically openBSD_install75.iso and debian-13.1.0-amd64-netinst.iso. They both have missing blobs.
I mounted each of the 3 snapshots and retrieved all files from the snapshots and nothing is missing and all files are accurate. No diff. How can that be?
Why is kopia snapshot verify --verify-files-percent=100 --file-parallelism=10 --parallel=10 not repairing anything?
What can I do to stop the error messages from the kopia verify command?
Well actually, there are some posts on this forum, which deal with corrupted data and invalid snapshots. The key is, that you run kopia snapshot veriy with the --commit flag, which will remove missing references to missing blobs and repair the snapshot manifests.
Just use the forumâs search and search for âinvalid-filesâ.
I did some more testing and I think this is a flaw in kopia compared to restic. It is very simple to reproduce and I would love to see some folks here trying to reproduce it.
create a test repo
create a source directory with just on bigger file to backup, e.g. in my case /data/datatmp/aaa/debian-13.1.0-amd64-netinst.iso
backup with kopia
remove a blob. If you happen to remove a blob from the repos manifest, the repo is broken and you have to repeat step 1-3 until you remove a blob that belongs to the file:
but this does not repair the file. Up to this point kopia and restic basically behave the same. The file is gone. It can not be repaired.
Here is the big difference between kopia and restic:
kopia: If I do another backup of the folder /data/datatmp/aaa, the correct file which is still in the folder is not put back into the repo. The backup keeps the corrupt file debian-13.1.0-amd64-netinst.iso forever. No further backup will change that.
restic: The next backup puts the correct file debian-13.1.0-amd64-netinst.iso back into the repo. And that also fixes the older snapshot. Old and new snapshot are clean now with the correct file.
Yes, thatâs the conclusion I arrived to when faced with this problem for the first time, and I think thatâs the general understanding of the issue once you dig a bit in similar threads. Kopia repairs âfixâ indices by removing the files with missing data and replacing them with a special filename, but those files are lost forever in that repo, in past and future snapshots.
Iâve been told in some github issue about it that kopia canât fix past snapshots because itâs kind of like a tape backup that can go only forward. Iâm unconvinced because then it wouldnât be able either to detect blobs are already there for deduplication of new files but, since I donât know the internals, I didnât press the idea.
But itâs true that the inability to recover, by design or by current lack of implementation, is a big shortcoming against restic, because it makes repositories very brittle. Itâs indeed the only reason Iâve moved my backups to restic.
Happy to be corrected on any of those points, wouldnât want to spread any misinformation.