Rollback Extend Disk

[SuperSavio]

so I have no hope of recovering the data from the first hd, even if I connect it to another computer (windows / linux / osx)?

 

[jgreco]

so I have no hope of recovering the data from the first hd, even if I connect it to another computer (windows / linux / osx)?

I wouldn't say NO hope.

But just to give you a more graphic picture, let's imagine that you had a fresh hard drive formatted with NTFS. You stored data so that it was only on one side of all the platters. Then you take a tablesaw and cut through the drive, carefully keeping that side of the platters intact.

It doesn't really matter that the half you cut off contained no appreciable data. A hard drive isn't designed to work if cut in half, even though all the data may be there and be intact.

You have done this to your pool, and it is somewhat difficult to recover from.

 

[danb35]

@sretalla's already mentioned the -F flag, but I don't see that he gave the exact command to try. See if zpool import -F Media_4TB lets it import the pool. Otherwise, I don't see a way to get the pool back online.

 

[SuperSavio]

@sretalla ha già menzionato il flag -F, ma non vedo che abbia dato il comando esatto per provare. Verifica se zpool import -F Media_4TB consente di importare il pool. Altrimenti, non vedo un modo per riportare la piscina online.

Nothing, running the command I have this output

Code:

root@freenas[~]# zpool import -F Media_4TB
cannot import 'Media_4TB': no such pool or dataset
    Destroy and re-create the pool from
    a backup source.

 

[jgreco]

Well, that's pretty bad.

Does

# zdb -hhe Media_4TB

report anything (maybe without the -e flag)?

 

[SuperSavio]

zdb -hhe Media_4TB

Code:

zdb: can't open 'Media_4TB': No such file or directory

zdb -e Media_4TB

Code:

Configuration for import:
        vdev_children: 2
        version: 5000
        pool_guid: 537171516661595357
        name: 'Media_4TB'
        state: 0
        hostid: 3858239460
        hostname: 'freenas.local'
        vdev_tree:
            type: 'root'
            id: 0
            guid: 537171516661595357
            children[0]:
                type: 'disk'
                id: 0
                guid: 18048118569942016813
                metaslab_array: 38
                metaslab_shift: 35
                ashift: 12
                asize: 3998634737664
                is_log: 0
                DTL: 179
                create_txg: 4
                path: '/dev/gptid/3525b579-3c08-11eb-95a5-a0b3cce3fb7a'
            children[1]:
                type: 'missing'
                id: 1
                guid: 0
zdb: can't open 'Media_4TB': No such file or directory

ZFS_DBGMSG(zdb):
spa_import: importing Media_4TB
spa_load(Media_4TB, config trusted): LOADING
disk vdev '/dev/gptid/3525b579-3c08-11eb-95a5-a0b3cce3fb7a': best uberblock found for spa Media_4TB. txg 7137201
spa_load(Media_4TB, config untrusted): using uberblock with txg=7137201
spa_load(Media_4TB, config trusted): vdev tree has 1 missing top-level vdevs.
spa_load(Media_4TB, config trusted): current settings allow for maximum 0 missing top-level vdevs at this stage.
spa_load(Media_4TB, config trusted): FAILED: unable to open vdev tree [error=2]
  vdev 0: root, guid: 537171516661595357, path: N/A, can't open
    vdev 0: disk, guid: 18048118569942016813, path: /dev/gptid/3525b579-3c08-11eb-95a5-a0b3cce3fb7a, healthy
    vdev 1: disk, guid: 13924785740365534829, path: /dev/gptid/7c23f04f-86cd-11ec-8262-a0b3cce3fb7a, can't open
spa_load(Media_4TB, config trusted): UNLOADING

 

[jgreco]

Well, if we can get a list of valid transactions, you can try recovery.

Normally you'd want to set a loader tunable of vfs.zfs.recover=1, then find the highest numbered transaction, then try something like

# zpool import -N -o readonly=on -f -R /mnt/Media_4TB -F -T <transaction#> Media_4TB

But I'm not sure what zdb incantations will work at this level of damage.