tb said:
Not sure if this is the appropriate forum. If not, please suggest an
alternative.
I just purchased a Seagate ST320005EXA101-RK which is a 2 TB external
hard drive.
I am getting ready to install Windows 7 to a desktop PC that currently
has Windows XP on it. As a precaution, I would like to clone the
internal hard drive of the PC to the Seagate external hard drive using a
program called Clonezilla. With the term "cloning" I mean copying all
the sectors of my internal hard drive, including the unused sectors and
the MBR, to the Seagate external drive. This way, should the
installation of Windows 7 fail for some reason, I can restore the
internal hard drive using the backup. My internal hard drive is 80 GB,
so there should be no problem cloning it to the Seagate external drive.
What I do not understand is whether I need to partition the Seagate
external drive before starting the cloning procedure. It is my
understanding that the process of cloning will destroy everything that
is on the external hard drive. Through Windows Explorer I can see that
there are some files and directories on the Seagate external hard drive.
They must have been placed there by the Seagate factory and I think
that it would be better not to overwrite that stuff. So I was thinking
about creating two partitions on the Seagate external drive: One
partition would harbor the files and folders that came with the Seagate
drive and a second partition that I would use to do the cloning of my
internal hard drive.
What do you guys think?
To start with, you're "protecting' the contents of an 80GB drive,
using a 2000GB drive to provide storage space.
If you wanted to provide instant access to the 80GB drive contents,
just copying the files, in a file by file way, would solve the problem.
But I expect, the info is arranged in partitions for a reason,
so the data can be dealt with at the partition level if need be.
Say your 80 GB was using four 20GB primary partitions. If we
cloned, that might look like this. Cloning makes the second
larger drive, look like the first, except there is a large
unallocated space at the end.
20GB 20GB 20GB 20GB <------- unallocated 1920GB ---------->
If you just cloned the drive, the remaining space would go unused.
You could "stretch" one of the partitions, to make use of the
unallocated space. Or, since drives support 3 primary and a
large number of "logical unbootable" partitions, we could hold
a lot more total partitions than that. A partition manager, could
help you convert the space, such that you had three 20GB primary
partitions, an extended partition chopped up into many logical spaces,
one of which was 20GB to hold the last partition.
Primary partitions are a precious resource, from a multiboot perspective.
At least, (easy) setup of multiple OSes, would use a primary partition
for booting each OS (or starting a boot process).
But there is another way to look at this. At the sector level.
For example
dd input=80GB_drive output=large_80GB_file_image_of_big_drive.dd
I could, for example, chop the large drive into two 1000GB NTFS
partitions. And store the entire 80GB drive, as a single "file" within
one of the partitions. The file would constitute a "backup image"
taking a snapshot of each sector.
<---------- 1000GB NTFS partition -----><----- 1000GB NTFS partition---->
80GB.dd file + (920GB free) (1000GB free)
That would deposit an 80GB single file, on the 2000GB hard drive, on
a partition which supports large files. FAT32 partitions, have a max
file size of 4GB, so trying to write an 80GB file on a FAT32
partition would fail. NTFS partitions, could store an entire 80GB file,
without breaking a sweat (some of the Linux EXT2/EXT3/EXT4 family
could do a similar thing, so more file systems than just NTFS can do that).
By dumping all of the sectors of the small disk, as a file on the
large disk, I can take a "snapshot" suited for emergencies. Then,
if my Windows 7 installation goes horribly wrong, simply reversing
the command
dd input=large_80GB_file_image_of_big_drive.dd output=80GB_drive
puts everything back, including the MBR which is sector zero. There
would be no evidence then, that anything had changed. Any damage done
by the Windows 7 installation, would be repaired.
That is a "very blunt tool", in the sense that it puts everything
back, but gives no options for putting back a single file. If
I needed access to my laundry_list.txt file that was stored in
one of the 20GB partitions, I would have a hard time extracting
just that one file from the 80GB "image". It isn't intended for
easy access to files (although there are ways to do it, such as
loopback mounts or the like).
To do that kind of operation, properly and neatly, you need a
"maintenance OS". I use a Linux LiveCD, like Ubuntu. The command
syntax for the Ubuntu version of "dd" would be slightly different
than the syntax if you use a Windows port of dd, such as this one.
That's why, I only showed a "conceptual" command syntax, without
showing variants suitable for both a Linux maintenance OS or
a Windows maintenance OS.
"Windows port of the dd disk dump program - sector by sector copying"
(Sector by sector copying works for any file system, even an unknown
file system can be copied this way in an emergency.)
http://www.chrysocome.net/dd
Using a maintenance OS, and booting that, allows a C: windows drive
to be copied, without running into the "busy file" problem. Windows,
when it is booted and running on C:, keeps certain files open. Attempting
to copy those files, with a file copy operation, would fail. So to
avoid the details, I simply switch to booting some "Other" OS,
to do the copy without regard to the details.
There is an option in Windows, using VSS Volume Shadow Service, that
allows copying a Windows file system. For example, this program
can run from Windows, and copy your C: drive as a VHD file, for
mounting in Virtual PC. This has nothing to do with your problem,
but shows you can make P2V copies of things like a C: drive while the
C: drive is in use. I even managed to boot the OS in a virtual
environment, when testing this - all that failed, was Microsoft
"product activation". So this really works.
http://technet.microsoft.com/en-us/sysinternals/ee656415
Windows 7 is capable of doing much the same thing (copy C:
to a .VHD) as part of its built-in backup capabilities. For example,
right now, I have a single VHD file, which contains the entire
C: drive from my Windows 7 laptop. I keep the single VHD file
mounted in Ubuntu, inside Virtual PC, on my WinXP machine (the machine
I'm typing this on). When someone asks a question, that requires
me examining what files are stored on a Windows 7 C:, I can
instantly view the contents of that laptop, using Virtual PC.
And all because I copied over the 30GB .VHD file from the
laptop.
There are an infinite number of ways of manipulating data,
and I've only just scratched the surface with my experiments.
I learned all this stuff the hard way, one experiment at a time.
I'm still not very good at it. My methods allow doing
these things, with a relatively low cost. I don't buy a ton of
$39.95 programs, to do these things. But on the other side of
the coin, it takes a bit of time to set these things up. And
some of my methods lack efficiency, and are easy to find fault
with. That's all part of the fun.
*******
OK, so looking at your description again, you want a method
to put the 80GB disk back, in an emergency.
If the Seagate drive ships with an NTFS partiton on it, for
the entire 2000GB, that's fine. No need to do anything. Before
exiting Windows to do this experiment, I might use "Properties"
to apply a "label" in Windows to the partition, to make it
easier to find. Perhaps I might change the label to "Fatty",
in lieu of the bulky size of the partition.
I boot my Ubuntu LiveCD. I open a Terminal window from
the Accessories. I also look in the "Places" menu, for the
Seagate 2000GB partition. Maybe I can see the word "Fatty" or
"2000GB" to click on. I click it, to mount it. Modern Linux can
safely mount NTFS and FAT32 partitions. Once clicked, they're
read/write (older Knoppix distros set them up read only,
and it's a few more steps to make them read/write in that
case).
Next, I go to the Terminal window, for a look.
df # lists mounted partitions
My partition has a label of "Fatty" and I happen to see
/media/Fatty in the df (disk free) command output.
ls /media/Fatty # list the disk, like a "dir" command
# this would list the root level of
# the partition on the big drive.
That should show the files Seagate left on the drive.
We're not going to disturb those files.
Next, I check the layout of the disk(s) connected to the
machine (which is now running Ubuntu from a LiveCD, nothing
installed on the hard drive).
ls /dev
Perhaps I see /dev/sda /dev/sda1 and /dev/sdb /dev/sdb1
That would imply two disk drives "sda" and "sdb", and
each one has one partition, such as partition "sda1" (NTFS
perhaps) and partition "sda2" (NTFS perhaps, on the large
disk). The machine I'm typing this on, has sda1, sda2, sda3
and sda4, because I'm defined all four primary partitions.
I can tell, from the partition count, which disk is which.
Using the fdisk command, I can look at the primary partition
structure.
sudo fdisk /dev/sda # open "sda" drive for a look
p # "print" the partition table
q # "quit", I'm not changing anything.
sudo is a way of elevating the user to adminstrator for the
duration of the command execution. (Yes, typing that is a
damn nuisance.)
Looking at the sector or block count in there, I can more or less
identify which disk is which. My "Fatty" disk would have a
huge block count, compared to the 80GB drive.
Since I clicked the 2000GB labeled seagate partition, which
is mounted as /media/Fatty , we can now copy the 80GB drive.
The "/dev/sda" says to copy the entire disk. If I said "/dev/sda1"
that would copy only the first partition and no MBR etc.
Doing "/dev/sda" copies the entire disk.
sudo dd if=/dev/sda of=/media/Fatty/80GB.dd
That will copy the sectors from /dev/sda, into a file stored
on /media/Fatty (my 2000GB seagate drive with single partition).
Copy will proceed at around 13MB/sec. The command will only
stop, when it runs out of media to copy. It'll stop at
80GB, when it "hits the end" of /dev/sda.
By providing block size and block count parameters, I can
speed the command up (and control how much it copies).
I've discovered, due to the habit of modern drives actually
being 4KB sector based internally, that a block size of 8192
is optimal for transfer speed.
I take the "exact" size in bytes of the 80GB drive, and
divide by 8192. It should divide exactly, without a remainder.
I can then craft bs (block size) and count parameters, based
on the arithmetic.
To take an example, I consult the log I keep of all my
experiments involving cloning or imaging. One of my disks
is 250,059,350,016 bytes in size. If I divide 8192 into
that, I get 30524823. If I were to do the "dd" disk copy,
it would look like this. Your disk will have a weird size
slightly larger than 80,000,000,000 bytes, and you can
do the math in a similar way. (Linux also measures things
in 1K blocks, so you may see a number like 40,000,000,000.)
If using this command syntax, you must be careful to enter
the numbers correctly. I remember one disk copy I attempted,
where I mistyped the number, and "snipped the end" off the
disk :-(
sudo dd if=/dev/sda of=/media/Fatty/250GB.dd bs=8192 count=30524823
Doing the command that way, transfers data at 39MB/sec, or
about three times faster than the other, parameterless
command.
On my older disks, I use a bs (block size) larger than
8192. Using the Linux "factor" program, I can factor
250,059,350,016 as the product of a series of simple
integers. I can then select a block size, larger than
8192. But what I've discovered with the latest generation
of drives, is they actually transfer slower, if I use
a large block size which is not a multiple of 4K. And
by accident, I tried 8192 as a value, and it actually
ran faster. Normally, on an older disk, using bs=8192
would be a bit on the small side and slow. But without that
option, perhaps less of the true speed of the
large disk, will be available to you.
Paul
