[gentoo-amd64] Re: Cloning a system drive

[Duncan]

"Mark Knecht" <markknecht@×××××.com> posted
5bdc1c8b0710051358g74f95702rb82a29219d890919@××××××××××.com, excerpted
below, on  Fri, 05 Oct 2007 13:58:18 -0700:

>    My system drive is making some naughty sounding noises to I'm
> thinking I'd better do something fairly quickly. I'm wondering what the
> best solution for this problem is?
>
>    I'm really looking for an almost 1 step fix if possible. If I could
> get a new drive, put it in the box, and then clone to that drive
> directly that would be great.
>
>    The system has both Win XP and Gentoo AMD64. The disk layout is
> shown below. I beleive the way I shoehorned XP into this machine was to
> steal the original boot partition as a small C: drive and then the buld
> of Windows is on a larger partition at the end of the drive.

I've migrated hard drives under old-one-dieing conditions a couple times 
in the last few years.  Fortunately, the old one has always been still 
usable, but that's why I went with RAID this time.

What I do is take the opportunity to redesign my partition layouts and 
the like (altho this time I have most stuff on LVM, which should help 
next time).  The disk is always larger, and sometimes I've switched 
distributions or something, so need to optimize my layout.  Thus, the 
first step is simply deciding how I want my partitions split up and what 
size each will be, then choosing the order I want to lay them out.  (This 
time, the first with RAID and LVM, I had that to think about too, 
partitions on the physical disks for the various RAID levels I wanted to 
run, then the RAID, choosing partitioned or not as appropriate, then the 
filesystem directly on RAID for the boot, system, and sysbackup volumes, 
LVM on RAID, and filesystems on LVM, for user and operational data.)

After setting up the partitions, the hard part, it's simply creating the 
filesystems and copying stuff over after that.  As for many of my 
sysadmin type tasks, I use mc, aka midnight commander, for the copying.  
Its defaults preserve ownership/permissions/etc and "just work" when 
exotic stuff like symlinks, sockets and device nodes are encountered, so 
no worrying about getting everything right.  The exception is stopping at 
the filesystem boundary if appropriate, but a well chosen mount layout 
minimizing recursive mounts on mounts minimizes that issue, and for 
filesystems such as root, there's mount-bind.  (I actually have a 
rootbind mountpoint and an entry in fstab for it, so all I have to do is 
mount that entry, and copy from it instead of from / itself, to eliminate 
worries of copying more than the root filesystem.)

IOW, the hard part is simply deciding on the new layout I want and doing 
the partitioning (and raid creation) as appropriate.  After that, as with 
the backup discussion recently, I simply copy the data from one place to 
the other, as I would do any other routine copying, so after the 
partitioning and etc. setup, it's pretty much just a routine backup copy 
operation from my perspective.  If there are locking issues, I've never 
seen them, so it seems they only apply to databases and the like.  Of 
course, I'm not trying to copy partitions whilst simultaneously copying 
CD/DVD sized images around on the partition I'm copying, either, but that 
would just be stupid.

I've actually done this for years, so it works.  As I mentioned in 
passing above and have noted before, I had two drives go out at almost 
exactly the 1-year mark (the last one due to overheating due to a failed 
AC), the reason I went with RAID this time.  The RAID has been up and 
running almost two years now, however, and I recently decided to update 
my backups then boot to them and delete and recreate my normally working 
copies, thus effectively "defragging", as I imagine the constant 
upgrading especially the system/root filesystem had well fragmented 
things and I had been routinely replacing the backup images but working 
from the same working copy main image, without defragging or anything.  I 
think I noticed a good increase in system responsiveness, but I didn't do 
any benchmarks or whatever to test, so it could be placebo effect.  Of 
course, the transfer to backup and then rewriting my main/working copies 
went without a hitch as it has always gone, but the point is that both 
the backup and the working copies have been redone "fresh" fairly 
recently and I'm up and running on them without issue, so the procedure 
simply works, and works well.

BTW, for trying to recover data on partially bad drives as I did twice in 
the last five years, dd-rescue works well.  It does direct block by block 
copies just as regular dd does, but it's optimized for bad disk recovery, 
such that when it hits several unreadable blocks in a row, it starts from 
the other end of the image and works backward.  When it hits several in a 
row from that end, it tries to find good spots in the middle between the 
two bad spots, and expands the recovered blocks from there if it finds 
any it can read.  Thus, since the bad-block retries are what takes 
forever in recovery situations, dd-rescue recovers much more data far 
faster than normal dd would, since dd would hit the bad spot and continue 
to try reading block after block in order, with the user likely giving up 
after a few hours or a day or two, possibly before dd reads thru the bad 
spot to the still good data on the other side.  Unlike dd, once dd-rescue 
has been running on an image for a number of hours with only incremental 
progress, the user can be reasonably sure it has recovered pretty much 
all the data that's going to be recovered, so can cancel the operation 
without much fear of leaving still recoverable data on the disk.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list