Sorry if this question is stupid. I asked myself the following question:
Let’s say there is a system backing up via cron to a restic repository daily. It does a forget and prune also daily, keeping daily 14.
Lets also say that some pack files in the repo are damaged for whatever reason without someone noticing.
If now after some weeks with the daily changes on the source system and daily forget/prune on the repo, let’s say the damaged pack files one day are not needed anymore and get pruned.
The repo would be fine again.
Am I talking about a possible scenario?
Yes. If you are lucky. It is at the end pure statistics depending on usage pattern. But never forget about Murphy’s law
Anything that can go wrong will go wrong, and at the worst possible time.
There are no stupid questions, although sometimes there are stupid answers 
At this point a restore of files that depend on the damaged files will fail. restic cannot “heal” the repository.
The repo will be fine in terms of restoring files referencing any packs. However this is not what I would reference as healing.
The only way to “heal” the repository is to use a file system that can heal itself such as btrfs.
The best practice is to have multiple backups on multiple devices and preferably multiple locations.
1 Like
hello @betatester77,
interesting scenario, but if you assume this can happen often then your backup is not safe.
You make a backup to restore content in case of disaster / user error / whatever scenario that damages your original data. Unless you have another backup (redundancy) that you could use, it means you have a risk that your data can be lost forever.
It is up to you to decide the value of (losing) your data.
p.s. If you do not trust the repository backend you can monitor it with restic check --read-data which verifies the content against its checksum. Depending on your backup size and connection speed this can be a short or a very long operation.