Re: ZFS rollback snapshot general question

On 6/26/26 20:30, Kevin P. Neal wrote:
> On Fri, Jun 26, 2026 at 10:14:17AM -0400, Bobb Shires wrote:
>> Hi Kevin... Yes, I knew I had done something incorrectly.
>> Thanks for the reminder.
> 
> I meant it as an explanation of why it went south on you, that's all.
> 
> ZFS has too many footguns.
> 
>> On Thu, Jun 25, 2026, at 21:11, Kevin P. Neal wrote:
>>> Really, the rollback should have been blocked and not allowed.
> 
> Seriously, this particular case really should have been stopped by the
> kernel. And why did it give you a script/command without a warning that
> it shouldn't be used on a running system? That's not very friendly.
> 
> The cases that always get me are the ones where I accidentally mount a
> filesystem over top of another one, typically the root filesystem. That's
> a bad day when I have to drive out to the datacenter because my server
> can't reboot with / overlaid by some other dataset like, for example, a
> root filesystem for a newer version of FreeBSD. Wow do I hate that.
> 
> And I hate that I keep finding more ways to make the same mistake. For
> example, a "zfs send | zfs receive" of /usr/local to a new boot environment
> will mount the new /usr/local over top of the already mounted /usr/local
> and ruin my ongoing poudriere builds. Well, unless I remember to use the
> "-u" option on the receiving end. Which I didn't remember on my upgrade
> to 15.1.  *sigh*

I avoid such misuse something like:

zfs send -LeRI older_snapshot pool_name@newer_snapshot|zfs recv -Fx 
mountpoint -x sharesmb -x sharenfs -x checksum -x compression -x atime 
-x refreservation -x readonly backup_pool/backups/pool_name

and restore with:

zfs send -bLeRv backup_pool/backups/pool_name@newer_snapshot|zfs recv 
pool_name

this creates an override of each of the -x properties so that the 
properties of the backup are what are actually used on the backup copy 
and -b will use the non-overridden property. This makes it possible to 
improve quality of life with things like backups getting a different 
higher compression while also performing necessary adjustments like 
overriding mountpoints to avoid the backup automounting on top of the 
running system (a truly horrible thing to have ZFS do to its 
unsuspecting users and needs big warnings added for in the docs; makes 
ZFS users appreciate the days and ways of fstab).

Though a different issue, refreservation if set based on a pool's size 
in just another example of how transferring between two different pools 
could go anywhere from an annoyance to drastically wrong just because of 
an overlooked ZFS setting. There may be more that are needs and wants to 
override but this likely matched a lot of cases and made a good example.

I know my memory is not good enough to remember these commands properly 
to guarantee I can avoid breaking things, the less important parts I'd 
still prefer to get right without lots of slow reading, and I'd prefer 
that even typos are not something I have to worry about. Such commands I 
save in a file and I "carefully" copy+edit to avoid all these issues; 
I'd use a script but I never took the time to write one that accounts 
for the always-changing snapshot names without being error prone.

If I wasn't working from such notes and scripts, I would never include 
`recv` in a backup and only use it on a restore do to the problems that 
ZFS defaults during replication cause.

> I have used zfs rollback before, but never in a case where the kernel
> should have stopped me. You got unlucky. Myself, I find other ways to get
> unlucky instead.
> 
> I like ZFS, but man is it easy to get into trouble with it.