Encrypt and backup personal data with OMV

I'm new to OMV and about to build my first NAS system. My NAS is going to have two HDDs of which one will host personal data (backups, pictures, etc...) and the other one will contain media (movies, music, software, ...). I consider all the personal stuff to be irretrievable and sensible information. Therefore, I want to have it encrypted and backed up to a remote location, for instance in case the HDD or the whole NAS get stolen.

I figured that currently there are three tools for data encryption that - judging from the posts in this forum - are more or less suitable to be used with OMV:
1) TrueCrypt
2) dm-crypt/LUKS
3) EncFS

In general I imaginge the encryption to require a passphrase only after system startup. After that, I want to be able to share the encrypted data via samba as if it wasnt encrypted after all. I want the NAS to handle all the de- and encryption stuff. I also want rsnapshot creating snapshots of my backups on the NAS and rsync or duplicity to back up my most recent backup to a remote location via the internet. I don't want the media HDD to be affected by all this in any way (it shall remain unencrypted).

My current plan is to have a TrueCrypt container on the data HDD which is mounted again in OMV and shared via samba. I think this would allow me the implement all the stuff I mentioned in the paragraph above. However I'm certainly not sure if that is actually going to work, nor if it's the best solution. Especially since TrueCrypt is dead, I'd like to avoid the use of it. I also wonder what happens to the sambda share, the snapshots and the remote backup if I forget to mount the TrueCrypt container or to put in the passphrase. In that case the shared directory is probably empty and the backup software of my computer is going to build a full new backup. Also rsync and rsnapshot will probably continue to work with this "wrong" and unencrypted backup.

Edit: The other option would be to encrypt the whole data HDD with one of the other tools mentioned above. Unfortunately I was not able to determine which one I should use, how to do it and especially how that is going to interfere with OMV...

What do you think of my idea? Could you please point out different approaches to this problem? What would you recommend?

you wrote me a PM regarding my personal setup. I think it's best if I just reply to you here.

My setup is built upon LUKS/dm-crypt because it is so tightly integrated in Debian. It consists of basically three steps:

install a plain Debian 7 (Wheezy) on your system drive and setup encryption for the OS (this is an optional step in the installer). You only wrote about the two disks you want to use, but you should consider using a third small drive for the OS itself.

use the commands provided in this guide to add an OMV installation on top

0. Remember that these steps will completely erase the contents of every selected disk.
1. Create a keyfile for your disks. You can reuse the file if you have multiple disks.dd if=/dev/urandom of=/root/keyfile bs=1024 count=4chmod 0400 /root/keyfile
2. Identify the disk you want to encrypt. lsblk or fdisk -l are your friends here. I will refer to the target disk as /dev/sdX.
3. Create a LUKS Partition on your data diskcryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 luksFormat /dev/sdX /root/keyfile
See this guide for an explanation of the parameters.
4. Mount the disk and create a partition. I am using ext4 in this example. Alternatively, you should be able to create the partition using the webinterface after the disk is mounted. cryptsetup luksOpen /dev/sdX luks-sdX --key-file /root/keyfilemkfs.ext4 /dev/mapper/luks-sdX
5. Automatically mount the disks on boot.
Create an entry like this in /etc/crypttab:luks-sdX /dev/disk/by-uuid/<<uuid>> /root/keyfile luks
Replace luks-sdX with a name for the disk, e.g. luks-video, and <<uuid>> with the UUID of the disk (lsblk and blkid are your friends again).

Now if everything went successful your drives will automatically on boot and you can use them as usual. While it is possible to unmount the drives while the system is running, I do not recommend it as it will likely create problems with OMV.

This way the data is not plainly available on the drives. In case the drives are physically stolen, or defective and have to be sent back, the other party cannot recover the contents. The information on the drives is not confidential and does not require special protection, so this is sufficient to me.
Besides, with AES-NI the encryption hardly affects the performance

Thx for the detailed installation instruction. Wikipedia says, AES-NI was designed for x86 (Intel/AMD), hence "hardly effecting the performance". What about RaspberryPi ? It's based on ARM. How strong is that one effected?

AES-NI was designed for x86 (Intel/AMD), hence "hardly effecting the performance". What about RaspberryPi ? It's based on ARM. How strong is that one effected?

Raspberry Pis are crap to be used for NAS use cases. Their ARM SoC is 64-bit ARMv8 but RPi foundation and/or Broadcom didn't want to spend the few cents on getting ARMv8 AES crypto extensions licensed (they even force you to run 32-bit code on it not making use of all the ARMv8/64-bit goodness).

So simply forget about it with a Raspberry Pi and if you want to use ARM then choose any of the other ARMv8 64-bit designs that do support crypto extensions. Some even outperform cheap Intel designs even if those have AES-NI enabled. More details if wanted/needed: cnx-software.com/2017/10/26/li…platforms/#comment-548152

This is true, but the system drive is encrypted using a strong passphrase (chosen during the Debian installation, not the generated key). I feel protected enough by this.

Me too! I also simply want to be protected against the drug consuming burglar, stealing and reselling my equipment. Therefore my question: Is there any possibility, any parameter or config switch, which gives me a faster decryption than AES? It might be weaker which is not so important. It must not be NSA-proof. If they like my vacation photos, they should have it.