...goes to: Seagate and/or heise.de (translation here).
Hardware sucks. It just totally and utterly sucks.
I purchased a 300 GB hard drive (plus a 3.5" USB disk drive enclosure) roughly 8 months ago which I encrypted using dm-crypt and then used it as a backup medium. And now the disk has died. No, this is not a software problem (that would be easy to deal with), the hardware is simply dead (it's making funny "klck" noises all the time).
Mounting it via USB (using the USB enclosure) doesn't work at all anymore. I connected the disk via IDE in a PC and was able to mount it just fine (with cryptsetup luksOpen and all). A simple ls works, too (at least in the top-level directory). So I tried to copy the data over to another medium, but when accessing certain directories or files the system simply hangs and I get tons of funny kernel errors (and the disk makes even more and louder funny noises). Great.
Stupid as I am, I also put data on the drive which I did not have backups of on other media (mostly because the data is huge, e.g. conference video recordings, large amounts of Creative Commons MP3s etc). OK, so I managed to get at least some small parts of my data, but now the disk is completely dead, I fear.
I'll try to convice the vendor to give me a new drive, but I won't let them get their fingers on my data, i.e., I will not send the disk to them (yes, even though it is encrypted; crypto can be broken). Any ideas what else I could do? A professional "data recovery" service is not an option either, they usually cost 1000-2000 Euros (in the best case).
What do you do for storing huge amounts of data nowadays? The only viable option I can think of is a RAID-5 (mdadm) with 3 or more disks in a silent PC which I can leave turned on 24/7. Unfortunately that costs non-trivial amounts of money. CDs are too small and they don't last too long either; the same is true for DVDs.
Sigh...
I'm going to set up a new laptop system soonish (more on that later) which shall have a completely encrypted hard drive. Hence, I'm testing a few setups wrt security, performance, manageability and fault-tolerance.
Here's a few performance tests I did on an 80 GB laptop hard drive (in an Intel Celeron based laptop, 1.7 GHz, 256 MB RAM, Linux 2.6.17, Debian unstable).
I ran bonnie++ (with no options) and hdparm as hdparm -tT /dev/hda each time. I haven't put too much thought into the test setup, so if I made some stupid mistakes, please let me know.
Unencrypted plain ext3 partitions:
bonnie++:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 432M 19857 84 21831 10 9536 4 16355 58 22165 3 148.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1650 98 +++++ +++ +++++ +++ 1734 98 +++++ +++ 3820 96
forest,432M,19857,84,21831,10,9536,4,16355,58,22165,3,148.8,0,16,1650,98,+++++,
+++,+++++,+++,1734,98,+++++,+++,3820,96
bonnie++ with SELinux:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 432M 20321 90 21036 13 9473 5 16742 61 21978 4 148.1 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1398 98 +++++ +++ +++++ +++ 1473 98 +++++ +++ 3305 98
forest,432M,20321,90,21036,13,9473,5,16742,61,21978,4,148.1,0,16,1398,98,+++++,
+++,+++++,+++,1473,98,+++++,+++,3305,98
hdparm:
Timing cached reads: 1416 MB in 2.00 seconds = 707.48 MB/sec Timing buffered disk reads: 82 MB in 3.06 seconds = 26.80 MB/sec
hdparm with SELinux:
Timing cached reads: 1404 MB in 2.00 seconds = 700.59 MB/sec Timing buffered disk reads: 80 MB in 3.02 seconds = 26.53 MB/sec
Ext3 partitions on top of LVM on top of dm-crypt:
bonnie++:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 464M 11149 54 16660 20 6461 5 7472 58 11129 5 136.4 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1564 98 +++++ +++ +++++ +++ 1650 98 +++++ +++ 2640 97
forest,464M,11149,54,16660,20,6461,5,7472,58,11129,5,136.4,0,16,1564,98,+++++,
+++,+++++,+++,1650,98,+++++,+++,2640,97
bonnie++ with SELinux:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 464M 9878 52 12138 11 5457 6 6834 56 11037 5 137.2 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1426 97 +++++ +++ +++++ +++ 1451 98 +++++ +++ 2433 97
forest,464M,9878,52,12138,11,5457,6,6834,56,11037,5,137.2,0,16,1426,97,+++++,
+++,+++++,+++,1451,98,+++++,+++,2433,97
hdparm:
Timing cached reads: 1408 MB in 2.00 seconds = 704.01 MB/sec Timing buffered disk reads: 80 MB in 3.02 seconds = 26.53 MB/sec
hdparm with SELinux:
Timing cached reads: 1396 MB in 2.00 seconds = 698.06 MB/sec Timing buffered disk reads: 82 MB in 3.07 seconds = 26.69 MB/sec
So yes, there is some overhead, but it's nothing too serious, IMHO. And quite honestly, I don't care too much about performance here — security is more important than performance. I think you'll agree; if you don't agree now, you will agree with me on the very day someone steals your laptop ;-)
Are full hard drives heavier than empty hard drives?
I read about this in the Talk page of the article about disk drives in the German Wikipedia.
What sounds like a pretty stupid question (it probably is), might still have a pretty interesting answer. Any physics students (electrical engineering? computer science?) out there who can enlighten us? Are there any scientific studies about such issues? There are some theories (German, sorry), but I'm not sure whether that's more than random guesses...
Other stupid questions from the articles above: Are charged cell phone batteries heavier than empty ones? Are Word documents with bigger fonts heavier?
My head hurts...
Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives.
I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too.
Here's a quick HOWTO:
AES encrypted loop device support" in "Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).apt-get install loop-aes-2.6-686 (or a similar package) should suffice.
losetup, mount etc.:apt-get install loop-aes-utils
shred -n 1 -v /dev/sda3.-n 25 or higher if you want more security and have a few days time to wait for the thing to finish...
losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.-C 3 means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see losetup(8)). This is supposed to be more secure.-S 'seed' (replace "seed" with a secret string like "g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!mke2fs -j /dev/loop0losetup -d /dev/loop0/etc/fstab:/dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
mount -o pseed=seed /mnt/crypted_sda3/mnt/crypted_sda3 which will be encrypted automatically.For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...
Recent comments
20 weeks 5 days ago
46 weeks 6 days ago
1 year 2 weeks ago
1 year 2 weeks ago
1 year 2 weeks ago