• Content Count

  • Joined

  • Last visited

Community Reputation

13 Good

About Opawesome

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Today, I found this tutorial by Mister @SpaceInvaderOne. This may be worth having a look @loopback. On paper, it seems to suit your needs :
  2. Hi @grunter This may interest you: https://www.anandtech.com/show/15863/the-intel-w480-motherboard-overview-lga1200-for-xeon-w-1200 They provide a review of several motherboards with a W-480 chipset: ASRock W480 Creator ASRock Rack W480D4U ASUS Pro WS W480-Ace DFI CMS310-W480 GIGABYTE W480 Vision D GIGABYTE W480 Vision W GIGABYTE W480M Vision W Supermicro X12SCZ-TLN4F Supermicro X12SCZ-F Supermicro X12SAE
  3. Hi @kimifelipe Hi all Maybe I did not understand very well but, it does not seem safe to me to change the parity disk if you are already having problems with one data drive. Especially with only one parity disk and not knowing for sure that the issue is caused by the new data drive and not by something else like a cable, backplane, HBA adapter, or motherboard issue. What if you put back you old drive and it becomes corrupt because of a faulty hardware ? I guess you would be happy to not have removed your parity drive in such event. So unless I misunders
  4. 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.
  5. 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: 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 sco
  6. 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.
  7. Hmm. Scary. Wouldn't that be caught and fixed with a parity check ?
  8. 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
  9. It seems that it is actually recommended to use the built-in command rather than the "dd" command: (abstract from https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery) I also figured that: (abstract from https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions) That means that @golli53's script, which only backups the first 2MB of each device, may not be compatible with LUKS2 (which is the version used by Unraid as of the date of this post). On the contrary,
  10. I forgot to mention that the huge 2017 WannaCry cyber attack used a vulnerability in the SMB protocol (port 445) to spread around the globe (https://en.wikipedia.org/wiki/WannaCry_ransomware_attack). So in a way, even if you do not care about your data being at risk, leaving such services opened to the internet can help the spread of cyber attacks and harm others.
  11. Hi @loopback Based on what I understand of your use case and knowledge in security I would also strongly advise against opening any of the 80/443/445 port (or corresponding HTTP, HTTPS and SMB services) to the internet (not that I am an expert myself either). IMO, the simplest and safest way to remotely access your Unraid server is via VPN. In addition to @trurl's suggestion to use WireGuard, I would also recommend OpenVPN, which have been around (and audited) for a long time now, and therefore could be seen by some as potentially less likely to suffer from vulnerabilit
  12. Hi all, I was wondering what was the advantage of using the "dd" command (which is used in the script kindly shared by @golli53), rather than the built-in "cryptsetup luksHeaderBackup" command. With the built-in command one would just need to run: cryptsetup luksHeaderBackup /dev/sdbX --header-backup-file /path/to/luks-headers-backup/backed-up-header.bin to backup the LUKS header, and: cryptsetup luksHeaderRestore /dev/sdbX --header-backup-file /path/to/luks-headers-backup/backed-up-header.bin to restore the backed-up header. I als
  13. Wow, my thread got hijacked hard :-). I am glad you (@Energen) were able to solve your issues.