From: Kai Iskratsch <kai@stella.at>
To: linux-lvm@sistina.com
Subject: [linux-lvm] trying to restore data after Harddisk breakdown
Date: Sun Apr 27 04:59:02 2003 [thread overview]
Message-ID: <3EABA9DC.2050507@stella.at> (raw)
I had a lvm System which was made of 3 PVs the Harddisks hde (30 GB),hdf
(80 GB) and hdg (120 GB). The first harddisk on which I created the vg
was hdf, then I created 3 LVs on it. Moved the existing data from hde
the VG, added hde as a PV and expanded one of the LVs. After some
months I added hdg and resized all LVs. Some time later I moved a bit of
free Space between the LVs but forgot to backup my configuration.
Not very much longer one of the harddisks hde had a complete breakdown,
it couldn't be found by the bios anymore. Since I still had waranty on
it I sent it in and got some time later a replacement disk.
In the meantime I was able to extract the data from the 2 LVs which
didnt span on the defect disk by using LVM2 and using
""vgscan ; vgchange -a y -P"".
Im Using now kernel 2.4.20 and device-mapper + lvm checked out from cvs
yesterday night.
(Compilation was not that easy, i had to make some changes for
device-mapper
lib/ioctl/libdevmapper.c,v
479c479
< char *outbuf = (char *) dmi + dmi->data_offset;
---
> char *outbuf = (char *) dmi + dmi->data_start;
536c536
< dmt->dmi.v3->data_offset);
---
> dmt->dmi.v3->data_start);
671c671
< dmi->data_offset = sizeof(struct dm_ioctl);
---
> dmi->data_start = sizeof(struct dm_ioctl);
which i hope is correct since the struct dm_ioctrl had no member
data_offst and reading the comments for this struct suggested that
data_start should be an offset
and in lvm2 I needed to include the kernel Include files into the
INCLUDE part of the MAKEFILE)
Now I have the replacement disk which should be only one large segment
in one of the LVs. So I thought that it could maybe possible to get the
lvm up again by exracting the actual configuration that is used by
"vgscan ; vgchange -a y -P" and making a vgcfgbackup of it with lvm2 and
edit the backup since it is humanreadable and restore it to the new
harddisk.
so I tried to make a vgcfgbackup which worked with the -P option
and got somthing which seemed a bit irritating for me:
--------------------------------------------------------
# Generated by LVM2: Sun Apr 27 09:26:39 2003
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing './vgcfgbackup -P'"
creation_host = "fuckup" # Linux fuckup 2.4.20 #1 SMP Sun Apr 27
00:32:28 CEST 2003 i686
creation_time = 1051428399 # Sun Apr 27 09:26:39 2003
Data {
id = "PUHFUx-71YI-m24t-7aZQ-J9ZM-PSrD-F10Y3t"
seqno = 0
status = ["RESIZEABLE", "PARTIAL", "READ"]
system_id = "matin1023540844"
extent_size = 8192 # 4 Megabytes
max_lv = 255
max_pv = 255
physical_volumes {
pv0 {
id = "3yHeIp-kPYG-dqYk-3Qvz-czTC-m05v-Hs44sq"
device = "/dev/hdg1" # Hint only
status = ["ALLOCATABLE"]
pe_start = 8696
pe_count = 29310 # 114.492 Gigabytes
}
pv1 {
id = "834fZw-DSuv-0gGa-2313-Ud40-uqyh-mh3zbW"
device = "/dev/hdf1" # Hint only
status = ["ALLOCATABLE"]
pe_start = 8696
pe_count = 19078 # 74.5234 Gigabytes
}
}
logical_volumes {
MP3 {
id = "000000-0000-0000-0000-0000-0000-000000"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "next free"
read_ahead = 120
segment_count = 1
segment1 {
start_extent = 0
extent_count = 12800 # 50 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
DATA {
id = "000000-0000-0000-0000-0000-0000-000001"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "next free"
read_ahead = 120
segment_count = 1
segment1 {
start_extent = 0
extent_count = 5120 # 20 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 15360
]
}
}
VIDEO {
id = "000000-0000-0000-0000-0000-0000-000002"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "next free"
read_ahead = 120
segment_count = 7328
segment1 {
start_extent = 0
extent_count = 8830 # 34.4922 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 20480
]
}
segment2 {
start_extent = 8830
extent_count = 1 # 4 Megabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"Missing", 0
]
}
.... (many more Missing Segments)
segment7326 {
start_extent = 16154
extent_count = 1 # 4 Megabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"Missing", 0
]
}
segment7327 {
start_extent = 16155
extent_count = 19078 # 74.5234 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv1", 0
]
}
segment7328 {
start_extent = 35233
extent_count = 2560 # 10 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 12800
]
}
}
}
}
-----------------------------------------------
first this says that the 120GB disk is my PV0 and the 80 GB is my PV1,
second it says that my 2 working LVs are entirely on the 120 GB
Harddisk, but I created them before on the 80 GB Disk so I thought they
would be spanning over both discs.
Is this backup wrong, then how do I get the data that the system uses
when I mount the two working LVs readonly?
Or has lvm moved the LVs on one of my resizes so that this data is
correct and I only need to add the new PV and replace all the Missing
Segments by one on the new PV?
best regards
Kai Iskratsch
next reply other threads:[~2003-04-27 4:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-27 4:59 Kai Iskratsch [this message]
2003-04-27 9:26 ` [linux-lvm] trying to restore data after Harddisk breakdown Alasdair G Kergon
2003-04-28 15:26 ` Kai Iskratsch
2003-04-28 15:38 ` Alasdair G Kergon
2003-04-28 15:58 ` Kai Iskratsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EABA9DC.2050507@stella.at \
--to=kai@stella.at \
--cc=linux-lvm@sistina.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.