Closed GoogleCodeExporter closed 9 years ago
If you do `diskutil list`, are the ZFS partitions still there?
Can you do a `zpool import <pool>` if the partitions exist?
Original comment by druro...@gmail.com
on 24 Feb 2012 at 8:58
Sadly no, I get this:
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *999.5 GB disk3
1: 0xEE 999.5 GB disk3s1
Looking around I got the tool gdisk (and hopefully am not doing stupid things)
i see this when i print out the GPT:
Number Start (sector) End (sector) Size Code Name
1 40 409639 200.0 MiB EF00 EFI System Partition
2 409640 1951889367 930.5 GiB BF01 %noformat%
121 72057594172145664 576460752303423488 224.0 EiB FFFF
122 7813586405489115136 431266031455 4.6 ZiB FFFF 鎈鯞ꅼ턭
123 16777216 2305843009230471168 1024.0 EiB FFFF 祴数
124 720575940396056576 8316288341928928303 3.3 ZiB FFFF
125 576460752303453286 16777216 7.8 ZiB FFFF
I then decided to delete the crazy 121-125 partitions...(hope i didn't do
something stupid). I am hoping that my data is still secure in the correct
partition 2.
Now what I see when I run diskutil list:
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *999.5 GB disk3
1: EFI 209.7 MB disk3s1
2: ZFS 999.2 GB disk3s2
seems to bring me back to a good state! But not sure what to do next...
Original comment by markanth...@med.ge.com
on 24 Feb 2012 at 10:49
I tried the zpool import MediaHD and I get.
cannot import 'MediaHD': pool may be in use from other system
use '-f' to import anyway
If I reboot, I am back to square 1 with the corrupted GPTs...
My main concern is getting the data off the partitions, any tool to help me
recover those files?
Super thanks for your help!
Original comment by markanth...@med.ge.com
on 24 Feb 2012 at 10:55
Partition type 0xEE is a composite type of MBR and GPT. Not sure why it's being
labeled as that. Maybe someone else here has seen this before?
Did you try doing `zpool import -f MediaHD` to see if you could import the pool
anyways? If you can make it mount, your data recovery will be much easier while
you figure out why the partition table keeps freaking out.
Original comment by druro...@gmail.com
on 25 Feb 2012 at 12:31
Sadly no, it tells me that the pool is in use and won't let me.
Original comment by markanth...@med.ge.com
on 25 Feb 2012 at 6:11
I tried looking at standard tools to get data off drives, like disk drill, but
it does not recognize the drives so i cannot even start to a deep scan or
anything to get the data off.
I have a backup, but not sure of exactly whats missing from there and the
"event" , but wanted to try anything i can before going that route to not lose
that.
Original comment by markanth...@med.ge.com
on 25 Feb 2012 at 8:05
okay, I tried 'zpool import -f MeidaHD' and it works; but, now the disk is
empty! :(
In my struggles, i did re-run the procedures in getting started without the
format part, in hopes that recreating the pool would bring back the
data...seems like its gone now!
Anyway to get the data off?
Thanks again for the help...
Original comment by markanth...@med.ge.com
on 26 Feb 2012 at 11:36
Recreating the pool recreates the four copies of the Uberblock, I'm pretty
sure. At this point, you /might/ be out of luck, since ZFS' on-disk format is
fairly complex (see PDF in download section if you want to know).
The problem is, without a good Uberblock, there is no easy or sure way of
finding the root of the filesystem(s). The Copy-On-Write means that you could
find a tree, but it may be out of date... worse, it could be from the new pool,
and is a dead end.
Worst case: The pool recreation has clobbered the old data and there are large
chunks of it that can't be recreated due to missing metadata.
Best case: The pool recreation has only clobbered the Uberblock, and data
recovery involves sitting with a hex editor and something to take notes with to
look for trees.
Original comment by druro...@gmail.com
on 26 Feb 2012 at 9:31
Actually, you might still have a good copy of the Uberblock you need, or
something close to it. Just take the pool offline to ensure it doesn't get
written to any more.
_TAKE_ _THE_ _POOL_ _OFFLINE_ _NOW_
Someone else here that knows about how zpool initializing works: Is the entire
Uberblock array written to? or does it just write as needed?
Original comment by druro...@gmail.com
on 26 Feb 2012 at 9:37
> okay, I tried 'zpool import -f MeidaHD' and it works; but, now the disk is
empty! :(
>
> In my struggles, i did re-run the procedures in getting started without the
format
> part, in hopes that recreating the pool would bring back the data...seems
like its
> gone now!
Yes, the data is gone. When you did a 'zpool create' you overwrote all the
uberblocks which pointed to the valid data. Ironically if you had done the
format but not the pool create then you might have got the data back.
I am not aware of low-level block scanning blocks which will fix the problem at
hand; the solution at this point is to restore from a backup/snapshot elsewhere.
The ZFS on-disk format is documented as per the download artifacts:
http://maczfs.googlecode.com/files/ZFSOnDiskFormat.pdf
The uberblock magic field is 0x00bab10c (or 0x0cb1ba00 depending on
endianness), which I think you wrote over when you did your second zpool
create. You might be able to write a program which would re-construct the
uberblocks based on the pointer to the entry on disk.
The suggestion, as with any data recovery, is to take a bitwise copy of the
disk first and then use the copy to do any data recovery from. That way you can
always create more bit copies to work from instead of potentially corrupting it
even further.
This isn't really an issue with MacZFS so I'm going to close this issue.
Original comment by alex.ble...@gmail.com
on 7 Mar 2012 at 11:21
Original issue reported on code.google.com by
markanth...@med.ge.com
on 24 Feb 2012 at 2:33