Re: recommendations on how to recover a corrupted, LVM-based hard drive?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 15 Feb 2014, Robert Nichols wrote:

> On 02/14/2014 08:52 AM, Robert P. J. Day wrote:
> >    so ... what now? i can see the detailed definition of the
> > volume group, and all of the logical volumes that were/are(?)
> > still there, and the only LV i care about is "home" which is the
> > fifth one down in the list of LVs, suggesting it's far enough down
> > to have escaped the overwriting unscathed.
> >
> >    so what would be the proper recipe to simply reactivate that
> > volume group and single logical volume within that group? thanks.
>
> You need to figure out just where that PV partition was located on
> the disk.
>
> In the physical_volumes section, look at the dev_size. How might
> that have been placed on the disk? It was very likely a partition
> that went to the end of the disk -- perhaps not the very end but
> just the last full "cylinder" (at the most common geometry of 255
> heads and 63 sectors per track). From that, calculate the starting
> location for the partition. Keep playing until you get something
> "reasonable", i.e., either a cylinder boundary or a megabyte
> boundary (LBA a multiple of 8).

  i would think it would be simpler than that -- here's the top part
of the backup file:

===== start =====
... snip ...
description = "Created *after* executing '/usr/sbin/pvscan --cache --activate ay /dev/block/8:21'"

creation_host = "localhost.localdomain"	# Linux localhost.localdomain 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64
creation_time = 1388764989	# Fri Jan  3 11:03:09 2014

vg1 {
	id = "T8PpR6-Dh0C-3rpj-HRkh-6T9E-0r3f-YNZjVL"
	seqno = 7
	format = "lvm2" # informational
	status = ["RESIZEABLE", "READ", "WRITE"]
	flags = []
	extent_size = 8192		# 4 Megabytes
	max_lv = 0
	max_pv = 0
	metadata_copies = 0

	physical_volumes {

		pv0 {
			id = "Yc26dN-mfSd-sGGf-Q9KU-OutY-sJgM-4P74WB"
			device = "/dev/sdb5"	# Hint only

			status = ["ALLOCATABLE"]
			flags = []
			dev_size = 1400690688	# 667.901 Gigabytes
			pe_start = 384
			pe_count = 170982	# 667.898 Gigabytes
		}
	}
===== snip rest of file =====

  because this disk represented pretty much a default fedora
installation, i'm assuming that there is a first primary /boot
partition, and the remainder of the 750G drive after that was
formatted as a single physical volume (pv0), which was then assigned
to the single volume group (vg1), which was then broken up into
multiple LVs.

  and from the above snippet, it would seem that physical volume pv0
started at pe_start * (4M) extent_size, or 384 * 4 = 1536M. would the
math really be that straightforward? is the above telling me that the
single PV on that drive used to start at, effectively, 1.5G?

  the only other thing i'll mention at this point is that, given that
the first 2G of the drive was overwritten, as long as the math above
is correct, then the first .5G of the PV "pv0" was also trashed, but
from the list of LVs inside the VG, the only LV i care about would
appear to be several gigabytes into the PV, so it should be undamaged.

  at this point, before i go any further, if my math is correct, is
there some command that can be used to ask, "if i *tell* you that a PV
started at this offset, and the first part of it is trashed, can you
tell me what you can find in the *rest* of the PV if it should contain
valid LVs further down"?

  note: remember that the MBR was trashed as well -- it contains info
about an alleged 2G bootable image. if i *know* the offset of the
(damaged) physical volume, i guess i can always go into fdisk and
simply adjust the MBR to define a "Linux LVM" partition at precisely
that offset so i have at least a special device file that now
(theoretically) corresponds to the original PV. does that make sense?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux