Thank you for your response. Perhaps I should have clarified my use case. I have data which is potentially legally privileged and which I also cannot afford to lose. Thus an unencrypted backup is out of the question, and my first thought was to use full-disk encryption for the backup.
Perhaps header is the correct term rather than metadata. Both LUKS (see, e.g., https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf, p. 2) as well as FreeBSD’s GELI (see the man page, e.g. https://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html) use on-disk metadata (for LUKS, I understand this includes e.g. salt values, I presume it is similar for GELI), and both systems provide explicit methods for backing up this metadata. I presume that OpenBSD also writes on-disk metadata of the same sort somewhere. Where? I know I could dig this out of the source code but I don’t have time right now. As it stands, the documentation gives no hint that softraid crypto gives any additional risk of data loss. If there are in fact e.g. salt values written in an unknown location on the disk, whose loss renders THE ENTIRE DISK cryptographically inaccessible, surely this ought to be documented somewhere? I understand that there are use cases where it would be better for the data to be lost entirely than to be disclosed to the wrong people. But this is not true in every use case. While I agree with you that there are definite security risks in backing up such metadata, surely the decision as to what to do ought to be left to the end user, rather than being enforced by lack of documentation? Thanks! Nathan On 1/2/23 23:54, Nathan Carruth wrote: > Thank you for the response. > > I am with you 100% on backups. My real question was, How > does one backup crypto volume metadata? Given that > it can be backed up, clearly it should be, but there is no > information in any of the cited documentation as to where > the metadata is or how to back it up. There appears to be no intended way to backup this crypto metadata you are worried about. Not that I'd really want extra copies of anything related to a crypto disk floating around anywhere if I could help it. Not sure what you are hoping to get "backed up", but it sure sounds like something useful to the wrong people. Encrypted disks are supposed to "fail closed". If that scares you, your backup sucks or you shouldn't be running encrypted drives. (well...you COULD # dd bs=1m if=/dev/rsd0c of=/mnt/someotherdevice/disk.img and that would get your meta data, your data, your microdata your macrodata and possibly your first born). So let me offer you this, instead. A backup of potentially someday useful disk data: for DISK in $(sysctl -n hw.disknames|tr ',' ' '); do D=$(echo $DISK| cut -f1 -d:) print print "====== $DISK =======" fdisk $D disklabel $D done (note: this script is surely missing edge and special cases. It has been run on three different machines. I do not wish to talk about how much time I've spent making it look prettier. I guarantee it is worth about what you paid for it and nothing more). Run that periodically, redirect the output to a file, get that file to another place, and you have full info about your disk partitions, both fdisk and disklabel, in case you overwrite them someday. Far more likely than a crypto failure that can be recovered by some crypto metadata backup. And the cool thing since the prefix "meta" basically boils down to "sounds cool, no idea what it means", we can call this metadata. :) (Yes, the disklabel info is stored by security(8), ... kinda. Spot checking two of my systems right now, I see both are missing drives...and I'm not sure why, I suspect there's a good reason. But fdisk output is NOT there, and I'd rather prefer it be there too on fdisk platforms). Nick. > > Thanks! > Nathan > >> Does a softraid(4) crypto volume require metadata backup? (I am >> running amd64 OpenBSD 6.9 if it is relevant, will probably >> upgrade in the next few months.) >> >> I understand FreeBSD GELI (e.g.) requires such a backup to protect >> against crypto-related metadata corruption rendering the encrypted >> volume inaccessible. >> >> Neither the OpenBSD disk FAQ nor the man pages for softraid(4) or >> bioctl(8) have anything to say about the matter. Web searches also >> turn up no relevant information. > > Storage requires backup. > Encrypted storage is (by design) more fragile than unencrypted storage. > Sounds like you are trying to protect against ONE form of storage > failure and avoid the solution you really need to have: a good backup > system, to deal with *all* forms of storage failure. > > I'd suggest a good backup system...to deal with ALL forms of data loss. > Yes, encrypted storage implies a certain care has to be taken with the > backups as well, you need to pick a solution that is appropriate for > your needs -- or accept that yeah, stuff will go bye-bye someday. > > I don't see a benefit to trying to protect against some single failure > mode when all the other failure modes still exist. If you have good > backups, you are good. If you don't, dealing with a 1% problem isn't > going to change much. > > Nick. >
