View Single Post
  #2   (View Single Post)  
Old 14th October 2013
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
Join Date: May 2008
Location: USA
Posts: 7,471

Hello, and welcome!
Originally Posted by virtuvoos View Post
(My goal is) ...full disk encryption. In the occasion I need the encrypted data, then I'll mount it manually. No fancy stuff like booting off it and such...
There's nothing special about this requirement -- it could be a "full disk" or it could be a partition -- the use will be exactly the same operationally, only the size of the encrypted partition would be different.
...Michael does repeatedly say: "Don't come crying to me if you lost your data. I know you eventually will. Keep good backups!" and last but not least he also mentions about bioctl potentially ruining your entire disk.
These are two separate issues. Let's start with filesystems: the most common reason for loss of data at rest (e.g. in a filesystem) is human error. The next most common reason is device failure. They're both very, very common. After those two, in a distant third place, are software problems.

This holds true with encrypted data. The same three causes for data loss -- human, hardware, and software -- apply. There may be more opportunities for human error, as you're adding a configuration layer. There is a minor opportunity for software error, though

Over the years since its incept, softraid(4) has had changes to stored metadata which , when we upgraded, required us to backup - recreate - restore softraid entities. I expect that to continue, as development is not complete for all disciplines.

You should back up your encrypted data -- whether your backup is a copy of the ciphered data or whether you back it up as planitext data will be dependent on your needs. In my case, I encrypt the /home partition on my netbook; its backups are stored in plaintext on another system that does not travel. My threat model for that data is loss/theft of the device when it is out of my home.
I want some data encrypted and I could live with one or two files being broken or lost but not all!
properly configured and managed (including backups) you should be able to eliminate this risk, whether you encrypt data at rest or not.
What about the software layer? How mature is the driver, will it eat up my entire disk if something goes wrong?
I consider the crypto discipline fairly mature, and I've been using it in production for at least four years. It was the second discipline added to softraid, in May 2007.
What about the hardware layer? Bit rot, degrading/old harddisks that occasionaly might miss a few bits/bytes, sudden power failures, ... . To put it really shortly: what is the danger of encryption apart from human error?
Hardware failure is hardware failure. All drives fail, eventually. This is why we take backups. The difference, though, is that a partial failure -- sector losses, for example -- may have a much bigger impact on an encrypted filesystem. I've had drive failures with softraid RAID1 arrays and continued operation, as expected. I've not experienced a drive failure with the crypto discipline.

If you have the resources, you can use the crypto discipline atop an array created with the RAID1 discipline. This should mitigate hardware failure issues. However, the order you do things in is important, when you are nesting softraid disciplines. See this misc@ thread for details.

I've never had a problem with the encrypted /home partition on the netbook.
Reply With Quote