1

I have a kind of philosophical question.

I'm about to set a new backup server and as time is passing encryption of data seems more and more reasonable.

However what if the harddrive goes bad. I know that the question seems simple, but...

...there is no such a thing like perfect HD. I had situation that I lost drive that was safely placed on the shelf. After lying for ~1 year it wouldn't spin up. Of course, in this case with-or-without encryption data are gone. However, taking in account, that 3 out of ~100 server-quality SAS-Drives I have around, have lost some sectors during last 3 years, I'm really not feeling comfortable. What is the sense of backup if some broken sectors render unknown file or even whole partition useless.

Other obvious side is: what if HD with sensible data goes missing? We had once situation that cleaning staff forgot to close in the morning our server room. With dozens of students passing this room daily it's more a question of luck (or high moral) that some of the cages weren't emptied.

As I use Linux, I checked what solution are available. I've read a bit about a stacked filesystem and a block device encryption but still, from what I understood, most of the HD-recovery tools have problems if the partition is encrypted.

I'm not talking about hacking into the data. I assume that I will always have a key-file or a password that is required for decryption.

Anyone would care to share some thoughts about it?

Jacob
  • 9,204
  • 4
  • 45
  • 56
Kris_R
  • 305
  • 1
  • 10

2 Answers2

1

While this is a rather broad question here are some hints:

If you really need to have encryption of data you should at least go for a lot of enterprise disks, md5sum(or similiar) checksum tools for every file in storage, and for the container, have multiple full backups on different media. off-site storage with tapes (obviously checksum the written data aswell. make constant recovery tests on every medium, and plan to switch the hardware depending on the "risk" you want to take.

For Server grade Disk: example with fictional values:

suppose you have 1 defect sector in ~3 years. this would make it roughly 1/1000 chance of having one defect sector per day. (lets ignore the amount of data variable for this example)

As the drive ages the risk increases until it fails.

So either you swap them out after you reach a certain threshold (like 1 or 2 %) or you risk having one backup/parts of backup fail, and you have to make sure that :

 you know that it failed
 you take action that next one will not fail.

Keep in mind that this all happens without encryption aswell.

so encryption just makes it more likely that you loose the whole backup (if you do not encrypt only on file level)

Additional deduplication of files, depending on how you encrypt it, will not work either, making the backups larger.

For HD missing: just make sure the encryption is strong enough until the data has no worth for someone else anymore. Or you need to tighten your security so this cannot happen :

F.e. Access control to the server room and full video monitoring etc

tl,dr: prevent bitrod by monitoring every file + container, swap hdds before they get bad, video monitor the server room and prevent access without at least one other person knowing.

Dennis Nolte
  • 2,881
  • 4
  • 27
  • 37
1

Hard disk encryption algorithms can be complex, but the actual block-level encryption is mostly a very simple, symmetric algorithm. DES, 3-DES, and its followers are all very-very simple algorithms, mostly they are permuting the location of the bits and then its values.

What makes this whole thing so complex, is the handling of the encryption/decryption key. This is where the RSA, the multihundred character long prime numbers, etc. are working.

It needs to be so: because an encrypted disk must not be too slow, thus the actual, speed-critic algorithm needs to be fast.

And second: the sectors (blocks) of an encrypted hard disks need to be encrypted/decrypted from eachother independently. It were a big joke if we needed to decrypt a whole disk to find out what is in its last block. :-)

This last, which makes your life so simple. The only thing you need to save, is the encoding/decoding key. If a bad block comes, this key will be enough to decode the whole hard disk.

Of course, not the bad blocks, but their fault won't cause the unreachability of the other blocks.

On the handling of the key, it is better to use some opensource solution: of course it also can't be allowed, that you will be unable to decode your data only because the developer company simply doesn't support rescue mechanisms.

In short: if you clone a such hard disk with bad blocks with a sector-level data rescue tool (for example: gddrescue is a good idea on the opensource world), the clone will be decodable (and then fixable) nearly always without any major problems.

Of course a lot more could be written from the actual things to do in case of a damaged disk, but it all depends on the actual used technology.

peterh
  • 4,953
  • 13
  • 30
  • 44
  • are you talking about encryption directly on the controller of the HDD? depending on how you partition the drive one actually might have to decrypt the whole HDD before one can access the data, or am i missing something here? I am thinking about encrypting the whole disk while install of debian f.e. , aka you need to enter the key before you can even boot. – Dennis Nolte Jul 30 '14 at 12:43
  • @DennisNolte Q1: "Are you talking about encryption directly on the controller of the HDD?" No, I talked about hard disk encryption, in general. Although a HD controller-based solution (imho) weren't a good idea, because they tend to be closedsource solutions which greatly reduces the data rescuing possibilities in case of a hardware failure. – peterh Jul 30 '14 at 12:46
  • @DennisNolte Q2: "Depending on how you partition the drive one actually might have to decrypt the whole HDD before one can access the data, or am i missing something here?" Nothing needs to be decrypted, there are independent encryption blocks in every hdd encrypting solution. It needs to be done so, or the contents of the data blocks of the disks weren't independant readable/writable. And this makes the encrypted disks much more resistant against hardware failures as we thought. – peterh Jul 30 '14 at 12:47
  • @DennisNolte Q3: "I am thinking about encrypting the whole disk while install of debian f.e. , aka you need to enter the key before you can even boot" It is possible, I did such system already as well, but in this case you need to be able to read the initial kernel/initrd on boot. I used an usb pendrive for this goal, which didn't contain the decipher key (it existed only in my mind, and I needed to type this herein on boot). But most "professional system administrator" don't use such solutions currently, because it is complex to configure. – peterh Jul 30 '14 at 12:53
  • thank you for your answers, this make it more clear for me. – Dennis Nolte Jul 30 '14 at 12:58
  • @DennisNolte Thank you! If you are satisfied, you can express that with an upvote/accepting. – peterh Jul 30 '14 at 13:00
  • Thank you Peter for sharing your thoughts. It looks better than I thought. Which solution would you advise stacked filesystem (eCryptfs, EncFS) or a block device encryption (loop-AES, dm-crypt or even TrueCrypt)? – Kris_R Jul 31 '14 at 10:40
  • @Kris_R Thank you! For backup, I used linux and dm-crypt. The is a very good command line tool named `cryptsetup`, but there are a lot of gui tools as well. `dm-crypt` cooperates very well with the linux LVM, which can be very useful if you want to share the backup with other functions as well. – peterh Jul 31 '14 at 14:52