[NAS4Free] Recover data from faulty RAID-Z2 pool

S

Sergius

On a VM (Proxmox, KVM) was installed NAS4Free with five disks (raw files), one for the OS, four for a RAID-Z2 pool. A few days ago the VM suddenly rebooted and enter a boot loop: each time it tries to mount the pool, it throws a fatal trap 12. Other FreeBSD-based OSes throw that trap too, though zpool import says that pool is online, but zpool import <poolname> wouldn't import the pool without the -f flag.

Code: 
nas4free: ~ # zpool import
   pool: r1
     id: 4651652232851139502
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        r1          ONLINE
          raidz2-0  ONLINE
            ada0    ONLINE
            ada1    ONLINE
            ada2    ONLINE
            ada3    ONLINE
nas4free: ~ # zpool import r1
cannot import 'r1': pool may be in use from other system
use '-f' to import anyway

And when -f is there, I got a fatal trap 12. Trying OpenIndiana, NexentaStor and Solaris 11 results in rebooted OI, but Nexenta and Solaris were able to import the pool with the -V flag. And it was inoperable. When I looked closer at the labels, I noticed that the number of the last succeeded transaction couldn't be found in uberblocks. Manually editing the txg field let FreeNAS 8.3 also import the pool, but without any other success. What else I could try to save the data?
 
Re: Recover data from falted raidz2 pool

You're trying to import a pool that's already there. Why did you choose RAID-Z2 with only four drives instead of mirroring?
 
Re: Recover data from falted raidz2 pool

No, the pool isn't there:
Code: 
nas4free: ~ # zpool import
   pool: r1
     id: 4651652232851139502
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        r1          ONLINE
          raidz2-0  ONLINE
            ada0    ONLINE
            ada1    ONLINE
            ada2    ONLINE
            ada3    ONLINE
nas4free: ~ # zpool import r1
cannot import 'r1': pool may be in use from other system
use '-f' to import anyway
nas4free: ~ # zpool status
no pools available
nas4free: ~ #

It was my first experience with ZFS, so I chose RAID-Z2 out of wonder (oh, it must be cool, I thought). I have a few backups, but not very fresh.
 
See the zpool() man page for details on the -F option. If there are issues with the last few transactions preventing an import, that might let you discard them and get the pool to an importable state.
 
No. I tried -F in various combinations, but with no result.


Code: 
zdb -lu on one of the disks
--------------------------------------------
LABEL 0
--------------------------------------------
    version: 28
    name: 'r1'
    state: 0
    txg: 4273868
    pool_guid: 4651652232851139502
    hostname: ''
    top_guid: 5698945487837190948
    guid: 5103665716231737406
    vdev_children: 1
    vdev_tree:
        type: 'raidz'
        id: 0
        guid: 5698945487837190948
        nparity: 2
        metaslab_array: 30
        metaslab_shift: 33
        ashift: 9
        asize: 1717968044032
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 5103665716231737406
            path: '/dev/vtbd1'
            phys_path: '/dev/vtbd1'
            whole_disk: 1
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 2955603279638369563
            path: '/dev/vtbd2'
            phys_path: '/dev/vtbd2'
            whole_disk: 1
            create_txg: 4
        children[2]:
            type: 'disk'
            id: 2
            guid: 10457907822566881951
            path: '/dev/vtbd3'
            phys_path: '/dev/vtbd3'
            whole_disk: 1
            create_txg: 4
        children[3]:
            type: 'disk'
            id: 3
            guid: 12784877634711548437
            path: '/dev/vtbd4'
            phys_path: '/dev/vtbd4'
            whole_disk: 1
            create_txg: 4
Uberblock[0]
        magic = 0000000000bab10c
        version = 28
        txg = 4401792
        guid_sum = 4759164026417764575
        timestamp = 1386233364 UTC = Thu Dec  5 14:49:24 2013

If I understand correctly, with -F specified, zpool import rollback to transaction meant in some of uberblocks, but since there only 128 of them... Look at txg values.
 
You must log in or register to reply here.
Back
Top