Pro and Con of XFP Encrypted?


Recommended Posts

Hello everybody,

 

I am building a new server and the disks are preclearing at the moment.

So I was wondering how to format them after that.

Should I use xfs or xfs encrypted? 

I could not find any pro/con lists about that.

 

Obviously the xfs ecrypted is... well encrypted. But does it have any cons? Is the array slower when it is encrypted? Can the hardrives still be read on any other linux-machine in case of a failure (of course when the other linux machine has some kind of key?!)

 

Thanks for your help

 

Acid  

Link to comment

Cons, I imagine encryption will add some overhead, but I think you'd have to ask someone who has their disks encrypted if they notice a performance hit.

Forgetting your encryption password, yeah that would be pretty bad.

 

At the end of the day, unless you are storing ultra classified, or secret stuff you don't want anyone to see, I'd have to ask WHY would you do it?


For laptops I can understand, they are easy to steal and can be lost, so you don't want anyone poking around your stuff, but a home based server or PC? To me it just seems unnecessary but hey, to each their own.

Link to comment
12 hours ago, ashman70 said:

At the end of the day, unless you are storing ultra classified, or secret stuff you don't want anyone to see, I'd have to ask WHY would you do it?

 

The main advantage with encrypting the disk, is that if you have a warranty issue you can send in the drive as is without caring about the content.

 

An unencrypted disk that fails may be so broken that it can't even be erased.

 

But as noted by @John_M - most people don't need encryption.

 

How much it slows down the system? That depends completely on amount of processing power. Note that unRAID parity work is done on raw disk sectors, so it isn't affected by the encryption - unRAID does the work below the file system layer.

Link to comment
  • 7 months later...
  • 7 months later...
  • 5 months later...

A year old post - but I was looking into this. unraid uses luks for encryption - you can setup a system or virtualbox system with luks and mount the drive with with the secret key to mount and read the drive. I have not tried this, but should work in theory.

 

 

Link to comment
  • 8 months later...

I'm debating using encryption myself.  I like the idea of my personal files being safe on the small chance a thief breaks into my home and steals my unraid server.  They would get access to a lot of important files of mine.

On the other hand I want to be able to recover my files if something goes wrong.  Has anybody actually tried mounting and reading an encrypted disk with their secret key from a different machine?

Link to comment

imho if your unraid server gets stolen, it would not be by a person who understands it. so in this manner i consider the data to be just lost and not stolen

a file or folder encryption would be a better solution here

if you need a safe copy for yourself, use cloud copy

if you need to be safe in case of an investigation against you, your password would be still cracked if it really would be needed.

so there is not much usecases to have encryption enabled. one of them being for compliance reasons if you work with sensitive data and you need to proof that you store them safe for an audit or so.

and yes i use encryption but i regret it and will migrate the data to non encrypted drive. The password submission is so annoying everytime you restart it.

The overhead can be quite big on slower performing CPUs too

immagine.thumb.png.ea0710f39528a4ed3d584a639b0ee35f.png

 

Edited by theruck
Link to comment

Thanks for the input.  I think Ill leave encryption off.  All my data is important and I have cloud backups, but I suppose if somebody were to read the data, it wouldnt be a big deal.  The only thing I never want getting out is my passwords and access to my email, but those are on my windows machine which is Bit lockered with TPM, so if thats stolen they cant just boot into my profile and open a web browser to view all my saved logins.  Unraid is just for storing files and its not like I keep plaintext files of my passwords so its fine.

Link to comment

In case this helps, I made tests and improved an existing script which enables you to easily backup LUKS2 headers:

 

 

@itimpi, I was considering switching to xfs-encrypted on my server. What exactly are you thinking about when you talk about "file system level corruption" ? Do you have in mind something other than a corruption in the fist 16MB sectors ?

 

Best,

OP

Edited by Opawesome
Link to comment
18 minutes ago, Opawesome said:

In case this helps, I made tests and improved an existing script which enables you to easily backup LUKS2 headers:

 

 

@itimpi, I was considering switching to xfs-encrypted on my server. What exactly are you thinking about when you talk about "file system level corruption" ? Do you have in mind something other than a corruption in the fist 16MB sectors ?

 

Best,

OP


yes - corruption in any part of the directory structure.     Not that unusual if a write to the drive fails for any reason.

Link to comment
On 2/14/2021 at 6:21 PM, 007craft said:

Thanks for the input.  I think Ill leave encryption off.  All my data is important and I have cloud backups, but I suppose if somebody were to read the data, it wouldnt be a big deal. 

Not saying that you should encrypt your data by any means, but when one has all its data backed up on a remote location, then the risk of loosing the locally encrypted data because of some sort of data corruption is, IMO, well mitigated.

Link to comment
1 hour ago, Opawesome said:

Wouldn't that be caught and fixed with a parity check ?

 

It is not that simple :(  In the case of a parity check detecting the drives do not agree with parity unRaid will not know which drive is at fault and the only action you can take is to update parity to match the drive.

 

If the write failed , but the corresponding parity write worked unRaid would disable the drive where the write failed and subsequently detect that the parity is out of step with the drive.  You now have to decide if parity is right and rebuild the drive to match parity (normal action) or decide to rebuild parity to match the drive (which means parity now reflects any file system level corruption).

 

You can also get the case where a software or hardware error causes an incorrect sector to be written to both the drive and the parity drive without any apparent error indication at the hardware level.  In such a case both parity and the drive are in agreement but the file system is corrupt.

 

Finally you have the case where you get more disks failing than you have parity drives.  In such a case parity cannot help you, but often the majority of the data can still be recovered off a failing drive as long as it is still working at even a basic level.

 

All of these are low probability but in my view are still higher probability than the use case where encryption would matter to me.

 

Link to comment

Hi again @itimpi

 

Many thanks for you detailed and insightful answer.

 

I have though about the various issues/scenarios you mentioned and I have a few remarks: 

 

1ST ISSUE:

 

Quote

If the write failed , but the corresponding parity write worked unRaid would disable the drive where the write failed and subsequently detect that the parity is out of step with the drive.  You now have to decide if parity is right and rebuild the drive to match parity (normal action) or decide to rebuild parity to match the drive (which means parity now reflects any file system level corruption).

 

This sounds very logical. I didn't know you could make such a choice however. In this case, I understand that the only case where having or not having encryption enabled would make a difference is: (i) when the bad sector would be located in the LUKS; and (ii) Unraid fails to rebuild the corrupted data correctly. Assuming that LUKS headers are checked and within the scope of parity protection, then I guess such failure would immediately be noticed upon a reboot, because you would not be able to mount the LUKS partition and start the array. In that case, wouldn't you just have to restore your backed up LUKS headers on the incriminated data drive to fix the issue? Unless I am missing something of course.

 

[As a side question (a bit off-topic): Also wouldn't having 2 parity disks help in the decision in determining which drive (parity1, parity2 or data) contains the incorrect data ? And if yes, does Unraid make that decision autonomously when checking/correcting parity ? I would be curious to know.]

 

2ND ISSUE:

 

Quote

You can also get the case where a software or hardware error causes an incorrect sector to be written to both the drive and the parity drive without any apparent error indication at the hardware level.  In such a case both parity and the drive are in agreement but the file system is corrupt.

 

This case scenario sounds indeed quite bad. I imagine that maybe the 'hardware-caused" issue can be mitigated by using ECC memory. However, I don't really see how would disk encryption render data recovery more difficult. As long as the LUKS headers are intact (or able to be restored as mentioned above in 1st issue) and you can mount the LUKS partition after providing the decryption key, won't that partition by treated like a simple hard-drive device by the kernel, thus enabling you to use any data recovery tool you would have used anyway ? 

 

3RD ISSUE:

 

Quote

Finally you have the case where you get more disks failing than you have parity drives.  In such a case parity cannot help you, but often the majority of the data can still be recovered off a failing drive as long as it is still working at even a basic level.

 

Same remark as for 2nd issue above.

 

CONLUDING REMARKS

 

I am by no mean an expert, so please be welcome to challenge my understanding above. I do understand that encryption adds a layer of potential problems but I would like to exactly understand the risk and I don't want to reject encryption if this additional layer of problems can be managed.

 

In any event, I don't see any scenario where encryption could be a problem if you have full offsite backup. Does anyone see one aside forgetting password or losing key for both machines at the same time?

 

Best,

OP

Edited by Opawesome
Link to comment
1 hour ago, Opawesome said:

Unraid fails to rebuild the corrupted data correctly.

I agree there is no problem if the rebuild has worked as expected.

 

1 hour ago, Opawesome said:

However, I don't really see how would disk encryption render data recovery more difficult

 

that is true if the recovery software you use knows how to recover encrypted volumes.  Not sure this is always the case.

 

1 hour ago, Opawesome said:

[As a side question (a bit off-topic): Also wouldn't having 2 parity disks help in the decision in determining which drive (parity1, parity2 or data) contains the incorrect data ? And if yes, does Unraid make that decision autonomously when checking/correcting parity ? I would be curious to know.]

 

unRaid does not use the 2nd parity to identify the failed drive after a parity check fails.  Not knowing the algorithms involved I do not know whether this is not done because it is computationally too expensive or because there is too much chance of a false positive.

 

1 hour ago, Opawesome said:

In any event, I don't see any scenario where encryption could be a problem if you have full offsite backup

I agree as good backups makes any discussion about recovery of data almost moot - but many people do not have that sort of backup.

 

The question many people do not think to even ask themselves is why they need encryption in the first place.  They simply assume it must be a 'good thing' to have.

Link to comment
39 minutes ago, itimpi said:

that is true if the recovery software you use knows how to recover encrypted volumes.  Not sure this is always the case.

 

That I don't understand. My understanding was that with LUKS : (i) the encryption/decryption is made at the kernel level, and that  (ii) a device is created by LUKS resulting in software applications not even being aware that they are dealing with an encrypted partition.

Link to comment
1 minute ago, Opawesome said:

That I don't understand. My understanding was that with LUKS : (i) the encryption/decryption is made at the kernel level, and that  (ii) a device is created by LUKS resulting in software applications not even being aware that they are dealing with an encrypted partition.

 

You are making assumptions that the recovery software is running on Linux I think?  If for instance it is running on Windows I expect it IS aware of the encryption layer (although I could be wrong :()

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.