dd zero on the wrong disk. ZFS over GELI on that disk, recover possible?

[Fabian Keil]

Stefano Rossi <stefa.rossi96 at gmail.com> wrote:

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

Ooops ...

> The command was interrupted after a few seconds (I only wanted to erase the partition table), and a "gpart create -s gpt ada1" was given before I realized my mistake.
> On ada1 there was a single partition, type freebsd, which was labelled HD4. /dev/label/HD4 was geli encrypted with a keyfile (I still have the keyfile), 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 root partition.
> 
> Is there any way to recover the few lost megabytes at the start of the disk?
> Or, would it be possible to recreate the same partition table with the single partition, relabel it and restore the geli backup to the labelled partition? 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
damaged.

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 at r500 ~ $ls /dev/label/recovery-test 
/dev/label/recovery-test
fk at r500 ~ $zogftw cmd zogftw_clear_device /dev/md0
2012-10-08 13:48:51 zogftw: Clearing /dev/md0. Feel free to abort this with ctrl-C
^C28+0 records in
27+0 records out
28311552 bytes transferred in 3.715472 secs (7619907 bytes/sec)
fk at r500 ~ $ls /dev/label/recovery-test 
ls: /dev/label/recovery-test: No such file or directory
fk at r500 ~ $sudo gpart create -s GPT /dev/md0
md0 created
fk at r500 ~ $sudo gpart add -t freebsd /dev/md0
md0s1 added
fk at r500 ~ $ls /dev/label/recovery-test 
/dev/label/recovery-test
fk at 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 labels: recovery-test 
2012-10-08 13:49:57 zogftw: No geli keyfile found at /home/fk/.config/zogftw/geli/keyfiles/recovery-test.key. Not using any.

You need a passphrase to unlock the secret key for
user: "Fabian Keil <fk at fabiankeil.de>"
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 at 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'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: none requested
config:

	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 at r500 ~ $sudo zpool scrub recovery-test
fk at 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.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 1.52M in 0h0m with 3601 errors on Mon Oct  8 13:51:23 2012
config:

	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 at r500 ~ $zpool list recovery-test
NAME            SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
recovery-test  1016M   442M   574M    43%  1.00x  ONLINE  -

Your mileage may vary ...

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20121008/9e9fbdfd/signature.pgp