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.
