Want To Clone Desktop Hard Drive

Discussion in 'Backup Software' started by tb, Jul 22, 2011.

  1. tb

    tb Guest

    Not sure if this is the appropriate forum. If not, please suggest an

    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?
    tb, Jul 22, 2011
    1. Advertisements

  2. tb

    John McGaw Guest

    If you are truly 'cloning' the original drive then the clone will have all
    of the characteristics, including the partitioning, of the original so any
    partitioning you do beforehand will be gone as soon as you finish the

    But are you seriously considering a new install of Windows 7 to such a
    tiny, and presumably old, drive? Don't get me wrong, it can certainly be
    done (I did it to an SSD just a bit bigger than that) but you won't have a
    huge amount of space left over for anything else like programs. Why not
    just buy a new drive to replace the 80gB? Do that and no clone is needed --
    just put the old drive in an anti-static container and put it away. Drives
    of 500gB-1tB are really cheap right now.

    But if you absolutely must be able to recreate an exact copy of the old
    80gB drive you might look at some free drive imaging software rather than
    tie an entire 2tB drive up by cloning an 80gB drive to it. I use the free
    version of Macrium Reflect which makes a digital image of a drive and can
    restore it from a file using a recovery CD.
    John McGaw, Jul 22, 2011
    1. Advertisements

  3. McGaw's comments (about a new HDD) are cogent.

    If you do not plan ever to boot Win98 from the TB drive,
    you do not need to clone a Win98 installation. Just copy
    (other than in Windows, i.e.using XXCOPY or Win7)
    the Win98 C: drive to a new logical drive on the TB drive
    (and copy SYS.COM to C:\root for convenience and
    delete the swap file) and your backup is complete.
    Don Phillipson, Jul 23, 2011
  4. tb

    Paul Guest

    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.)


    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.


    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

    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

    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

    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

    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, Jul 23, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.