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

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: