>> but then, it could be configurable by commandline whether luksFormat >> creates a backup header at all, and everybody would be happy, no? > > I really do not see the point. Many filesystems are gone if you > overwrite the start of the partition. It is one of the things > careful users guard against by backing up. I don't agree with this. I have recovered FAT32, reiserfs and ext4 file-systems which have been formatted. The idea is that files are (with high probability) stored contiguously. Therefore, a "grep-like" utility can recover many files, albeit the file-names are lost. Testdisk is a nice utility which does just that. It scans the disk for known file headers, then uses knowledge about the file format to find the end of the file. It can recover pretty much everything that can be lost (e.g., XML, gzipped XML, JPEG, videos, etc.). Basically, if you format your drive you don't lose anything. :) I have even recovered damaged file-systems inside dm-crypt volumes with great success. In contrast, if the LUKS header is overwritten, you lost everything, without having any chance of recovery. Testdisk is ready to help you, but without the master-key the hard-drive looks like random data. I understand that LUKS' concern is to protect data from unauthorized access, but couldn't a compromise be found? The randomly-placed backup header idea proposed by Jonas seems nice. Implementation-wise, if the position of the backup header is known, then LUKS can just make a second shift when accessing sectors after that position. Wouldn't this be an acceptable solution? Cristi. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
