[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)



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.

> On 3/17/23 13:52, Dan Ritter wrote:
> > Three different things:
> >
> > resiliency in the face of storage failure: RAID.

And what I'm really trying to achieve is resiliency in the face of all the
drives failing, e.g. due to a fire or other catastrophe.

> > restoration of files that were recently deleted: snapshots.

I don't have automated LVM snapshotting set up, but I could and probably
should. That would cover that use case.

> > complete restoration of a filesystem: backup.

This can be achieved with the same off-site full-disk backup.

> > (and technically, a fourth: complete restoration of points in
> > time: archives).

That isn't a use case I've considered, and I don't think it's a use case I
have.

[...]
> > -dsr-
[...]
> I would add:
> 
> * ECC memory.

In place, yes.

> * Check-summing filesystems (I prefer ZFS-on-Linux).
[...]
> With four disks, the OP could use two in a ZFS mirror for live data, use
> zfs-auto-snapshot for user-friendly recovery, and use the other two
> individually as on-site and off-site backup media.

I do like the checksumming ZFS offers. The main reason I haven't switched
to ZFS, aside from already having a working setup with RAID/LUKS/LVM and
not wanting to fix what isn't broken, is that ZFS encryption is per volume
instead of the entire pool overall. That means that I either need to create
an encrypted ZFS volume for each of my existing LVM filesystems,
multiplying the hassle of unlocking them all, or I need to create a single
encrypted ZFS volume and put LVM on top of it. Is there a better way?

> David
--Gregory


Reply to: