Date: Sun, 13 Aug 2017 12:55:25 -0400 From: Chris Ross <cross+freebsd@distal.com> To: Volodymyr Kostyrko <arcade@b1t.name> Cc: freebsd-fs@freebsd.org Subject: Re: Oh no, what have I done... Message-ID: <8EE368A2-D2BA-4E43-8B84-47E8F50B5B1B@distal.com> In-Reply-To: <1d3771a3-9c3a-1af9-9c48-032a01629630@b1t.name> References: <3408A832-BF2E-4525-9EAC-40979BA3555B@distal.com> <20170813000323.GC95431@server.rulingia.com> <5B508AED-4DAC-42E4-8C56-4619C0D1A1C6@distal.com> <035BFBCB-BA43-4568-89E9-8E8DCDFAA8CA@kraus-haus.org> <928F1F16-0777-4D66-BD27-8224DF80363C@distal.com> <06EEEF86-E466-44EA-86F1-866DA32DD92D@kraus-haus.org> <1d3771a3-9c3a-1af9-9c48-032a01629630@b1t.name>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
> On Aug 13, 2017, at 09:54 , Volodymyr Kostyrko <arcade@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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJZkISGAAoJEPFBDnXvoNg0wVwP/jT7fT/cy5SpJAvBIOyQ4SIZ
ifaWO8u/lyAVJQGOUpqR4RGmZWSlxmn3IzLhInPFxXV9PGjzRDUJrDSGza2RWV8k
Kzj2wSQEJGUmbEYlSY8ssZ51wMsjcFLrfsKAzJgfFztsy6XOdUR+3sGWAZKA/t7M
B1lCgr+75rlfQZrX52aZOw3n3+S9c/Z5ggHBoAvw3gT66JOqyKbm2IkjyWj+1A50
QYIpuOB9InjGB22Uk3zk07wUDSxngjby9LBcbBArUl94yQkuBhmwB3TqbGxQiyeV
WOpipLycDyaLjrlw+srfYhyiLDXS0vpI7ZGvzTN+dffUGb+skEBjZevfSPxLx1gR
SIW2GI1Bw70ChOpeW9tqrCAdOKwYEZnv47XN3PrSc2Ziu2K3XTmHXalXmLPXn04i
RYYl1GshEguCGfxJCkWF+dnMoU3g/LSD6OdjMy4n4QbOG/nWuSrFeMDWf9vquL20
zJvYT9gma5saBSvPUS4Ubbtk58yB5Dz5Hl4JSBxh3LWjFCRRNEwMDTe8znyYF30H
lV/SrxTXoDyIh+Y2BUeJfgafHcX34vYwh6T+iHNfyIc9tfwDMldyCY5eoY+S5mR7
n02qOlGxV0dEiM6nkl0O99WwcpF8T7fbiaTxfnBlzJXB3X9NDjCn6N4cSFL3qBj9
MEXAmoYugAopC+8L87ZS
=g833
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8EE368A2-D2BA-4E43-8B84-47E8F50B5B1B>