info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Encrypted RAID1 for storage with Debian Jessie
83 views
Skip to first unread message
commen...@riseup.net
Apr 18, 2017, 10:10:04 PM4/18/17
to
Hello,
Is there an easy way to attach several pair of RAID1 disks (with full
disk encryption) to a Debian Jessie system?
Here is a picture of what I'm trying to achieve:
http://imgur.com/vF7IqX2
I am building a home backup system, I have different type of data to
backup (work, family, random stuff - hence the three pairs in the
picture). The system (Debian Jessie) will be on a USB key.
It's a backup system on a budget that I'd like to have up and running
within a couple of weeks, I know that ZFS (with FreeNAS for instance)
can achieve similar goals but it's out of budget ; I also know that work
is being done on BTRFS about encryption but it's not ready for prime
time yet.
Always state the obvious so :
- the idea behind having the SYSTEM on a independent USB drive is to
have one independent piece to handle the boot and system operations
(that I can easily - and cheaply - mirror to have drop in replacement in
case of failure) and "DATA" drives are just "dumb" encrypted drives that
could be unplugged from the setup and mounted anywhere else ;
- the idea behind the RAID1 is to create redundancy, hence in case one
drive fails, be able to plug a new one in, would it be possible with
full disk encryption?
- this backup system will only be turned on when needed, I don't plan on
using it as some sort of server or a NAS.
Am I re-inventing the wheel here, is there a better, simpler solution to
achieve both redundancy and encryption ?
Thank you in advance for your help,
CA
Is there an easy way to attach several pair of RAID1 disks (with full
disk encryption) to a Debian Jessie system?
Here is a picture of what I'm trying to achieve:
http://imgur.com/vF7IqX2
I am building a home backup system, I have different type of data to
backup (work, family, random stuff - hence the three pairs in the
picture). The system (Debian Jessie) will be on a USB key.
It's a backup system on a budget that I'd like to have up and running
within a couple of weeks, I know that ZFS (with FreeNAS for instance)
can achieve similar goals but it's out of budget ; I also know that work
is being done on BTRFS about encryption but it's not ready for prime
time yet.
Always state the obvious so :
- the idea behind having the SYSTEM on a independent USB drive is to
have one independent piece to handle the boot and system operations
(that I can easily - and cheaply - mirror to have drop in replacement in
case of failure) and "DATA" drives are just "dumb" encrypted drives that
could be unplugged from the setup and mounted anywhere else ;
- the idea behind the RAID1 is to create redundancy, hence in case one
drive fails, be able to plug a new one in, would it be possible with
full disk encryption?
- this backup system will only be turned on when needed, I don't plan on
using it as some sort of server or a NAS.
Am I re-inventing the wheel here, is there a better, simpler solution to
achieve both redundancy and encryption ?
Thank you in advance for your help,
CA
tv.d...@googlemail.com
Apr 19, 2017, 5:20:06 AM4/19/17
to
I use luks on top of raid1, mdadm raid1 volumes get mounted first at
boot, then cryptsetup opens the luks containers. This way re-syncing or
replacing a failed disk never caused me trouble.
Performance-wise it's not the best solution, there is an overhead with
both raid1 (heavy writing can load up the system) and luks. With luks
encryption it depends on the cpu having acceleration for the cypher you
choose. Mine doesn't, but the overhead never disturbed normal operations
so I don't consider it a problem.
System on usb flash disks always caused me troubles, I use it only if
the system can be loaded in ram at boot time and the drive isn't used
for write operation. A low-end small SSD would be a far better option in
my opinion.
On my system all RAID1 are started at boot, then the luks volumes are
either opened at boot time, later when a user logs in via pam-mount, or
on-demand with scripts.
My BackupPC server runs with RAID1 + luks volumes too, no problems for
the past six years.
I use ext4 as my file-system. ext4 has built-in encryption capabilities
now, but I can't comment on it since I have no first hand experience.
Good luck.
Joshua Schaeffer
Apr 19, 2017, 11:10:07 AM4/19/17
to
As already stated LUKS and mdadm are a good combination. I too use these in all my recent systems. I Create RAID volumes, then LVM, then cryptsetup:
=========
+ mdamd +
+ | +
+ LVM +
+ | +
+ LUKS +
+ | +
+ ext4 +
=========
I can't speak to your system being on USB, but in general you can just do something like the following:
$mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
$mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
$mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdc /dev/sdd
$mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sde /dev/sdf
If you want to use LVM then you create the PV, VG, and LV:
$pvcreate /dev/md0
$pvcreate /dev/md1
$pvcreate /dev/md2
$vgcreate vg_data1 /dev/md0
$vgcreate vg_data2 /dev/md1
$vgcreate vg_data3 /dev/md2
$lvcreate vg_data1 -n lv_data1 -L <size>
$lvcreate vg_data2 -n lv_data2 -L <size>
$lvcreate vg_data3 -n lv_data3 -L <size>
Then create your LUKS partition:
$cryptsetup -v --verify-passphrase luksFormat /dev/mapper/lv_data1 vg_data1-lv_data1_crypt
$cryptsetup -v --verify-passphrase luksFormat /dev/mapper/lv_data2 vg_data2-lv_data2_crypt
$cryptsetup -v --verify-passphrase luksFormat /dev/mapper/lv_data3 vg_data3-lv_data3_crypt
Then create your filesystem and mount them:
$mkfs.ext4 /dev/mapper/vg_data1-lv_data1_crypt
$mkfs.ext4 /dev/mapper/vg_data2-lv_data2_crypt
$mkfs.ext4 /dev/mapper/vg_data3-lv_data3_crypt
$mount -t ext4 /dev/mapper/vg_data1-lv_data1_crypt /mnt/data1
$mount -t ext4 /dev/mapper/vg_data2-lv_data2_crypt /mnt/data2
$mount -t ext4 /dev/mapper/vg_data3-lv_data3_crypt /mnt/data3
One of my systems looks like this. On this particular system I only encrypt home and swap:
$jschaeffer@zipmaster07 ~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
\sda1 8:1 0 100M 0 part /boot/efi
\sda2 8:2 0 250M 0 part
\md0 9:0 0 250M 0 raid1 /boot
\sda3 8:3 0 111.5G 0 part
\md1 9:1 0 111.4G 0 raid1
\vg_sys1-lv_var1 (dm-1) 252:1 0 55G 0 lvm /var
\vg_sys1-lv_tmp1 (dm-2) 252:2 0 4G 0 lvm /tmp
\vg_sys1-lv_swap1 (dm-3) 252:3 0 6G 0 lvm
\vg_sys1-lv_swap1_crypt (dm-5) 252:5 0 6G 0 crypt [SWAP]
\vg_sys1-lv_root1 (dm-4) 252:4 0 46.4G 0 lvm /
sdb 8:16 0 111.8G 0 disk
\sdb1 8:17 0 100M 0 part
\sdb2 8:18 0 250M 0 part
\md0 9:0 0 250M 0 raid1 /boot
\sdb3 8:19 0 111.5G 0 part
\md1 9:1 0 111.4G 0 raid1
\vg_sys1-lv_var1 (dm-1) 252:1 0 55G 0 lvm /var
\vg_sys1-lv_tmp1 (dm-2) 252:2 0 4G 0 lvm /tmp
\vg_sys1-lv_swap1 (dm-3) 252:3 0 6G 0 lvm
\vg_sys1-lv_swap1_crypt (dm-5) 252:5 0 6G 0 crypt [SWAP]
\vg_sys1-lv_root1 (dm-4) 252:4 0 46.4G 0 lvm /
sdc 8:32 0 931.5G 0 disk
\sdc1 8:33 0 100M 0 part
\sdc2 8:34 0 931.4G 0 part
\vg_home1-lv_home1 (dm-0) 252:0 0 850G 0 lvm
\vg_home1-lv_home1_crypt (dm-6) 252:6 0 850G 0 crypt /home
sr0 11:0 1 3.8G 0 rom
Thanks,
Joshua Schaeffer
David Christensen
Apr 20, 2017, 12:10:03 AM4/20/17
to
1. One drive ("primary") is in a server at all times.
2. I rotate the other two drives between near-site and off-site every
couple of weeks -- dock the near-site drive, rsync the primary drive to
the near-site drive, undock the near-site drive, then swap the near-site
and off-site drives.
My file server and backup server are running Debian 7 with Xfce on 16 GB
USB 3.0 flash drives. They work fine headless, but stutter noticeably
if I log in and run concurrent GUI apps and/or terminal jobs. I
initially created USB flash Debian system drives using the Debian
installer, but found that I can migrate system images via dd between
USB, SSD, and HDD. I need to test if these tricks work on Debian 8.
ZFS is the new way to do storage. I downloaded, installed, and ran ZFS
on Linux for a while, but had to write my own Debian boot and shutdown
integration scripts. (Ubuntu may have solved this.) I'm currently
migrating to ZFS file, backup, and archive services on FreeBSD.
On 04/19/2017 02:11 AM, tv.d...@googlemail.com wrote:
> A low-end small SSD would be a far better option in my opinion.
interactively.
David
commen...@riseup.net
May 10, 2017, 7:50:04 PM5/10/17
to
Hello,
On 2017-04-19 09:11, tv.d...@googlemail.com wrote:
> System on usb flash disks always caused me troubles, I use it only if
> the system can be loaded in ram at boot time and the drive isn't used
> for write operation. A low-end small SSD would be a far better option
> in my opinion.
Thanks for the advice. I managed to find a 40 Go Intel SSD, for under
30€ :)
Thank you for the detailed explanations.
I'm a complete noob when it comes to this kind of operations, so, sorry
for the dumb question : following tv.debian@'s advises, I purchased a
cheap SSD and installed my system on it (the SSD, and one pair of HDD
are plugged in). From there on, how should I proceed ?
Thanks in advanced for your help.
CA
On 2017-04-19 09:11, tv.d...@googlemail.com wrote:
> System on usb flash disks always caused me troubles, I use it only if
> the system can be loaded in ram at boot time and the drive isn't used
> in my opinion.
Thanks for the advice. I managed to find a 40 Go Intel SSD, for under
30€ :)
I'm a complete noob when it comes to this kind of operations, so, sorry
for the dumb question : following tv.debian@'s advises, I purchased a
cheap SSD and installed my system on it (the SSD, and one pair of HDD
are plugged in). From there on, how should I proceed ?
Thanks in advanced for your help.
CA
commen...@riseup.net
Jun 6, 2017, 8:00:08 AM6/6/17
to
Hello,
Giving this thread a UP, would anyone be able to help me?
On 2017-05-10 23:41, commen...@riseup.net wrote:
> I'm a complete noob when it comes to this kind of operations, so,
> sorry for the dumb question : following tv.debian@'s advises, I
> purchased a cheap SSD and installed my system on it (the SSD, and one
> pair of HDD are plugged in). From there on, how should I proceed ?
>
> Thanks in advanced for your help.
Best,
CA
Giving this thread a UP, would anyone be able to help me?
On 2017-05-10 23:41, commen...@riseup.net wrote:
> I'm a complete noob when it comes to this kind of operations, so,
> sorry for the dumb question : following tv.debian@'s advises, I
> purchased a cheap SSD and installed my system on it (the SSD, and one
> pair of HDD are plugged in). From there on, how should I proceed ?
>
> Thanks in advanced for your help.
CA
Andy Smith
Jun 7, 2017, 2:20:04 AM6/7/17
to
Hello,
On Wed, May 10, 2017 at 11:41:30PM +0000, commen...@riseup.net wrote:
> I'm a complete noob when it comes to this kind of operations, so, sorry for
> the dumb question : following tv.debian@'s advises, I purchased a cheap SSD
> and installed my system on it (the SSD, and one pair of HDD are plugged in).
> From there on, how should I proceed ?
What is your goal? Exactly what setup do you have now?
You are not making it easy for people to help you as your email does
not thread back to whatever you were discussing before. So I'm
afraid you'll have to remind us.
If you're just looking to set up software RAID with encryption, all
of that can be done from the Debian installer.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
On Wed, May 10, 2017 at 11:41:30PM +0000, commen...@riseup.net wrote:
> I'm a complete noob when it comes to this kind of operations, so, sorry for
> the dumb question : following tv.debian@'s advises, I purchased a cheap SSD
> and installed my system on it (the SSD, and one pair of HDD are plugged in).
> From there on, how should I proceed ?
You are not making it easy for people to help you as your email does
not thread back to whatever you were discussing before. So I'm
afraid you'll have to remind us.
If you're just looking to set up software RAID with encryption, all
of that can be done from the Debian installer.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
commen...@riseup.net
Aug 30, 2017, 7:50:06 AM8/30/17
to
Hello,
Sorry, I'll start again from the beginning :
Here is a picture of what I'm trying to achieve:
https://imgur.com/a/DAM8D (the "Today" column).
I am trying to build a home backup system. The system (Debian Stretch)
will be on a SSD. For the time being, I only have one pair of HDDs (the
"Today" column in the picture) ; in the future (the "Future" column), I
would like to add other pairs of HDD to store other kind of data.
This backup system will only be turned on when needed, I don't plan on
I would like everything to be encrypted (FDE), from the system (/ and
/swap) to the RAID1 drives.
Debian will be installed via a USB stick.
If possible, I would like to have different encryption keys for the
system and the various RAID1 pairs (in the "Future" column in the
picture, one for the system, one for "work", one for "family", one for
"misc"). So that I can give the system encryption passphrase, "family"
and "misc" ones to my wife and keep the "work" one for myself.
As stated in another mail of the thread, I'm a complete noob when it
comes to this kind of operations so I'm looking for a step by step ELI5
explanation (I have tried to use the Debian graphical installer to
achieve this but have failed because I was just messing around with the
options trying to figure out what to do).
For the sake of the discussion: here is the complete archive of this
thread
https://groups.google.com/forum/#!topic/linux.debian.user/jjdr6LXaOm8
You'll notice that Joshua Schaeffer provided what seems to be a complete
solution but I have no idea how to go from "I have my computer with all
the drives plugged in, Debian installer on USB stick and I launched the
graphical installer" to "enter these commands into a terminal to achieve
what you are trying to do" :
https://groups.google.com/d/msg/linux.debian.user/jjdr6LXaOm8/Pals7djzAAAJ
Note: I am not criticizing Joshua's answer in any way, I am grateful for
it, I am just underlying (once again) the fact that I am a noob on this
topic :)
Thank you in advance for your help :)
CA
PS: at the time of my first mail, Stretch wasn't the "stable" release
yet (I have now updated the title from "Jessie" to "Stretch")
Here is a picture of what I'm trying to achieve:
I am trying to build a home backup system. The system (Debian Stretch)
will be on a SSD. For the time being, I only have one pair of HDDs (the
"Today" column in the picture) ; in the future (the "Future" column), I
would like to add other pairs of HDD to store other kind of data.
This backup system will only be turned on when needed, I don't plan on
using it as some sort of server or a NAS.
We are talking about software RAID1.
I would like everything to be encrypted (FDE), from the system (/ and
/swap) to the RAID1 drives.
Debian will be installed via a USB stick.
If possible, I would like to have different encryption keys for the
system and the various RAID1 pairs (in the "Future" column in the
picture, one for the system, one for "work", one for "family", one for
"misc"). So that I can give the system encryption passphrase, "family"
and "misc" ones to my wife and keep the "work" one for myself.
As stated in another mail of the thread, I'm a complete noob when it
comes to this kind of operations so I'm looking for a step by step ELI5
explanation (I have tried to use the Debian graphical installer to
achieve this but have failed because I was just messing around with the
options trying to figure out what to do).
For the sake of the discussion: here is the complete archive of this
thread
https://groups.google.com/forum/#!topic/linux.debian.user/jjdr6LXaOm8
You'll notice that Joshua Schaeffer provided what seems to be a complete
solution but I have no idea how to go from "I have my computer with all
the drives plugged in, Debian installer on USB stick and I launched the
graphical installer" to "enter these commands into a terminal to achieve
what you are trying to do" :
https://groups.google.com/d/msg/linux.debian.user/jjdr6LXaOm8/Pals7djzAAAJ
Note: I am not criticizing Joshua's answer in any way, I am grateful for
it, I am just underlying (once again) the fact that I am a noob on this
topic :)
Thank you in advance for your help :)
CA
PS: at the time of my first mail, Stretch wasn't the "stable" release
yet (I have now updated the title from "Jessie" to "Stretch")
commen...@riseup.net
Aug 30, 2017, 8:10:06 PM8/30/17
to
(there was a problem with my subscription to the list, I am not sure
that my previous mail went through, copy/pasting it again just in case -
sorry for the spam if you received it twice)
Hello,
On 2017-06-07 06:11, Andy Smith wrote:
that my previous mail went through, copy/pasting it again just in case -
sorry for the spam if you received it twice)
Hello,
On 2017-06-07 06:11, Andy Smith wrote:
Sorry, I'll start again from the beginning :
Here is a picture of what I'm trying to achieve:
https://imgur.com/a/DAM8D (the "Today" column).
I am trying to build a home backup system. The system (Debian Stretch)
will be on a SSD. For the time being, I only have one pair of HDDs (the
"Today" column in the picture) ; in the future (the "Future" column), I
would like to add other pairs of HDD to store other kind of data.
This backup system will only be turned on when needed, I don't plan on
I am trying to build a home backup system. The system (Debian Stretch)
will be on a SSD. For the time being, I only have one pair of HDDs (the
"Today" column in the picture) ; in the future (the "Future" column), I
would like to add other pairs of HDD to store other kind of data.
using it as some sort of server or a NAS.
David Christensen
Aug 31, 2017, 12:00:05 AM8/31/17
to
On 08/30/17 04:28, commen...@riseup.net wrote:
...
STFW you might find step-by-step instructions for something similar to
what you want, but this is Linux and the whole point is to learn enough
to do it yourself.
The most common Linux encryption technology is variously called LUKS and
dm-crypt. The command-line administration tool is cryptsetup(8).
There are at least two ways to do software RAID on Linux:
1. MD arrays -- the administration tool is mdadm(8).
2. LVM RAID -- the administration tool is lvm(8).
Start by STFW the underlying technologies:
https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
https://en.wikipedia.org/wiki/Mdadm
https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
Then RTFM the tools:
https://linux.die.net/man/
If you want to combine encryption and RAID 1, you're going to need to
choose between encrypting one RAID volume or RAID'ing two encrypted
volumes. There are trade-off's either way. A primary consideration
will be whether or not you have a processor with AES-NI:
https://en.wikipedia.org/wiki/AES_instruction_set
Read up the links above and then post when you're ready.
David
...
what you want, but this is Linux and the whole point is to learn enough
to do it yourself.
The most common Linux encryption technology is variously called LUKS and
dm-crypt. The command-line administration tool is cryptsetup(8).
There are at least two ways to do software RAID on Linux:
1. MD arrays -- the administration tool is mdadm(8).
2. LVM RAID -- the administration tool is lvm(8).
Start by STFW the underlying technologies:
https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
https://en.wikipedia.org/wiki/Mdadm
https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
Then RTFM the tools:
https://linux.die.net/man/
If you want to combine encryption and RAID 1, you're going to need to
choose between encrypting one RAID volume or RAID'ing two encrypted
volumes. There are trade-off's either way. A primary consideration
will be whether or not you have a processor with AES-NI:
https://en.wikipedia.org/wiki/AES_instruction_set
Read up the links above and then post when you're ready.
David
commen...@riseup.net
Aug 31, 2017, 9:40:06 AM8/31/17
to
Hello,
Thank you for your answer.
I did, I couldn't find anything extensive enough.
I'm not asking "just tell me what to do", I'm asking "people have
undoubtedly already done that, please share your experience with me,
tell we what to do and explain me what I'm doing". If I wanted to get
something working out the box, or somebody doing the work for me, I just
would have purchased a Synology or the likes.
As you said, this is Linux, and part of the cake is its community.
> The most common Linux encryption technology is variously called LUKS
> and dm-crypt. The command-line administration tool is cryptsetup(8).
>
> There are at least two ways to do software RAID on Linux:
>
> 1. MD arrays -- the administration tool is mdadm(8).
> 2. LVM RAID -- the administration tool is lvm(8).
>
> Start by STFW the underlying technologies:
>
> https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
>
> https://en.wikipedia.org/wiki/Mdadm
>
> https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
>
> Then RTFM the tools:
>
> https://linux.die.net/man/
>
> If you want to combine encryption and RAID 1, you're going to need to
> choose between encrypting one RAID volume or RAID'ing two encrypted
> volumes. There are trade-off's either way. A primary consideration
> will be whether or not you have a processor with AES-NI:
>
> https://en.wikipedia.org/wiki/AES_instruction_set
I don't :
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.
Does it have any impact on the reliability of the setup? 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? Should I care about the
"system" redundancy? Are the encryption keys stored on the "system"
drive or on the RAID drives (one of them, both?) ?
> Read up the links above and then post when you're ready.
I am all for the RTFM approach nevertheless, this is like telling
someone who is trapped in a nuclear facility with leaking hazardous
material and asking for a way out : "here are the blueprints for the
facility, the 1200 pages `The Art of Electronics` book, and a playlist
of defcon talks about lockpicking, call us back when you're all set, if
you prove you can hack the lock, we'll give you the code to get out".
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.
CA
Thank you for your answer.
I'm not asking "just tell me what to do", I'm asking "people have
undoubtedly already done that, please share your experience with me,
tell we what to do and explain me what I'm doing". If I wanted to get
something working out the box, or somebody doing the work for me, I just
would have purchased a Synology or the likes.
As you said, this is Linux, and part of the cake is its community.
> The most common Linux encryption technology is variously called LUKS
> and dm-crypt. The command-line administration tool is cryptsetup(8).
>
> There are at least two ways to do software RAID on Linux:
>
> 1. MD arrays -- the administration tool is mdadm(8).
> 2. LVM RAID -- the administration tool is lvm(8).
>
> Start by STFW the underlying technologies:
>
> https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
>
> https://en.wikipedia.org/wiki/Mdadm
>
> https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
>
> Then RTFM the tools:
>
> https://linux.die.net/man/
>
> If you want to combine encryption and RAID 1, you're going to need to
> choose between encrypting one RAID volume or RAID'ing two encrypted
> volumes. There are trade-off's either way. A primary consideration
> will be whether or not you have a processor with AES-NI:
>
> https://en.wikipedia.org/wiki/AES_instruction_set
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.
Does it have any impact on the reliability of the setup? 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? Should I care about the
"system" redundancy? Are the encryption keys stored on the "system"
drive or on the RAID drives (one of them, both?) ?
> Read up the links above and then post when you're ready.
someone who is trapped in a nuclear facility with leaking hazardous
material and asking for a way out : "here are the blueprints for the
facility, the 1200 pages `The Art of Electronics` book, and a playlist
of defcon talks about lockpicking, call us back when you're all set, if
you prove you can hack the lock, we'll give you the code to get out".
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.
CA
David Christensen
Sep 1, 2017, 1:30:05 AM9/1/17
to
On 08/31/17 06:35, commen...@riseup.net wrote:
> I don't [have a CPU with AES-NI):
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
> 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
> 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
>
> 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.
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?
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?
(?).
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?
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?) ?
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.
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
0 new messages