this post was submitted on 13 Feb 2026
47 points (100.0% liked)

Selfhosted

56402 readers
905 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

I'm planning to setup backup on my nas with the 3-2-1 backup rule.

For the backup disks I want full disk encryption, but I also want to be really sure that I don't lose the encryption keys if I lose my phone and computer where I have my password manager.

What is a good practice to store the encryption key(s)?

One thought I had was to have an unencrypted partition on the backup disks that stores an encrypted keepass database with the key.

Any tips or experiences are welcome.

PS. I want to avoid cloud-based options.

top 16 comments
sorted by: hot top controversial new old
[–] noodNinja@sh.itjust.works 1 points 18 hours ago

A dumbass question maybe - Is this what the "keys" category in Bitwarden is meant for? I always thought it was for SSH related keys. I don't encrypt by backup HDD as I don't really care but this is kind of a good idea.

[–] linuxguy@lemmy.gregw.us 25 points 1 day ago (2 children)

If you're using LUKS don't forget you can dump/backup the header. It isn't the encryption key but is critical if you accidentally do a stupid. As to the keys themselves, how about convert them to qr codes, print them, and store them in a safe.

[–] irmadlad@lemmy.world 9 points 1 day ago

convert them to qr codes,

Never crossed my mind, but that's a good idea. Might have to implement that on my next rotation.

[–] nullroot@lemmy.world 1 points 1 day ago

This is smart.

[–] lorentz@feddit.it 15 points 1 day ago (1 children)

A chain is as strong as its weakest link. If you store your encryption keys in plain text in an unencrypted partition you are not very resilient against an attack.

There is no general advise for security, you always have to frame it in a treat model. What do you use encryption to protect for?

If you want to be able to safely dispose the drives without having to wipe them, storing the keys in a different drive (not partition) could be good. If you want to protect your data against physical thief, storing the decryption keys in plain text in the same server doesn't make sense.

If you want to protect by a state sponsored actor, keep in mind https://xkcd.com/538/

Something you have to consider is how likely your drives and your encryption keys can be stolen together. How quickly you can realize that only one of them got stolen, and how quickly you can protect the other one to keep you data safe.

A simple approach could be: print them down and put them in a safe box, maybe at a trusted relative or friend's home. But again, it boils down to what do you want to protect most, because there is no definitive answer to your question

[–] lorentz@feddit.it 5 points 1 day ago

Also, keep in mind that really good passwords can be easy to remember or recover. Pick your favourite book at home, get the last word of the first 10 chapters and put all of them together. You get a password that is impossible to bruteforce, literally written in your home but impossible to guess for anyone else but you. Of course it won't be easy to type. But is still a good main password for a password manager which stores all the others.

[–] bacon_pdp@lemmy.world 5 points 1 day ago

Buy a physical safe. Encrypt a flash drive using a 128bit pass phrase that you memorize.

Combine with a ubikey storing a 256bit password that is stored somewhere hard to get to

I don’t do full disk encryption on my backups. I use duplicity and encrypt the backups with three gpg keys: one that is for the IT department with a known passphrase, one for the business with a different known passphrase, and my personal key.

I’m a one man show but I set this up with the future in mind. Different data might not have all three keys, but this arrangement allows me to spin off bits of the data management as needed. The passphrases can be changed as/when needed without invalidating old backups.

Combined with ssh certificates it helps organize my IT needs.

[–] irmadlad@lemmy.world 4 points 1 day ago (1 children)

For the backup disks I want full disk encryption

I encrypt everything.

I have a repository set up with all my keys for all my encrypted drives. The keys get rar'd with a strong, known, 50 character password, and the filenames encrypted so no one can just open the rar file and gaze at the keys.

  • drive_xxxxx1_2_14_26.rar
  • drive_xxxxx2_2_14_26.rar
  • drive_xxxxx3_2_14_26.rar

These get backed up in a 3,2,1 schema, and also to thumb drives stored in secure places. I also rotate the passwords on a regular basis, so the process starts all over again.

  • Check keys: sudo cryptsetup luksDump /dev/sdX
  • Add new key: sudo cryptsetup luksAddKey /dev/sdX
  • Delete old key: sudo cryptsetup luksRemoveKey /dev/sdX
  • Verify keys: sudo cryptsetup luksDump /dev/sdX

The headers are not secret. Anyone with physical, read access to the device can run luksDump. It reveals algorithm, key derivation parameters, number of keys, but not the passphrase or master key.

As far as 'best practice', that will be determined by subsequent replies to your post. LOL That's just how I do it.

[–] ki9@lemmy.gf4.pw 3 points 1 day ago (1 children)

You can dettach your headers with --header.

I've started putting the header and key on my boot partition on a USB key. Without the usb, the hard drives appear to be filled only with random data (plausible deniability). After booting, the USB can be removed to prepare for a panic shutdown.

[–] irmadlad@lemmy.world 1 points 1 day ago

You can dettach your headers with --header.

I did not know this. That would seem, abiding by your system, to be more secure. I will have to investigate.

Thanks for sharing.

[–] ki9@lemmy.gf4.pw 3 points 1 day ago

I also want to be really sure that I don’t lose the encryption keys if I lose my phone and computer where I have my password manager.

Keep a copy on your (PIN-secured) phone and a copy on your PC and dont lose both at the same time.

[–] istdaslol@feddit.org 1 points 1 day ago

Have you tried printing it out ? For a last ditch effort it’s actually good, as the physical attack vector isn’t that high for home users.

[–] sharuum@piefed.social 2 points 1 day ago

Write in on a post-it/piece of paper you keep near your PC

[–] observantTrapezium@lemmy.ca 1 points 1 day ago

Personally I don't go with full disk encryption for backups. I use Borg that encrypts its repositories on a plain ext4 partition, and the key is saved in the config file (wrapped in passphrase of course). Obviously it just moved the problem of what to do with the passphrase... I also have Vaultwarden (with a separate backup mechanism).

[–] IanTwenty@piefed.social 0 points 1 day ago

Don't encrypt the drive, encrypt the backups and put your keepassdb alongside. Use restic or similar that encrypts backups.