Oh no, what have I done...

[Chris Ross]

> On Aug 13, 2017, at 09:54 , Volodymyr Kostyrko <arcade at b1t.name> wrote:
> 
> Paul Kraus wrote:
> 
>> Using zdb you can examine the TXGs and there is a way to force an import to a certain TXG (at least under Illumos there is, I assume the FBSD ZFS code is the same). I do not remember the specific procedure, but it went by on one of the ZFS mailing lists a few years ago. The goal at the time was not to deal with a changed pool configuration but a series of writes that corrupted something (possibly due to a feature being turned on at a certain point in time). You would lose all data written after the TXG you force the import to.
>> 
>> Looking at the manpages for zpool and zdb, it looks like doing this has gotten easier with `zdb -e -F` … operate on exported pool and rollback TXG until the pool is importable … but I’m sure there are limits :-)
> 
> That's -T, it was intentionally left undocumented.
> 
> /usr/src/cddl/contrib/opensolaris/cmd/zpool/zpool_main.c /starting txg

  Thanks Peter, Paul, Volodymyr, and all.  So I got my pool back online, just in a way I don’t like it, so I’m trying to find a place I can export (zfs send) the 5+ TB of data.  Disadvantage of having my largest data-store machine be the problem machine.  :-)

  But, were I in a state as I was earlier in recent days, and I understand the above, I might’ve been able to “zfs import -T” to a TXG that was before I added the single-drive vdev, and it would’ve imported just the working raidz1 and been okay?  If any data had been written in the very small time the new vdev was added, that would be lost, but I would’ve been fine with that.

  And, if I understand correctly, I would’ve used “zdb” to find out what the TXG that I wanted to refer to was?  Paul, you mention using zdb against an exported pool, which of course I didn’t have.  Could I have found the old TXG to import from without having an export?  Just that that seems to be the gap I’m missing in the above.

  But, all is well.  Or at least, 99+% recoverable, it seems.  Thank you all for your time and information.  What do rebuild after I find a way to back the pool up will be this next weeks problem.

               - Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20170813/da388900/attachment.sig>