sweetcheeks said:
I have a Dell 8300 Dimension running Win XP Pro on a 250 GB SATA HD. The HD
is failing. I have a 500 GB SATA HD I have been using as a backup drive. I
would like to use the 500 as my main drive now. What are the steps required
to do this? There is no operating system on the 500.
Since you're about to use your backup drive, as your primary drive,
now you're "short a drive". You should buy yet another hard drive.
You don't want to be caught without a backup! Bad things can
happen, no matter how careful you are. Say you move from
a--> b, and "b" is a bad copy and "a" breaks a few minutes
later. Now, you have no copy of data to work with.
Make sure you have at least one backup to fall back on.
One way to move all the stuff, is to use the utility the
disk manufacturer provides on their web site. Seagate
provides a utility, while I think Hitachi does not.
Check the disk manufacturer web sites for details.
Discwizard manual
http://www.seagate.com/support/discwizard/dw_ug.en.pdf
Download page
http://www.seagate.com/ww/v/index.j...toid=d9fd4a3cdde5c010VgnVCM100000dd04090aRCRD
*******
I changed my C: drive, just this week. I bought a couple
160GB disks. I changed from an existing noisy 80GB drive,
to a 160GB drive. I used my Linux LiveCD (Knoppix), to
boot the computer, in place of using WinXP. I used the
"dd" or disk dump command, which copies every sector from
one drive to the other. It doesn't matter how many partitions
are on the disk, or their file system type, it just copies
all the sectors. The syntax looks like this. You
have to examine /etc/fstab, to get some idea of what
the drive names are.
dd if=/dev/hda of=/dev/hdb
What that does, is transfers the raw device "hda" in Linux,
to the raw device "hdb". The command runs until it hits the
end of hda, so using the syntax above, hdb has to be the
same size or bigger than hda, in order for the command to
finish and have copied all the data. My transfer rate was
roughly 19MB/sec. To transfer a 250GB disk, would take
250000/19 seconds or about 3.6 hours. Using Discwizard
could be faster than that (because Discwizard won't be
copying the parts of the disk that are blank).
If you check the actual size of the disk, the disk size is
the product of a number of prime numbers. In Linux, I
can use a command like disk_stat, to get a measure of the
number of sectors
156301488
Since each sector is 512 bytes or 0.5KB, if you multiply
that number by 0.5, you get 78,150,744 or close to 80GB.
If I use the Linux "factor" program, it tries dividing numbers
into that number. It prints all the factors on one line of
output. That number is equivalent to
2*2*2*2*3*3*3*3*3*7*5743 = 156301488
Written another way, that is 27216 * 5743.
I can rewrite the "dd" command now. (I actually stopped the
command the first time I was running it, to use a syntax
that would double the copy speed.) Since 27216 is a number
of sectors, I multiply by 512 bytes/sector, to get a count of
bytes. That means my disk is
(27216*512) * 5743 bytes
The reason I want to break the disk down into exact pieces,
is so the disk can be copied a block at a time. The
new dd command to copy my 80GB drive becomes
dd if=/dev/hda of=/dev/hdb bs=13934592 count=5743
Since I've done the math, I know that copies the entire disk.
That means the disk is broken down into 5743 equal pieces,
each 13934592 bytes in size. Or, if the command didn't
like the syntax, I could bump the first number down by a
factor of 2, and the second one up by a factor of 2. It
all depends on the largest bs (block size) the command
happens to support. I didn't check what that is.
dd if=/dev/hda of=/dev/hdb bs=6967296 count=11486
If you don't like that geeky stuff, then use the Seagate
tool. It is actually a piece of software written by
Acronis. Acronis makes tools that can move data from one
disk to another. And without all the arithmetic I used.
Another small note. When you copy the disk
a--> b
After the copy is complete, disconnect the "a" drive
from the computer, before you boot the "b" drive for
the first time. That prevents Windows from becoming
confused. Once "b" has booted by itself at least
once, then it is safe to reconnect the "a" drive
again if you want. You don't want the "a" drive
connected, when "b" boots for the first time. I don't
know all the technical details, as to why it screws up,
but I've had to "reclone" a disk before, because I forgot
to disconnect the source disk before booting the
destination disk. Perhaps someone else here can
explain what goes on there.
I expect you would enjoy the Acronis tool, a lot
more than using "dd"
Good luck,
Paul
