Re: RAID1 + iSCSI as backup (was Re: More RAID weirdness: external RAID over network)
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-
Reply to: