Correct, it wasn’t a good test 
The reason is that on restic init, restic generates new encryption keys, despite the same password is used.
Right. I misunderstood “same password” – I took that to mean that he used the same keys when (rather obviously, in hindsight) he meant that he typed the same password which would have created a new key.
In that case, I’d assume that simply using restic init in a new directory and copying the config file to the broken repository would be sufficient to fix the problem (enough to recover data, assuming no other repository problems) without having to patch restic. (Unless the config is encrypted with the master key?)
Interesting to read all that.
If the config File is not that important and a restore of data without it is somehow possible, than it would be nice to have a workaround for such situations in future versions maybe.
That’s the case, so it isn’t so easy.
I put together a quick & dirty patch:
It writes a new config file:
$ go run build.go && ./restic check --no-cache --verbose
repository opened successfully, password is correct
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
no errors were found
I will test it with the real repository soon unless you see major problems with my patch @fd0 
.
I used it on my “live” repo and it worked, config is back. Bad news though that restic check detects numerous missing data files and I suspect it is yet again a case of restic “detecting” faulty hardware 
.
Thanks for your hints in this case @fd0, @betatester77, and @cdhowie!
2 Likes
A last-ditch effort would be to restic rebuild-index before running restic check, in case the files that are missing are indexes and not the actual packs.
@cdhowie Thanks, I tried that with not really encouraging results .
Btw. it was a nice experience to build restic myself (git clone … && go run build.go, wait 20 seconds and boom! done!). Navigating the source was nice and I loved seeing it well documented and nicely split to smaller chunks of code 
.
I/O error (probably on a write). This once happened to me, and I “lost” the config file. Or to be more accurate, I lost the directory entry for config, but the file’s critical contents still existed, there just wasn’t any way to obtain them.
This was on Linux, and after fixing the problem which caused the I/O error (loose cable connection), an fsck repaired the corrupted filesystem, restoring config. It probably helped I was using a journaling filesystem.
The mystery is why did an I/O error cause the lost of the config directory entry? Neither config nor the directory were being changed. One guess is that portion of the directory was contained in a sector(-group?) of the HDD that was being rewritten due to some other region of the sector-group legitimately changing. The old sector-group (with the config entry) was added to the journal but then the I/O error happened corrupting the sector-group. (The filesystem also then dropped off-line to prevent further damage, as was configured to happen.) The later fsck replayed the journal, restoring the config entry.
Since then, I’ve been trying to keep safe backups of all the config files!