Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Oct 2012 14:13:29 +0200
From:      Fabian Keil <>
To:        Stefano Rossi <>
Subject:   Re: dd zero on the wrong disk. ZFS over GELI on that disk, recover possible?
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Stefano Rossi <> wrote:

> I made a tremendous mistake with a "dd of=3D/dev/zero of=3D/dev/ada1" com=
mand. ada1 was the wrong disk.

Ooops ...

> The command was interrupted after a few seconds (I only wanted to erase t=
he partition table), and a "gpart create -s gpt ada1" was given before I re=
alized my mistake.
> On ada1 there was a single partition, type freebsd, which was labelled HD=
4. /dev/label/HD4 was geli encrypted with a keyfile (I still have the keyfi=
le), and /dev/label/HD4.eli was a zpool (named HD4 too).
> Is there any way I could save at least some of the data on that zpool? I =
know geli makes backup of the metadata, I must have them somewhere on my ro=
ot partition.
> Is there any way to recover the few lost megabytes at the start of the di=
> Or, would it be possible to recreate the same partition table with the si=
ngle partition, relabel it and restore the geli backup to the labelled part=
ition? Would then zfs recognize it?

The geli and glabel meta data is located at the end of the partition
so it shouldn't be affected by the dd if you only deleted a couple of
MBs at the beginning of the disk.

If you previously weren't using a gpt layout on ada1, however,
the gpart call might have corrupted the meta data for both in
which case you'll have to recreate it.

If the glabel meta data wasn't corrupted, the label should show up
again once you recreated the partition at the previous position.

If the label shows up, it's likely that the geli meta data isn't
affected either and you can try to geli attach the provider and
import the zpool. After a zpool scrub you'll know which files were

If the label doesn't show up after the partition table has been
corrected, you'll first have to recreate a label and "geli restore"
the meta data as documented in geli(8).

I'd recommend that you backup the whole disk and work on the backup
until you know that the recovery process works. This would allow you
to use zfs snapshots to be able to quickly rollback the backup if you
need several attempts to get the partition layout right and decreases
the chances that the damage gets worse.

Out of curiosity I just experimented with a 1 GB disk where the label
was on md0s1 which was created with "gpart add" using the whole disk
and could thus easily be recreated:

fk@r500 ~ $ls /dev/label/recovery-test=20
fk@r500 ~ $zogftw cmd zogftw_clear_device /dev/md0
2012-10-08 13:48:51 zogftw: Clearing /dev/md0. Feel free to abort this with=
^C28+0 records in
27+0 records out
28311552 bytes transferred in 3.715472 secs (7619907 bytes/sec)
fk@r500 ~ $ls /dev/label/recovery-test=20
ls: /dev/label/recovery-test: No such file or directory
fk@r500 ~ $sudo gpart create -s GPT /dev/md0
md0 created
fk@r500 ~ $sudo gpart add -t freebsd /dev/md0
md0s1 added
fk@r500 ~ $ls /dev/label/recovery-test=20
fk@r500 ~ $zogftw import
2012-10-08 13:49:57 zogftw: recovery-test's location isn't registered yet!
2012-10-08 13:49:57 zogftw: No pool name specified. Trying all unattached l=
abels: recovery-test=20
2012-10-08 13:49:57 zogftw: No geli keyfile found at /home/fk/.config/zogft=
w/geli/keyfiles/recovery-test.key. Not using any.

You need a passphrase to unlock the secret key for
user: "Fabian Keil <>"
4096-bit ELG-E key, ID 351A59E5, created 2006-08-19 (main key ID BF2EA563)

2012-10-08 13:50:04 zogftw: recovery-test attached
2012-10-08 13:50:09 zogftw: recovery-test imported
fk@r500 ~ $sudo zpool status recovery-test
  pool: recovery-test
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
  scan: none requested

	NAME                       STATE     READ WRITE CKSUM
	recovery-test              ONLINE       0     0     0
	  label/recovery-test.eli  ONLINE       0     0   116

errors: No known data errors
# Apparently a bunch of ZFS meta data was corrupted but could be
# corrected, scrub the whole pool to see what else got damaged.
fk@r500 ~ $sudo zpool scrub recovery-test
fk@r500 ~ $sudo zpool status recovery-test
  pool: recovery-test
 state: ONLINE
status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
  scan: scrub repaired 1.52M in 0h0m with 3601 errors on Mon Oct  8 13:51:2=
3 2012

	NAME                       STATE     READ WRITE CKSUM
	recovery-test              ONLINE       0     0 3.52K
	  label/recovery-test.eli  ONLINE       0     0 7.78K

errors: 3601 data errors, use '-v' for a list
fk@r500 ~ $zpool list recovery-test
recovery-test  1016M   442M   574M    43%  1.00x  ONLINE  -

Your mileage may vary ...


Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

Version: GnuPG v2.0.19 (FreeBSD)



Want to link to this message? Use this URL: <>