编辑1：与我在创建这个问题时最初的想法不同，似乎问题不是由计划外的电源循环直接引起的，而是我过去可能用 beadm 做的一个错误，并且它变得有效只是由于从那时起第一次重新启动。
这是（并且仍然是）问题的实际核心：
我认为自该快照以来的大多数更改应该仍然存在于磁盘上的某个位置。是否有任何远程机会（没有为原始设备编写我自己的 zfs-reader）来访问自上次快照以来更改的特定文件？
评论中要求的更多信息：
珠列表
BE Name Flags Mountpoint Space Policy Created
---------------- ----- ---------- ------- ------ ----------------
11.4.23.69.3 NR / 73.93G static 2020-07-27 12:08
solaris - - 95.53G static 2020-05-23 19:35
solaris-backup-1 - - 374.41M static 2020-07-22 14:37
zfs 列表：
NAME USED AVAIL REFER MOUNTPOINT
rpool 382G 713G 73.5K /rpool
rpool/ROOT 170G 713G 31K none
rpool/ROOT/11.4.23.69.3 75.5G 713G 63.3G /
rpool/ROOT/11.4.23.69.3/var 3.12G 713G 1.14G /var
rpool/ROOT/solaris 94.2G 713G 143G /
rpool/ROOT/solaris-backup-1 98.9M 713G 48.5G /
rpool/ROOT/solaris-backup-1/var 1K 713G 1.13G /var
rpool/ROOT/solaris/var 503M 713G 1.29G /var
rpool/VARSHARE 102M 713G 24.7M /var/share
rpool/VARSHARE/kvol 27.7M 713G 31K /var/share/kvol
rpool/VARSHARE/kvol/dump_summary 1.22M 713G 1.02M -
rpool/VARSHARE/kvol/ereports 10.2M 713G 10.0M -
rpool/VARSHARE/kvol/kernel_log 16.2M 713G 16.0M -
rpool/VARSHARE/pkg 63K 713G 32K /var/share/pkg
rpool/VARSHARE/pkg/repositories 31K 713G 31K /var/share/pkg/repositories
rpool/VARSHARE/sstore 30.0M 713G 30.0M /var/share/sstore/repo
rpool/VARSHARE/tmp 20.0M 713G 20.0M /var/tmp
rpool/VARSHARE/zones 31K 713G 31K /system/zones
rpool/dump 63.1G 713G 63.1G -
rpool/export 20.5G 713G 32K /export
rpool/export/home 20.5G 713G 7.26G /export/home
rpool/export/home/avl 9.30G 713G 9.30G /export/home/avl
（大部分 - 除了我的 homedir - 是机器附带的）
只有根文件系统似乎已被回滚，我的 homedir 仍然有所有最近的文件。
根据df -kl根文件系统的输出，当前是这个：rpool/ROOT/11.4.23.69.3，它已经对应于可用的最新 BE。
我也希望从答案中了解真正可能导致回滚的原因。不，我不完全记得我的 beadm 调用。我只记得我为下次启动更改了 BE，但随后将其更改回当前的 BE 并且没有重新启动 - 直到电源故障。
也许这里的答案也可能会在以后拯救其他人。