killing at multiplay.co.uk
Fri Jun 7 07:57:59 UTC 2019
Great to hear you got your data back even after all the terrible luck you
On Fri, 7 Jun 2019 at 00:49, Michelle Sullivan <michelle at sorbs.net> wrote:
> Michelle Sullivan wrote:
> >> On 02 May 2019, at 03:39, Steven Hartland <killing at multiplay.co.uk>
> >>> On 01/05/2019 15:53, Michelle Sullivan wrote:
> >>> Paul Mather wrote:
> >>>>> On Apr 30, 2019, at 11:17 PM, Michelle Sullivan <michelle at sorbs.net>
> >>>>> Been there done that though with ext2 rather than UFS.. still got
> all my data back... even though it was a nightmare..
> >>>> Is that an implication that had all your data been on UFS (or ext2:)
> this time around you would have got it all back? (I've got that impression
> through this thread from things you've written.) That sort of makes it
> sound like UFS is bulletproof to me.
> >>> Its definitely not (and far from it) bullet proof - however when the
> data on disk is not corrupt I have managed to recover it - even if it has
> been a nightmare - no structure - all files in lost+found etc... or even
> resorting to r-studio in the even of lost raid information etc..
> >> Yes but you seem to have done this with ZFS too, just not in this
> particularly bad case.
> > There is no r-studio for zfs or I would have turned to it as soon as
> this issue hit.
> So as an update, this Company: http://www.klennet.com/ produce a ZFS
> recovery tool: https://www.klennet.com/zfs-recovery/default.aspx and
> following several code changes due to my case being an 'edge case' the
> entire volume (including the zvol - which I previously recovered as it
> wasn't suffering from the metadata corruption) and all 34 million files
> is being recovered intact with the entire directory structure. Its only
> drawback is it's a windows only tool, so I built 'windows on a stick'
> and it's running from that. The only thing I had to do was physically
> pull the 'spare' out as the spare already had data on it from being
> previously swapped in and it confused the hell out of the algorithm that
> detects the drive order.
> Michelle Sullivan
More information about the freebsd-stable