1 |
"Mark Knecht" <markknecht@×××××.com> posted |
2 |
5bdc1c8b0710051358g74f95702rb82a29219d890919@××××××××××.com, excerpted |
3 |
below, on Fri, 05 Oct 2007 13:58:18 -0700: |
4 |
|
5 |
> My system drive is making some naughty sounding noises to I'm |
6 |
> thinking I'd better do something fairly quickly. I'm wondering what the |
7 |
> best solution for this problem is? |
8 |
> |
9 |
> I'm really looking for an almost 1 step fix if possible. If I could |
10 |
> get a new drive, put it in the box, and then clone to that drive |
11 |
> directly that would be great. |
12 |
> |
13 |
> The system has both Win XP and Gentoo AMD64. The disk layout is |
14 |
> shown below. I beleive the way I shoehorned XP into this machine was to |
15 |
> steal the original boot partition as a small C: drive and then the buld |
16 |
> of Windows is on a larger partition at the end of the drive. |
17 |
|
18 |
I've migrated hard drives under old-one-dieing conditions a couple times |
19 |
in the last few years. Fortunately, the old one has always been still |
20 |
usable, but that's why I went with RAID this time. |
21 |
|
22 |
What I do is take the opportunity to redesign my partition layouts and |
23 |
the like (altho this time I have most stuff on LVM, which should help |
24 |
next time). The disk is always larger, and sometimes I've switched |
25 |
distributions or something, so need to optimize my layout. Thus, the |
26 |
first step is simply deciding how I want my partitions split up and what |
27 |
size each will be, then choosing the order I want to lay them out. (This |
28 |
time, the first with RAID and LVM, I had that to think about too, |
29 |
partitions on the physical disks for the various RAID levels I wanted to |
30 |
run, then the RAID, choosing partitioned or not as appropriate, then the |
31 |
filesystem directly on RAID for the boot, system, and sysbackup volumes, |
32 |
LVM on RAID, and filesystems on LVM, for user and operational data.) |
33 |
|
34 |
After setting up the partitions, the hard part, it's simply creating the |
35 |
filesystems and copying stuff over after that. As for many of my |
36 |
sysadmin type tasks, I use mc, aka midnight commander, for the copying. |
37 |
Its defaults preserve ownership/permissions/etc and "just work" when |
38 |
exotic stuff like symlinks, sockets and device nodes are encountered, so |
39 |
no worrying about getting everything right. The exception is stopping at |
40 |
the filesystem boundary if appropriate, but a well chosen mount layout |
41 |
minimizing recursive mounts on mounts minimizes that issue, and for |
42 |
filesystems such as root, there's mount-bind. (I actually have a |
43 |
rootbind mountpoint and an entry in fstab for it, so all I have to do is |
44 |
mount that entry, and copy from it instead of from / itself, to eliminate |
45 |
worries of copying more than the root filesystem.) |
46 |
|
47 |
IOW, the hard part is simply deciding on the new layout I want and doing |
48 |
the partitioning (and raid creation) as appropriate. After that, as with |
49 |
the backup discussion recently, I simply copy the data from one place to |
50 |
the other, as I would do any other routine copying, so after the |
51 |
partitioning and etc. setup, it's pretty much just a routine backup copy |
52 |
operation from my perspective. If there are locking issues, I've never |
53 |
seen them, so it seems they only apply to databases and the like. Of |
54 |
course, I'm not trying to copy partitions whilst simultaneously copying |
55 |
CD/DVD sized images around on the partition I'm copying, either, but that |
56 |
would just be stupid. |
57 |
|
58 |
I've actually done this for years, so it works. As I mentioned in |
59 |
passing above and have noted before, I had two drives go out at almost |
60 |
exactly the 1-year mark (the last one due to overheating due to a failed |
61 |
AC), the reason I went with RAID this time. The RAID has been up and |
62 |
running almost two years now, however, and I recently decided to update |
63 |
my backups then boot to them and delete and recreate my normally working |
64 |
copies, thus effectively "defragging", as I imagine the constant |
65 |
upgrading especially the system/root filesystem had well fragmented |
66 |
things and I had been routinely replacing the backup images but working |
67 |
from the same working copy main image, without defragging or anything. I |
68 |
think I noticed a good increase in system responsiveness, but I didn't do |
69 |
any benchmarks or whatever to test, so it could be placebo effect. Of |
70 |
course, the transfer to backup and then rewriting my main/working copies |
71 |
went without a hitch as it has always gone, but the point is that both |
72 |
the backup and the working copies have been redone "fresh" fairly |
73 |
recently and I'm up and running on them without issue, so the procedure |
74 |
simply works, and works well. |
75 |
|
76 |
BTW, for trying to recover data on partially bad drives as I did twice in |
77 |
the last five years, dd-rescue works well. It does direct block by block |
78 |
copies just as regular dd does, but it's optimized for bad disk recovery, |
79 |
such that when it hits several unreadable blocks in a row, it starts from |
80 |
the other end of the image and works backward. When it hits several in a |
81 |
row from that end, it tries to find good spots in the middle between the |
82 |
two bad spots, and expands the recovered blocks from there if it finds |
83 |
any it can read. Thus, since the bad-block retries are what takes |
84 |
forever in recovery situations, dd-rescue recovers much more data far |
85 |
faster than normal dd would, since dd would hit the bad spot and continue |
86 |
to try reading block after block in order, with the user likely giving up |
87 |
after a few hours or a day or two, possibly before dd reads thru the bad |
88 |
spot to the still good data on the other side. Unlike dd, once dd-rescue |
89 |
has been running on an image for a number of hours with only incremental |
90 |
progress, the user can be reasonably sure it has recovered pretty much |
91 |
all the data that's going to be recovered, so can cancel the operation |
92 |
without much fear of leaving still recoverable data on the disk. |
93 |
|
94 |
-- |
95 |
Duncan - List replies preferred. No HTML msgs. |
96 |
"Every nonfree program has a lord, a master -- |
97 |
and if you use the program, he is your master." Richard Stallman |
98 |
|
99 |
-- |
100 |
gentoo-amd64@g.o mailing list |