Creating an SSD Replacement

[Juan Wei]

I want to recreate my C: drive on an SSD drive that is presently
connected via USB. Eventually, I will physically replace the hard drive
with the bootable SSD which will then become the C: drive.

Do I want to clone or image?

I have Macrium Reflect v5.2 (free).

If I try to "clone", it does not recognize the SSD.

If I try to "image", it does. It says it will create
M:\{IMAGEID}-00-00.mrimg That doesn't look like a bootable image.

 

[philo]

I want to recreate my C: drive on an SSD drive that is presently
connected via USB. Eventually, I will physically replace the hard drive
with the bootable SSD which will then become the C: drive.

Do I want to clone or image?

I have Macrium Reflect v5.2 (free).

If I try to "clone", it does not recognize the SSD.

If I try to "image", it does. It says it will create
M:\{IMAGEID}-00-00.mrimg That doesn't look like a bootable image.

that's an image file,

If your operating system recognizes the external drive see if you can
restore the image to that.

Otherwise, install the SSD internally and clone your present drive to it.
Be sure to disconnect it before rebooting

 

[Paul]

I want to recreate my C: drive on an SSD drive that is presently
connected via USB. Eventually, I will physically replace the hard drive
with the bootable SSD which will then become the C: drive.

Do I want to clone or image?

I have Macrium Reflect v5.2 (free).

If I try to "clone", it does not recognize the SSD.

If I try to "image", it does. It says it will create
M:\{IMAGEID}-00-00.mrimg That doesn't look like a bootable image.

I looked at my copy of Macrium, and "clone" looks like
the operation to use.

For a clone to work, the destination disk has to be the same
size or larger than the source disk. If the destination disk
is smaller, you've got a problem.

Any other options, you'd want a Partition Manager, to make
any necessary changes.

If the SSD is smaller than the original disk, you can use
the Disk Management "shrink" function on a partition. But
the Win7 Disk Management may not be able to move the partitions
around to finish the job. Only if the original layout just
happened to leave the C: partition as the last partition,
might you benefit from a "shrink", followed by cloning
with Macrium.

Paul

 

[BobbyM]

I looked at my copy of Macrium, and "clone" looks like
the operation to use.

For a clone to work, the destination disk has to be the same
size or larger than the source disk. If the destination disk
is smaller, you've got a problem.

I think that may be a fallacy as I've successfully cloned larger drives
to smaller drives (as long as the data will fit on the new drive) -
granted I wasn't using Macrium. At the worst, you're out a few minutes
of time installing the extra drive & running the program. It should
tell you whether the new drive is acceptable for the cloning process.
If it's not, then go to plan b.

 

[Monty]

I want to recreate my C: drive on an SSD drive that is presently
connected via USB. Eventually, I will physically replace the hard drive
with the bootable SSD which will then become the C: drive.

Do I want to clone or image?

I have Macrium Reflect v5.2 (free).

If I try to "clone", it does not recognize the SSD.

If I try to "image", it does. It says it will create
M:\{IMAGEID}-00-00.mrimg That doesn't look like a bootable image.

Go to http://www.macrium.com/reflectfree.aspx and look at the
"feature comparison". In particular, note the item "Restore to
dissimilar hardware" and you will note that the free version is not
the version for what you want to do.

 

[Char Jackson]

For a clone to work, the destination disk has to be the same
size or larger than the source disk. If the destination disk
is smaller, you've got a problem.

The cloning programs I've used over the past 10 years or so have all
defaulted to some version of 'smart cloning', making it possible to clone to
a smaller drive as long as the data will fit. Generally speaking, it makes
little sense to clone empty sectors.

 

[Char Jackson]

Go to http://www.macrium.com/reflectfree.aspx and look at the
"feature comparison". In particular, note the item "Restore to
dissimilar hardware" and you will note that the free version is not
the version for what you want to do.

I think "Restore to dissimilar hardware" may not mean what you think it
means. The dissimilar hardware refers to the computer you're restoring to,
not the drive you're restoring to.

 

[Paul]

On 8/23/2013 8:45 AM, Paul wrote:

I think that may be a fallacy as I've successfully cloned larger drives
to smaller drives (as long as the data will fit on the new drive) -
granted I wasn't using Macrium. At the worst, you're out a few minutes
of time installing the extra drive & running the program. It should
tell you whether the new drive is acceptable for the cloning process. If
it's not, then go to plan b.

What you're referring to, would require resizing a partition
as well as copying. Because tools typically do not like to
combine operations (two operations into one step), this
is not actually that easy to do.

It is more along the lines of something a Partition Manager
application might do. You're talking about a copying operation,
that can take this source, to that destination disk.

+-----+------------------+---------------------------------------+ Source
| MBR | Small partition | Large partition (half full of files) | Disk
+-----+------------------+---------------------------------------+

+-----+------------------+---------------------------+ Destination
| MBR | Small partition | Large partition (shrunk) | Disk
+-----+------------------+---------------------------+ (not to scale)

To do that, you start with a partition by partition copy. The MBR
and the "Small partition" are easy to copy. No arguments there.

To handle the last one though, in the way you claim, requires resizing
the partition, and copying it, at the same time. Historically,
partition management tools don't like to do that. It's because
"primitive operations" are easier to execute correctly, for
a developer. To do that, as depicted above, would effectively
involve coding a file by file copy operation, to a new partition
created on the destination disk. Then correcting the file system
header so that it is functionally equivalent to the source disk.

If I was doing this at home here, my sequence would be as follows,
using the primitives available to me. It would happen in two
steps, and not require nearly as fancy an operation.

1) Shrink the large partition, on the source disk first.
(In Windows 7, this can be done in Disk Management.)
This reduces the extent (last sector address) of the
source data. The end of the disk is now empty on the source,
and nothing there needs to be copied (assumes no Dynamic Disks
are involved).

+-----+------------------+---------------------------+ Source
| MBR | Small partition | Large partition (shrunk) | Disk
+-----+------------------+---------------------------+

2) Now, I can use Macrium, since the destination is now
sufficiently large to hold the whole thing. The clone
option should "light up", because sufficient space
exists on the destination, to make it possible.

So while a tool may exist, to implement the first style
of copying, it's also more dangerous, and more possible
to screw up some tiny detail along the way. Seeing
as one of the free partition management tools, managed
to break a FAT32 while resizing it, I would not trust
them to do some "two in one" type of operation. If they
can't execute "primitive" operations correctly, what
are the odds some special two in one would be coded
correctly ?

It is for similar reasons I don't recommend the "Merge"
feature on any tool. Complexity is higher than on more
simple primitive operations. Not worth the risk (at least,
without a backup so the risk is reduced). And you may not
be able to determine, by inspection, that a Merge actually
worked properly. Maybe there is damage you might only notice
six months from now.

Any time you're dealing with disk sized applications, ones
that manipulate hundreds of gigabytes of data, it's a matter
of "trust". You do as much testing as you can, under controlled
conditions. See whether the tools do risky things, and only
trust a tool, once it is proven to not be a total failure.
That means doing lots of backups at first, as insurance.

Paul

 

[Paul]

The cloning programs I've used over the past 10 years or so have all
defaulted to some version of 'smart cloning', making it possible to clone to
a smaller drive as long as the data will fit. Generally speaking, it makes
little sense to clone empty sectors.

I can think of a couple (easy to draw) cases.

1) Defined partitions, sum total, is smaller than destination.
This is a trivial case. If the empty space is sandwiched
in the middle, then some care is required. The only partitions
I know of, which are position sensitive, are Win98 boot, and
perhaps the others can have their origin changed without
needing to be tweaked.

+-----+---------------------------------------+---------------+ Source
| MBR | Large partition (half full of files) | (Empty Space) | Disk
+-----+---------------------------------------+---------------+

+----------------------------------------------------+ Destination
| | Disk
+----------------------------------------------------+

2) In this case, the source partition will need to be defragmented,
stuff moved to the left, the file system envelope shrunk,
then the copy can proceed. In the end, the source partition
envelope could be resized to take up the original space.
In other words, you can abuse the source disk as a scratch
pad, in preparing for your smart clone.

+-----+---------------------------------------+ Source
| MBR | Large partition (half full of files) | Disk
+-----+---------------------------------------+

+-----------------------------------------+ Destination
| | Disk
+-----------------------------------------+

*******

It all depends as to what extent you're allowed to make
changes to the source disk (even if those changes
are temporary). Defragmenting the large partition,
temporarily changing the envelope before doing the copy,
then changing it back, involves some risk if the tool
crashes (say, bad RAM), half way through an operation.
The best operations are the ones that involve fewest
state changes. Especially if they're not "power fail"
or "crash" safe. The Microsoft defragmentation API
for example, is supposed to be safe, which is also why
it has such dreadfully slow performance.

The notion of not making any changes to the source,
and massaging the data on the fly (while copying),
that sounds a bit risky. It's not risky in the sense
of damaging the source - it's risky in the sense that
the user may not detect a problem with the copy that
has been made, until it's too late (six months from now).

You want operations that are as mechanical as possible,
such as copying sectors. Copying at the file level
sounds easy, but on a modern OS you've got reparse points,
hard links, alternate streams, lots of stuff to get
wrong if you're writing your own code. Imagine writing
Robocopy, if you didn't have a set of Microsoft documentation
on hand to help you... So if that's how the smart
clone is being done, I don't know if I'd want to use it.

The track record on tools like this, must be "squeaky clean".
Even one report of fouling up someones disk, is too much.

Paul

 

[Timothy Daniels]

"Paul" replied:

I looked at my copy of Macrium, and "clone" looks like
the operation to use.

For a clone to work, the destination disk has to be the same
size or larger than the source disk. If the destination disk
is smaller, you've got a problem.

Any other options, you'd want a Partition Manager, to make
any necessary changes.

If the SSD is smaller than the original disk, you can use
the Disk Management "shrink" function on a partition. But
the Win7 Disk Management may not be able to move the
partitions around to finish the job. Only if the original layout
just happened to leave the C: partition as the last partition,
might you benefit from a "shrink", followed by cloning
with Macrium.

Paul

Macrium Reflect Free can clone to a partition smaller than
the source partition as long as the amount of data in the
source partition can fit in the destination partition. If it looks
close, try defragmenting the source partition before cloning it.
I know whereof I speak because I cloned Win7 Pro from a
large partition to a smaller partition on another drive by using
Macrium Reflect Free just 2 weeks ago, and the clone boots and
runs fine. Casper and other major cloners can do this, too, BTW.
It's required by the marketplace nowadays.

*TimDaniels*

 

[Timothy Daniels]

I want to recreate my C: drive on an SSD drive that is presently
connected via USB. Eventually, I will physically replace the hard drive
with the bootable SSD which will then become the C: drive.

Do I want to clone or image?

I have Macrium Reflect v5.2 (free).

If I try to "clone", it does not recognize the SSD.

[ . . . ]

Did you align the SSD partition correctly?
from http://www.howtogeek.com/97242/how-to-migrate-windows-7-to-a-solid-state-drive/ :

"If you install Windows 7 directly onto an SSD (instead of cloning, as we're doing)
the installation program makes sure that everything is aligned properly and that
the outmoded sector-based system works fine on the SSD. If you clone onto an
SSD from a HDD, however, there is a very high probability that the alignment will
be off. What this means, in practical terms, is that you will radically increase your
SSD read/writes and decrease performance because of the poor alignment. You'll
be wearing out and slowing down the drive, all over something as tiny as data
misalignment."
I'm not saying that this is causing the non-recognition problem, but proper
alignment increases efficiency for an SSD.

*TimDaniels*

 

[Gene E. Bloch]

I think that may be a fallacy as I've successfully cloned larger drives
to smaller drives (as long as the data will fit on the new drive) -
granted I wasn't using Macrium. At the worst, you're out a few minutes
of time installing the extra drive & running the program. It should
tell you whether the new drive is acceptable for the cloning process.
If it's not, then go to plan b.

I've frequently used Macrium to clone a drive to a smaller destination.

Of course, the amount of disk space used in the source drive must be
smaller than the capacity of the destination drive (AKA "Duh!").

 

[Gene E. Bloch]

What you're referring to, would require resizing a partition
as well as copying. Because tools typically do not like to
combine operations (two operations into one step), this
is not actually that easy to do.

Macrium doesn't seem to find the process at all difficult. It just
clones the source to the destination without complaint or extra time.

I've done it dozens of times.

 

[Paul]

Macrium doesn't seem to find the process at all difficult. It just
clones the source to the destination without complaint or extra time.

I've done it dozens of times.

Macrium is supposed to be based on VSS (makes a shadow copy).
That's how it backs up C:, without a reboot.

I've been searching on VSS API, and don't see any obvious
option in there, to change the size of the copy.

VSS is block based, not file based. And squeezing files into
a smaller space, requires moving them, changing the entry in
the $MFT for them, and so on (i.e. file based, file pointers).
You can do that with a defragmentation API (that moves things
and does bookkeeping for you, and does it safely), but then,
you need a place to work, to do that. Like, changing the
source volume (by defragmenting), to make it easier to pack.

That takes the least developer effort, but breaks the
rule of not changing the source state. And there isn't sufficient
space on the destination disk, to do it there either.

And while some tool developers, do write lots of stuff from
scratch (like the defragmenter product that does amazing things
and can move any metadata file on NTFS), most developers
seek to avoid that, because it takes a lot of expertise to
get right.

*******

To give an example of why this kind of study is important...

I have a copy of Partition Magic. It supports EXT2 partitions
(Linux). Now, you'd say "that's amazing", that they would go
the extra mile to handle a foreign format.

And you'd probably say to yourself "that'll take custom code"
and "there will be risks".

So, I use the capability in PM. I create an EXT2. It turns out,
the EXT2 it makes, is "old style". And an attempt to convert
it to "new style" with Linux, fails. That's an example of custom
code, that shoots the customer in the foot. The problem with the
old style EXT2, is a capacity limitation. Linux contains code to
"fix" that on the fly, and it does work for a partition created
by some old Linux distro. But it didn't work for the partition
created by PM. (Now, when I use PM, I have to consult my
mental "table of quirks", as to what works, and what doesn't
work worth a damn.)

The more standard the code path a tool uses, the better the odds
of a positive outcome. That's why I try to harvest any
information that's available about them. To know what to expect.

Paul

 

[Paul]

Macrium doesn't seem to find the process at all difficult. It just
clones the source to the destination without complaint or extra time.

I've done it dozens of times.

OK, I tried an experiment. Because of what I could see
in the Application Data folder.

When I ran a backup with Macrium, a file with extension .vsslog
was left. And in there, are some log entries for what it was doing.

I figured, I'd test your situation (clone larger disk to smaller
disk), and then examine the .vsslog after it was finished. This
would be "clone", rather than backup.

To my surprise, the .vsslog file did not get updated. So "clone"
doesn't leave the same evidence trail as "backup" does.

I cloned a 250GB drive to a 160GB drive. And the single partition I
tested with, had maybe 147GB of files, in various states of fragmentation.

The destination disk, ended up pretty full (as expected), and with
less fragmentation. Not zero fragmentation, due to the fullness of
the disk, and the need to convert $MFT reserved space into file
storage space. The transfer couldn't have all fragmentation removed.

In terms of the transfer characteristic, it "looked like a VSS transfer"
in that the disk heads didn't seem to be flying all over the place. The
transfer seemed to be roughly sequence, at around 45MB/sec (old disks).
The transfer rate was steady - not like the Robocopy transfers I do
all the time here, which can vary from as low as 1MB/sec to 135MB/sec
(depending on file sizes). Using Performance Monitor, tells me the
transfer is likely VSS based.

But with no .vsslog to go on, there are no log comments to analyse.
And determine how this mode of transfer is possible.

Since it doesn't create a log, that almost suggests the function in
question (clone n' squeeze), is built into something. But without
any log file, "their secret is safe".

A file "XMLFiles.dat" had the date changed on it, but the file
is virtually empty. I don't know if that had something to do
with it, or not. I tried Googling that, and didn't get anywhere.

My conclusion is, the VSS stuff has something magical to
do for file-by-file operations. And that means the
Wikipedia article that claims it is block oriented,
might not strictly be true.

You know, this evidence just doesn't make sense. If the
files are repositioned, then they're written to different
offsets in the new partition. You can't have a "smooth" transfer
curve if that is the case. The only way the transfer curve could
be smooth, is if the reader and writer are both sequential. But
to rewrite the files, as has been done here, some of the files
must be out of order, and the head movement for that, should
cause the Performance Monitor transfer rate graph to be "spiky".

So it really is magical...

I checked with NFI (the NTFS file listing utility), and
it appears the "clone n' squeeze" processes files in file number
order. But the files on the source disk, wouldn't be in spatial
order (for a disk that is well fragmented). The destination is
pretty well ordered (written in spatial order), and not too fragmented.
The last four large files transferred, didn't have any fragments at all.
Even though that partition is very close to full.

"Processed in file order, written in spatial order
(File 41 on the source disk, is also kav_rescue_10__Feb24_2013.iso)"

File 41
\kav_rescue_10__Feb24_2013.iso
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 10150984-10729079 (0x9ae448-0xa3b677)

File 42
\rescue2usb__kav_installer.exe
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 10729080-10729839 (0xa3b678-0xa3b96f)

File 43
\KNOPPIX_V7.0.5CD-2012-12-21-EN.iso
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 10729840-12157799 (0xa3b970-0xb98367)

So maybe VSS does it that way all the time, and I just missed
it ? There just doesn't seem to be that much head movement when
VSS copying is going on. Guess I'll need a "severely fragmented"
disk to shine more light on how it works.

Paul

 

[Juan Wei]

Paul has written on 8/22/2013 7:45 PM:

I looked at my copy of Macrium, and "clone" looks like
the operation to use.

Did you miss "If I try to 'clone', it does not recognize the SSD."?

However, I did solve that problem.

 

[Juan Wei]

Char Jackson has written on 8/22/2013 9:36 PM:

The cloning programs I've used over the past 10 years or so have all
defaulted to some version of 'smart cloning', making it possible to clone to
a smaller drive as long as the data will fit. Generally speaking, it makes
little sense to clone empty sectors.

Interesting. The clone I was finally able to do "copied" the entire
partition and not just the data.

 

[Juan Wei]

Timothy Daniels has written on 8/22/2013 11:47 PM:

Macrium Reflect Free can clone to a partition smaller than
the source partition as long as the amount of data in the
source partition can fit in the destination partition. If it looks
close, try defragmenting the source partition before cloning it.
I know whereof I speak because I cloned Win7 Pro from a
large partition to a smaller partition on another drive by using
Macrium Reflect Free just 2 weeks ago, and the clone boots and
runs fine.

Did you clone:

1) the entire drive,
2) just the "C:" partition, or
3) the C: and the (for me) 100MB SYSTEM RESERVED partition?

 

[Gene E. Bloch]

OK, I tried an experiment. Because of what I could see
in the Application Data folder.

When I ran a backup with Macrium, a file with extension .vsslog
was left. And in there, are some log entries for what it was doing.

I figured, I'd test your situation (clone larger disk to smaller
disk), and then examine the .vsslog after it was finished. This
would be "clone", rather than backup.

To my surprise, the .vsslog file did not get updated. So "clone"
doesn't leave the same evidence trail as "backup" does.

Suggestion: just accept that it works.

 

[Timothy Daniels]

"Juan Wei" asked:

Timothy Daniels has written:

Did you clone:

1) the entire drive,
2) just the "C:" partition, or
3) the C: and the (for me) 100MB SYSTEM RESERVED partition?

Just the C: partition, although it could have been any other
single partition. The 100MB "System Reserved" partition is for
the boot files if you're using the added security or expanded
multi-booting facilities of UEFI firmware. If you don't need the
extra security or the ability to boot from more than 4 partitions,
the legacy BIOS firmware is fine and you can put the boot files in
the OS's partition using standard Windows utilities and boot
directly from there (remembering, though, to mark the partition
"active") just as in previous Windows versions. I freed up my own
100MB System Partition by cloning the OS partition to another
HDD, then deleting the 100MB partition and the C: partition, then
creating a new single partition in their place, and then re-cloning
the clone to the new single partition. The point was not to gain
the extra 100MB of space, but to make a primary partition available
for Linux.

*TimDaniels*