David Christensen wrote: > On 3/17/23 19:25, Gregory Seidman wrote: > > On Fri, Mar 17, 2023 at 06:05:27PM -0700, David Christensen wrote: > > > On 3/17/23 12:36, Gregory Seidman wrote: > > [...] > > > > This thread has piqued my interest, because I have been lax in doing > > > > proper > > > > backups. I currently run a RAID1 mirroring across three disks (plus a > > > > hot > > > > spare). On top of that is LUKS, and on top of that is LVM. I keep > > > > meaning > > > > to manually fail a disk then store it in a safe deposit box or > > > > something as > > > > a backup, but I have not gotten around to it. > > > > > > > > It sounds to me like adding an iSCSI volume (e.g. from AWS) to the RAID > > > > as > > > > an additional mirror would be a way to produce the off-site backup I > > > > want > > > > (and LUKS means I am not concerned about encryption in transit). It also > > > > sounds like you're saying this is not a good backup approach. Ignoring > > > > cost, what am I missing? > > > > > > > > > Reco > > > > --Gregory > > > > > > I would not consider using a cloud device as a RAID member -- that sounds > > > both slow and brittle. Live data needs to be on local hardware. > > [...] > > > > Thinking about it more, that makes sense. Maybe the right approach is to > > split the difference. I can manually fail a mirror, dd it over to an iSCSI > > target, then re-add it. > > > If you are serious about iSCSI, I suggest evaluating it. Build a RAID1 > using two local disks. Benchmark it. Run it through various > failure-recovery use-cases. Then add an iSCSI volume on another host in the > LAN, repeat the benchmarks, and repeat the failure-recovery use-cases. Then > add an iSCSI volume in the cloud, repeat the benchmarks, and repeat the > failure-recovery use-cases. I would be interested in reading the results.
I can think of a few cases where this would not be horribly slow, but no cases where performance is likely to be smooth and uninterrupted. > > > On 3/17/23 13:52, Dan Ritter wrote: > Some people have to deal with "audit" and "discovery". Usually people know if they have to deal with audit when they set a system up. Occasionally people know they they will be dealing with discovery; more often it becomes a requirement post hoc. > I use old-school ZFS-on-Linux (ZOL), which does not have built-in > encryption. So, I encrypt each partition below ZFS. A pool with many > partitions could multiply the CPU cryptographic workload. I make sure to > buy processors with AES-NI. > > > The Debian stable zfs-dkms package is the newer OpenZFS. It may support > built-in encryption. I do not know how the cryptographic efficiency > compares. It does. Efficiency is similar. -dsr-
