1 |
thank you guys, you've been helpful :) |
2 |
|
3 |
On Wed, Mar 30, 2011 at 3:31 PM, Joost Roeleveld <joost@××××××××.org> wrote: |
4 |
|
5 |
> On Wednesday 30 March 2011 07:28:40 Florian Philipp wrote: |
6 |
> > Am 30.03.2011 05:02, schrieb Einux: |
7 |
> > > Hi, |
8 |
> > > |
9 |
> > > I bought a new 1T harddrive which is exactly the same as my previous |
10 |
> > > harddrive. So I'm planning to make a Raid-1 layout(for security |
11 |
> > > reasons). But here's the problem: I've already setup LVM2 on the |
12 |
> > > existing harddrive and I don't want to destroy the existing LVM volume |
13 |
> > > groups. I tried to google it, but I'm not sure which is the right |
14 |
> > > keyword. Could you guys help me out? |
15 |
> > > |
16 |
> > > Thanks in advance:) |
17 |
> > |
18 |
> > 1. Create a degenerated RAID1 with your new disk |
19 |
> > mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb |
20 |
> > |
21 |
> > 2. Partition the raid device |
22 |
> > |
23 |
> > 3. Add one of the partitions to your LVM volume group. |
24 |
> > pvcreate /dev/sdb2 |
25 |
> > vgextend volume_group /dev/sdb2 |
26 |
> > |
27 |
> > 4. Move everything from the old physical volumes to the new pv. |
28 |
> > pvmove /dev/sda3 /dev/sdb2 |
29 |
> > |
30 |
> > 5. Remove the old and now empty physical volume |
31 |
> > vgreduce volume_group /dev/sda3 |
32 |
> > |
33 |
> > 6. Move everything else which is not on LVM to your new raid. Guess you |
34 |
> > need to go to single user mode to do this safely. |
35 |
> > |
36 |
> > 7. Grow your raid to also contain the old disk. |
37 |
> > mdadm /dev/md0 -a /dev/sda |
38 |
> > |
39 |
> > No, I have not tested this and you should double-check everything. No |
40 |
> > guarantees, etc. |
41 |
> > |
42 |
> > One warning, though: pvmove is known to create problems from time to |
43 |
> > time. Leaking memory, bogging systems with infinite system load and so |
44 |
> > on. If it gives you trouble, you can abort it with `pvmove --abort` and |
45 |
> > try it again later by calling `pvmove volume_group` (without physical |
46 |
> > device specified) to resume it. It SHOULD survive system crashes. |
47 |
> > Trying another kernel version sometimes helps when pvmove gives you |
48 |
> trouble. |
49 |
> |
50 |
> To avoid that, with "large" moves, do the following: |
51 |
> # pvmove -i 600 /dev/sda3 |
52 |
> |
53 |
> The "-i 600" means, only report every 10 minutes. It's the "reporting" that |
54 |
> causes the memory leak. |
55 |
> |
56 |
> Also, when just wanting to "empty" one physical volume, it is not necessary |
57 |
> to |
58 |
> specify the "target". |
59 |
> It's a good idea to mark the PVs on the existing drive "non-allocatable". |
60 |
> Then |
61 |
> LVM won't try to move anything to that PV: |
62 |
> # pvchange -xn /dev/sda3 |
63 |
> |
64 |
> The rest of the steps read correct. It's how I did a similar operation, but |
65 |
> still double-check all the parameters and when in doubt, read the manual |
66 |
> and/or ask on the list. |
67 |
> |
68 |
> -- |
69 |
> Joost Roeleveld |
70 |
> |
71 |
> |
72 |
> |
73 |
|
74 |
|
75 |
-- |
76 |
Best Regards, |
77 |
Einux |