Re: Encrypted RAID1 for storage with Debian Stretch

[David Christensen <dpchrist@holgerdanske.com>]

On 08/31/17 06:35, commentsabout@riseup.net wrote:
> I don't [have a CPU with AES-NI):
> https://ark.intel.com/products/78867/Intel-Celeron-Processor-J1900-2M-Cache-up-to-2_42-GHz
>
> So, what would be the most efficient? I guess that encrypting one drive
> and having the other one blindly copying every bit is the proper method.

I suggest that you put encryption on top of RAID 1, so that encryption 
happens once.


But, you do have 4 cores. So, RAID 1 on top of encrypted volumes should 
perform about the same when the system is lightly loaded.


> Does it have any impact on the reliability of the setup?

I have read of a common RAID 1 trick for backups -- add a third drive to 
a mirror, resilver the mirror, and remove the third drive.  This gives 
you an exact duplicate in the shortest time.


The above idea is typically extended with a fourth, fifth, etc., drives 
and off-site rotation.


But, more drives in more sites increases security risks.


An advantage of encryption on RAID 1 is that your CPU encrypts/decrypts 
each block once, so it takes less CPU.  A disadvantage is that there is 
only one set of keys, so if one drive gets cracked they all get cracked.


An advantage of RAID 1 on encrypted drives is that each drive has its 
own set of keys, so cracking one drive does not crack them all.  The 
disadvantage is that your CPU has to encrypt/decrypt each block for 
every drive, so it takes more CPU -- two drives, twice the work; three 
drives, three times the work; etc..


> If the "system"
> ssd fails, would I be able to reinstall Debian on a new drive and plug
> the RAID drives in a plug-and-play fashion? 

I believe RAID requires configuration/ system administrator intervention 
(?).


LUKS can be "automagic" on some desktops.


It's best to keep accurate notes of all administrative actions applied 
to each drive and to the array (e.g. console sessions in a version 
control system).


> Should I care about the "system" redundancy?

I assume you mean RAID 1 for your system drive.  Again, there are 
trade-off's between risk, reliability, performance, security, cost, 
effort, etc..  You must strike a balance that works for you.


I don't use RAID on any of my disks -- system, data, or backup.


I backup my system drives by keeping them small (16 GB or less), 
periodically taking images of them, placing important configuration 
files into a version control system (CVS), keeping a list of all 
packages I've installed in CVS, and keeping a running log of 
administrative actions taken in CVS.  I also backup the LUKS headers of 
all LUKS containers.


For backing up my data, I have three desktop 3 TB HDD's and 1 backup 
server.  The server has two mobile dock bays and each drive is mounted 
in a mobile dock drawer.  One drive stays in the server, one is 
near-site, and one is off-site.  The backups, archives, and images go to 
the server drive.  Periodically, I install the near-site drive, rsync 
the server drive to the near-site drive, remove the near-site drive, and 
then swap the near-site and off-site drives.


I periodically burn archives to optical media and store them off-site.


> Are the encryption keys stored on the "system"
> drive or on the RAID drives (one of them, both?) ?

LUKS provides a "container" with a header and data.  The master key and 
key slots are in the header, so they move with the drive and don't 
necessarily depend on the system drive (unless you do something to make 
them depend upon the system drive, such as putting a key on the system 
drive so that the LUKS container is automatically opened on boot).


> I have been juggling with bash scripts and USB keys in order to create
> some sort of backup on the cheap for my work documents. I do not want to
> risk to screw it up, I want to do it right on the first try and have
> something future proof in my hands and perhaps, more importantly, have
> it up and running before my juggling fails me.

Experimenting with a USB stick is a good way to learn LUKS.  Here is a 
console session for a USB stick I set up recently:


Plug in the USB stick, then run 'dmesg' to find out the device node -- 
in my case, it was /dev/sdb.  Don't screw this up, or you may destroy 
your operating system, data, backups, etc. (!).


Wipe old partition table and boot loader on USB stick:

	2017-05-19 15:21:20 root@jesse ~
	# dd if=/dev/zero bs=1M count=1 of=/dev/sdb
	1+0 records in
	1+0 records out
	1048576 bytes (1.0 MB) copied, 0.69534 s, 1.5 MB/s


Create a new MS-DOS partition table:

	2017-05-19 15:23:21 root@jesse ~
	# parted /dev/sdb mklabel msdos
	Information: You may need to update /etc/fstab.


Create a new partition:

	2017-05-19 15:25:06 root@jesse ~
	# parted /dev/sdb mkpart primary 0% 100%
	Information: You may need to update /etc/fstab.


Look at the partition table:

	2017-05-19 15:27:34 root@jesse ~
	# parted /dev/sdb u s p free
	Model: SanDisk Ultra Fit (scsi)
	Disk /dev/sdb: 242614272s
	Sector size (logical/physical): 512B/512B
	Partition Table: msdos
	Disk Flags:

	Number  Start  End         Size        Type     File system  Flags
	        63s    2047s       1985s                Free Space
	 1      2048s  242614271s  242612224s  primary


Create a LUKS container in the partition:

	2017-05-19 15:28:46 root@jesse ~
	# cryptsetup luksFormat /dev/sdb1

	WARNING!
	========
	This will overwrite data on /dev/sdb1 irrevocably.

	Are you sure? (Type uppercase yes): YES
	Enter passphrase:
	Verify passphrase:


Open LUKS data device:

	2017-05-19 15:29:31 root@jesse ~
	# cryptsetup luksOpen /dev/sdb1 sdb1_crypt
	Enter passphrase for /dev/sdb1:


Create a mount point:

	2017-05-19 15:30:52 root@jesse ~
	# mkdir /mnt/sdb1


Create a BTRFS file system in the LUKS data device:

	2017-05-19 15:31:35 root@jesse ~
	# time mkfs.btrfs --label usb128c /dev/mapper/sdb1_crypt
	Btrfs v3.17
	See http://btrfs.wiki.kernel.org for more information.

	Turning ON incompat feature 'extref': increased hardlink limit per file 
to 65536
	fs created label usb128c on /dev/mapper/sdb1_crypt
		nodesize 16384 leafsize 16384 sectorsize 4096 size 115.68GiB

	real	0m1.287s
	user	0m0.000s
	sys	0m0.024s


Mount file system:

	2017-05-19 15:35:16 root@jesse ~
	# mount /dev/mapper/sdb1_crypt /mnt/sdb1/


Verify file system is mounted:

	2017-05-19 15:36:20 root@jesse ~
	# mount | grep sdb
	/dev/mapper/sdb1_crypt on /mnt/sdb1 type btrfs (rw,relatime,space_cache)

	2017-05-19 15:36:25 root@jesse ~
	# ll /mnt/sdb1
	total 16
	drwxr-xr-x 1 root root  0 2017/05/19 15:35:14 ./
	drwxr-xr-x 1 root root 24 2017/05/19 15:31:06 ../

	2017-05-19 15:36:54 root@jesse ~
	# df /dev/mapper/sdb1_crypt
	Filesystem             1K-blocks  Used Available Use% Mounted on
	/dev/mapper/sdb1_crypt 121304064   512 119177984   1% /mnt/sdb1


Unmount file system:

	2017-05-19 15:37:06 root@jesse ~
	# umount /mnt/sdb1


Close LUKS data device:

	2017-05-19 15:37:29 root@jesse ~
	# cryptsetup luksClose sdb1_crypt


Unplug the USB stick.


You should now be able to plug in the USB stick into this or any other 
recent Linux machine and your desktop/ file manager should give you a 
means to access and release the data -- e.g. an automagic pop-up, an 
icon you can click on, etc..


Backup software is another story.  I've been running home-brew backup 
and archive scripts for many years -- shell and/or Perl scripts that 
drive low-level tools (tar, gzip, rsync, etc.).  The scripts work once I 
get them working, but they are brittle and I am loath to touch them 
because of the risk of breakage and because of the effort required to 
validate everything.  I very much want to migrate to an established 
backup/ archive/ imaging solution, such as Amanda, Bacula, Clonezilla, 
etc..  I suggest you consider doing the same.


David