zfs discuss - Jun 2012 - Restore destroyed snapshot ???

OK, I am a butt-head and accidentally destroyed my last snapshot of a
replicated ZFS dataset. The dataset is NOT mounted and other than a
resilver going on, there is no I/O going on to this dataset. Is there
any way to roll back and get my latest snapshot back?

from zpool history -i:

2012-06-18.10:34:00 zfs destroy xxx at 1339668001
2012-06-18.10:34:00 [internal destroy txg:2213852] dataset = 1906
2012-06-18.10:34:07 zfs destroy xxx at 1339671601
2012-06-18.10:34:07 [internal destroy txg:2213854] dataset = 1921
2012-06-18.10:34:14 zfs destroy xxx at 1339675201
2012-06-18.10:34:14 [internal destroy txg:2213856] dataset = 1938
2012-06-18.10:34:24 zfs destroy xxx at 1339678800

I accidentally destroyed one too many snapshots (I wanted to keep just
the latest so that I could still do an incremental send/ recv from the
source end, this is a 40 TB dataset).

I figure that since there have been no writes since I did the destroy
then I *might* have a chance at this ... HELP!

-- 
{--------1---------2---------3---------4---------5---------6---------7---------}
Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Assistant Technical Director, LoneStarCon 3 (http://lonestarcon3.org/)
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, Troy Civic Theatre Company
-> Technical Advisor, RPI Players

2012-06-18 19:39, Paul Kraus wrote:
> OK, I am a butt-head and accidentally destroyed my last snapshot of a
> replicated ZFS dataset. The dataset is NOT mounted and other than a
> resilver going on, there is no I/O going on to this dataset. Is there
> any way to roll back and get my latest snapshot back?
AFAIK you can roll back the pool to one of the TXG numbers saved
in the uberblock ring (128 entries for 512b native sector disks,
32 entries for 4KB sectored disks). ZFS does not (yet) guarantee
that the freed blocks from those last N-127 TXGs won''t be further
overwritten - these are not (yet) rolling snapshots, but there
are often good chances to pick a valid state (or one with few
errors; though checking for those may take long).

The problem is that the TXGs are synced to disk every 5 seconds
(or 30sec in some builds), which gives you about 10 minutes to
export the pool until you do rollbacks/repairs, or perhaps then
you can mount it read-only.

While undeletions might logically be done, or at least attempted,
i.e. to recover the deleted dataset (snapshot) while the rest of
the pool is not rolled back, I don''t know of a mechanism for that.

As it stands now, rollbacks are one-way (uberblocks with newer
TXG numbers are, AFAIK, explicitly invalidated (zeroed out)).
I don''t know how/if rollbacks work with read-only imports, if
they allow to inspect a pool at TXG number N without forfeiting
its newer changes.

HTH,
//Jim Klimov