recover file from destroyed zfs snapshot - is it possible?
greg at bonett.org
Thu Jun 9 22:43:47 UTC 2011
On Thu, 2011-06-09 at 14:57 -0700, Artem Belevich wrote:
On Thu, Jun 9, 2011 at 1:00 PM, Greg Bonett <greg at bonett.org> wrote:
> > Hi all,
> > I know this is a long shot, but I figure it's worth asking. Is there
> > anyway to recover a file from a zfs snapshot which was destroyed? I
> > the name of the file and a unique string that should be in it. The
> > pool is on geli devices so I can't dd the raw device and look for
> > Any suggestions?
> > Thanks for the help.
> Theoretically it may be possible. Practically it will not be trivial.
> ZFS state at any given point in time is determined by it's uberblock.
> ZFS keeps number of previous uberblocks (and thus -- ZFS states). If
> you're familiar with ZDB and with ZFS filesystem layout, you may be
> able to use information in the last saved uberblock before the
> snapshot was nuked and, with some luck, would be able to find the data
> tat was in your file. That, however, relies on an optimistic
> assumption that a) such uberblock is still around and, b) appropriate
> disk blocks have not been reused by more recent transactions.I believe
> recent ZFS versions (v28 should qualify) make an effort to keep recent
> transaction groups in consistent state to improve chances of recovery
> with "zpool import -F" in case disks lied about cache flushes.
> In case you do want to dig in, ZFS on-disk data structures are
> This script (WARNING -- DESCTRUCTIVE) should allow you to roll back
> ZFS state to an earlier point in time on single-device pools:
> Good luck.
Thanks for the response. I'll follow these links and see if I think I
can pull it off.
One question though, you say it's necessary that "appropriate
disk blocks have not been reused by more recent transactions"
Is it not possible for me to just read all the disk blocks looking for
the filename and string it contained? How big are disk blocks, is it
possible the whole 16k file is on one or a few contiguous blocks?
> P.S. You wouldn't happen to have backup of your file, would you? That
> would make things so much easier. :-)
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable