[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Encrypted RAID1 for storage with Debian Stretch

On 08/31/17 06:35, commentsabout@riseup.net wrote:
I don't [have a CPU with AES-NI):

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

	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.


Reply to: