Slashdot Mirror


Ask Slashdot: Simplifying Encryption and Backup?

New submitter FuzzNugget writes "A recent catastrophic hard drive failure has caused me to ponder whether the trade-off between security and convenience with software-based OTFE is worthwhile. My setup involves an encrypted Windows installation with TrueCrypt's pre-boot authentication, in addition to having data stored in a number of TrueCrypt file containers. While it is nice to have some amount of confidence that my data is safe from prying eyes in the case of loss or theft of my laptop, this setup poses a number of significant inconveniences." Read on below; FuzzNugget lists some problems with this set-up, and seeks advice on a simpler system for backing up while keeping things locked down. FuzzNugget continues: "1. Backup images of the encrypted operating system can only be restored to the original hard drive (ie.: the drive that has failed). So, recovery from this failure requires the time-consuming process of re-installing the OS, re-installing my software and re-encrypting it. Upgrading the hard drive where both the old and new drives are still functional is not much better as it requires decryption, copying the partition(s) and re-encryption.

2. With the data being stored in large file containers, each around 100-200GB. It can be come quite burdensome to deal with these huge files all the time. It's also a particularly volatile situation, as the file container is functionally useless if it's not completely intact.

3. As much as I'd like to use this situation as an opportunity to upgrade to an SSD, use with OTFE is said to pose risks of data leaks, cause decreased performance and premature failure due to excessive write operations.

So, with that, I'm open to suggestions for alternatives. Do you use encryption for your hard drive(s)? What's your setup like and how manageable is it?"

2 of 148 comments (clear)

  1. backup orthogonal to encryption by Anonymous Coward · · Score: 5, Insightful

    Aka: you are doing it wrong. First think of backup: you have a machine, and you copy its contents to another drive. Ok. Easy. Now take a breath, and use OTFE for the original hard disk, and now add OTFE for the external drive/media. There. The backup has NOTHING to do with encryption. If you have forced yourself into a backup solution which requires encryption integration to the point that it only restores to a specific hardware, you are failing hard time, precisely for the reason backups are for when you don't have the original hardware.

    Again, separate backup from encryption. I mean, next you will want an integrated internet/remote backup and you will cry us a river? Compartimentalize each function and then you can mix them freely.

  2. What problem are you trying to solves? by bill_mcgonigle · · Score: 5, Insightful

    aside: "OFTE" seems to stand for "On The Fly Encryption" - an initialism I hadn't heard used by IT folks before ... but anyway....

    Why aren't you backing up your files from one encrypted volume to another, at the file level? It sounds like you're doing block level backups of your container files. Do you not trust your backup computer to have those volumes open and decrypted at backup time? Dealing with block-level diffs isn't an easy way to approach the problem, but you could look at mirroring a copy-on-write filesystem, or a dedicated backup application that does its own block diffs and maps for incrementals.

    I use LUKS on linux for my backups, and then the backup drives go offsite. But the backup computer is allowed to access the files while the backup is running - which isn't a problem for the risks I'm trying to defend against. If you can't trust your backup computer, another approach is to run Windows as a VM and handle your backups with linux, which has a lower intrusion rate.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)