On 08/31/17 06:35, commentsab...@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
