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

Selfhosted

61307 readers
505 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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

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

Questions? DM the mods!

founded 3 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.

you are viewing a single comment's thread
view the rest of the comments
[–] irmadlad@lemmy.world 6 points 5 months 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 5 months 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 5 months 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.