Date: Mon, 8 Oct 2012 14:13:29 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Stefano Rossi <stefa.rossi96@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: dd zero on the wrong disk. ZFS over GELI on that disk, recover possible? Message-ID: <20121008141329.45b6396b@fabiankeil.de> In-Reply-To: <5DF28740-BBF5-47EE-827B-DD712ABD0F62@gmail.com> References: <5DF28740-BBF5-47EE-827B-DD712ABD0F62@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/xO72qM87_WPjZJwSoriJYxk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Stefano Rossi <stefa.rossi96@gmail.com> 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). >=20 > 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. >=20 > Is there any way to recover the few lost megabytes at the start of the di= sk? > 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 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@r500 ~ $ls /dev/label/recovery-test=20 /dev/label/recovery-test 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= ctrl-C ^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 /dev/label/recovery-test 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 <fk@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@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@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. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 1.52M in 0h0m with 3601 errors on Mon Oct 8 13:51:2= 3 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@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 --Sig_/xO72qM87_WPjZJwSoriJYxk Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlByw2sACgkQBYqIVf93VJ24FgCgyhKVSRUxUGkaAid1bq5HoO8M KkcAnj9NGw6+00b61MCXWxgJDwN+FfUP =rUoJ -----END PGP SIGNATURE----- --Sig_/xO72qM87_WPjZJwSoriJYxk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121008141329.45b6396b>