Should I make a backup of my keyfile?

[goebbe]

There is a keyfile for each repository - which is crucial for accessing (encryption/decryption) the backups.

Do I understand correctly that, if this key file would be damaged or corrupted there would be no way to access/ restore the data of a repository?

• Should users of Vykar be encouraged to make a backup of their keyfiles?
• Or is Vykar guarding a second copy of the keyfile somewhere (just in case)?

[Shingedo]

I am also quite interested in this topic, but I think having to backup a backup would be a bit absurd.
But if I understand the current architecture correctly, then it is indeed a single point of failure, which seems like a bad idea. In a business/enterprise context, where other systems (like ZFS) guarantee integrity, this might be fine, but for a general backup tool, which will probably also be used unreliable storage (i.e. a single external HDD) which can have bit rot this seems ill advised.

Therefore I would argue that it (and similar important data) should at least be stored redundantly (i.e. using something like #194 or just multiple copies) since it adds absolutely neglible overhead, while providing redundancy for a rare, but catastrophic failure case.
And while having multiple remote repositories makes the situation a bit better, each of them would still be susceptible to this issue individually.

[m3nu]

Thanks for raising this. You’re right: today, keys/repokey is a single point of failure. The passphrase alone cannot recover the repository if that file is lost, and we should document this clearly.

I'm addressing it with:

• A second key copy inside the repository, created at init and added to existing repositories when opened. If one copy is damaged, vykar can usethe other.
• vykar key export and vykar key import, making it easy to save and restore the passphrase-protected key across all storage backends.
• Explicit key checks and repair through check and check --repair.
• Clearer error messages and documentation explaining key recovery and when a failure likely indicates an incorrect passphrase.

For now, I recommend copying keys/repokey somewhere outside the repository, such as your password manager. The second in-repository copy will help with localized corruption, but an external copy remains useful if both are lost.

Commit for this is coming shortly and will be in 0.20.1

[Shingedo]

Thank you for addressing this,
but how will you ensure that you know which of the 2 copies is the correct one and which is potentially corrupted?

And are keys the only single point of failure data or should this be generalised to more data in a repository?

[m3nu]

It will try both copies if they differ and see which one works. 😀

We can't duplicate all the data. So for other data individual files could be lost, but the rest of the repo repaired, if it's corrupted.

Additional resistance would need something like EC, as suggested here: #194

[Shingedo]

No I think you misunderstood me, what I meant was:
Is there more metadata that is a singular point of failure for a repository (like the key) that would be worth duplicating 1:1 to be safer. If there isn't, or the metadata could be rederived from the repository content, then that is good, but if there is, then it would probably be good to duplicate that data as well.

Nevertheless, I thought about the way the key is now stored redundantly and I am not sure, but since the same data is stored in two files now, I think that some filesystems could "silently" deduplicate this data so that effectively both files would point to the same physical block on disk. That would of course completely defeat the the purpose of the redundancy.

If we want to be really sure that this can't happen, then the second key shouldn't just be a copy of the first, but something that will definitely have different bytes. I first thought of just XORing the second copy with a non-zero constant but that still has a relatively "obvious" relation to the original, so a sufficiently complex deduplication could still pick this up.
Therefore the best idea would probably be to just encrypt the key another time with the same passphrase, but different randomness/nonces. Then the .2 key would almost certainly not be deduplicatable with the first in any way shape or form.

Checking and repairing would then of course also need to be aware of this seperate way of storage for the copy, but that should be easy.

[goebbe]

@Shingedo
Good point. E.g. when using btrfs as a file system, a simple cp would only create a new reflink to the already existing file. (there would still be only one physical copy of a file on the disk)
On btrfs one can use cp --reflink=never to force a physical copy of a file.
@m3nu I guess Rust provides low-level tools to force a physical copy of a file, if desired (as in this case)?
One (computational and conceptional) simple approach to force two physical different copies on disc could also be to save the copy of the keyfile as a (lzm4) compressed version of the original keyfile.

[m3nu]

I wouldn't want to overcomplicate this. If the second copy doesn't add much value in practice, better we remove it again. The real win is the key export command, which allows for a proper backup.

If other parts of the repo gets damaged, the rest can still be repaired. That's not true for the key.

[goebbe]

@m3nu Thank for looking into this and adding the feature for import/ export keyfile!

With regard to a copy of the keyfiles, why not opt for the middle ground?
Something like simply save a lz4 compressed copy of the keyfile, when generating a new keyfile?

My gut feeling tells me that educating users about doing backups of keyfiles (for their backups) might not always be successful.