Re: dk for z/lvm volumes?

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Wed, 26 Feb 2020 at 19:28, Staffan Thomén <duck%shangtai.net@localhost> wrote:
>
> Replying to you both in one here..
>
> Chavdar Ivanov wrote:
> > On Wed, 26 Feb 2020 at 18:18, Greg Troxel<gdt%lexort.com@localhost>  wrote:
> >> Staffan Thomén<duck%shangtai.net@localhost>  writes:
> >>> I couldn't coax dkctl to create dk devices for the gpt on the volume,
> >>> and dkctl seems like a bit of a mismatch for creating arbitrary dk:s
> >>> anyway as it seems mostly directed at bare drives (cache settings
> >>> etc).
> >>  From the NetBSD point of view there is a zvol, and you are letting iscsi
> >> manage it.  So there's nothing to tell netbsd to read a gpt/mbr and
> >> deal.
>
> Indeed, but that's where dkctl comes in with makewedges to tell netbsd to scan
> for wedges, but that doesn't work (wonderfully it says "Read-only file system"
> on the (admittedly read only) volume snapshot).
>
> >> The other thing you can do is export the zvol snapshot via iscsi and use
> >> an iscsi initiator on netbsd to mount it.
>
> This would work, but seems like a bit of a pretzel of a solution. What I'm
> mostly wondering is if it wouldn't be sensible to extend dk to be able to be
> used with volumes.
>
>  > [...] perhaps looking at it
> > from the Windows initiator would have more sense - unless the backup
> > is supposed to be done on the NetBSD host, in which case the
> > suggestion would be to
> > # zfs send pail/nbsd1>  nbsd1.zfsfs
> >
> > and then backup the resulting zfs stream, which you can cmpress of course.
>
> Yup, this would definitely work, but it's terribly inefficient on tape use
> since I can't do block-level differential backups. Whenever the volume
> filesystem changes, I have to backup the entire thing.

True. If I were to figure out a backup system like this, I'd try to
introduce a second zfs server, send the zvol snapshot there and iSCSI
share it there; this way I would have the option of incremental
backups with the benefit of a half-way house server for the backups.
We had similar system - Nexenta based - a few years ago in my former
company, whereby the main Nexenta servers sent the zfs streams to
another local Nexenta server, which then sent the incremental
snapshots offsite to a third Nexenta server (which was the SAN for our
DR site). It was a bit of a mess with the whole Nexenta stuff - weird
encrypted perl scripts - and a bunch of shell stuff to bind them over,
but we were able on a weekly basis to bring back the whole enterprise
network running in the DR site (obviously offline, as we never had the
reason to actually use it in anger).

All this is dead now, so no big deal discussing it.


>
> Staffan



-- 
----