Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I had a ZFS pool -- a mirror containing 2 vdevs -- running on a FreeBSD server. I now have only one of the disks from the mirror, and I am trying to recover files from it.

The ZFS data sits in a GPT partition on the disk.

When I try to import the pool, there's no sign that it exists at all. I have tried a number of approaches, but nothing happens.

I have run zdb -lu on the partition, and it seems to find the labels just fine.

# zpool import
# zpool import -D
# zpool status
no pools available
# zpool import -f ztmp
cannot import 'ztmp': no such pool available
# zpool import 16827460747202824739
cannot import '16827460747202824739': no such pool available

Partition information:

# gpart list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
   Mediasize: 65536 (64K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 17408
   Mode: r0w0e0
   rawuuid: d7a10230-8b0e-11e1-b750-f46d04227f12
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 65536
   offset: 17408
   type: freebsd-boot
   index: 1
   end: 161
   start: 34
2. Name: da0p2
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 82944
   Mode: r0w0e0
   rawuuid: d7aa40b7-8b0e-11e1-b750-f46d04227f12
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 17179869184
   offset: 82944
   type: freebsd-swap
   index: 2
   end: 33554593
   start: 162
3. Name: da0p3
   Mediasize: 1905891737600 (1.7T)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 82944
   Mode: r0w0e0
   rawuuid: d7b6a47e-8b0e-11e1-b750-f46d04227f12
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 1905891737600
   offset: 17179952128
   type: freebsd-zfs
   index: 3
   end: 3755999393
   start: 33554594
Consumers:
1. Name: da0
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Mode: r0w0e0

ZFS label:

--------------------------------------------
LABEL 0
--------------------------------------------
    version: 5000
    name: 'ztmp'
    state: 0
    txg: 0
    pool_guid: 16827460747202824739
    hostid: 740296715
    hostname: '#############'
    top_guid: 15350190479074972289
    guid: 3060075816835778669
    vdev_children: 1
    vdev_tree:
        type: 'mirror'
        id: 0
        guid: 15350190479074972289
        whole_disk: 0
        metaslab_array: 30
        metaslab_shift: 34
        ashift: 9
        asize: 1905887019008
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 3060075816835778669
            path: '/dev/gptid/d7b6a47e-8b0e-11e1-b750-f46d04227f12'
            phys_path: '/dev/gptid/d7b6a47e-8b0e-11e1-b750-f46d04227f12'
            whole_disk: 1
            DTL: 5511
            resilvering: 1
        children[1]:
            type: 'disk'
            id: 1
            guid: 3324029433529063540
            path: '/dev/gptid/396a2b11-cb16-11e1-83f4-f46d04227f12'
            phys_path: '/dev/gptid/396a2b11-cb16-11e1-83f4-f46d04227f12'
            whole_disk: 1
            DTL: 3543
            create_txg: 4
            resilvering: 1
    features_for_read:
    create_txg: 0
Uberblock[0]
    magic = 0000000000bab10c
    version = 5000
    txg = 0
    guid_sum = 1668268329223536005
    timestamp = 1361299185 UTC = Tue Feb 19 10:39:45 2013

(Other labels are exact copies)

There is a discussion of a similar-sounding problem in this old thread. I tried running Jeff Bonwick's labelfix tool (with updates from this post), but it did not seem to solve the problem.

Any ideas?

share|improve this question
    
What happened before this? –  ewwhite Mar 28 at 20:00
    
The drive was detached from the mirror, rather than being split. It appears that was the cause of the problem. The rest of the mirror does not exist, unfortunately. –  slugchewer Mar 28 at 20:03
    
I don't know that this is the proper forum for this, because the 'answer' to the question involves a lot of trial & error. For now, try 'zpool import -d </dev/path/to/disk>'. -D lists destroyed pools, -d takes an argument of the location of a disk to look at, and can be specified multiple times on the command line (but in your case, only once will be needed as you have but the one disk). See what that does. –  Nex7 Mar 28 at 20:23
    
You may be right about this not being the right forum. And yes, I've tried with the -d and -D options, to no avail. –  slugchewer Mar 28 at 20:44
    
If you tried with -d <disk dev path including partition> and it didn't show up, try everything again but on an illumos OS. If that still can't see it, I'm out of ideas. You may need to engage a data recovery expert if the data has monetary value, or start looking at the code (src.illumos.org) while on the illumos derivative and dtrace'ing the zpool import command to see what path it takes and try to figure out why it can't see your pool. –  Nex7 Mar 30 at 20:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.