I don't know about the "single point of failure" part when there is possibility to avoid the problem (backups and keeping your LUKS header a RAID). However I do agree that this issue is overlooked in the general documentation.
Well, backups are not always an option, especially during daytime when your system is busy with other things (as I wrote in the previous post). The only time I ever seen backups during the day was an SAP-cluster with 9 nodes that had a huge tape-robot connected to it, but I doubt that small companies can afford those solutions :-) I don't consider the dd option to be a safe way. There is no way to determine that the output from dd is really the luks-header, is there? You can check if the drive is a luks-drive but you can't verify that the data you get from dd is a correct one. Of course, you can argue that since the header is in that particular place it must be the header, but I think it's too much of a hacker-solution then a real solution for a serious production environment. And after reading the mailing list there seems that the problem with a damanged header isn't an uncommon event. Having the header with just one copy on the disk is a very high risk solution. If you look at for instance Sun's raid/mirror solutions you can save like 10 backups of the important metadata for "just in case". /Paul T --------------------------------------------------------------------- - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
