My OCZ Agility 2 120 drive has just died for the second time

On 3/6/2012 8:14 PM, Metspitzer wrote:
I am not too pleased to be starting over for the 3rd time. Nothing
was backed up, but nothing but my settings were lost.
The good news is that OCZ has agreed to replace it with an Agility 3.

I am considering ordering another Agility 3 and trying RAID.


Has anyone tried 'Clonezilla' ?

http://clonezilla.org/

I used it to clone a Linux partition but haven't tried to copy it back
yet. It was free and very easy to use, reads all types of file systems
including NTFS, but I don't have a bunch of spares drives about to test
copying the info back.

John

On Fri, 09 Mar 2012 04:43:39 -0500, Paul wrote:

Allen Drake wrote:


I have the SW that comes with the HDDs like Seagate but I was trying
to clone my many Crucial SSDs to install the latest FW and that
application won't work. I looked into Acronnis but they want $50 for
one system and $79 for three. I have 8 Systems and while I don't mind
spending the money I don't want to give it away. I am now trying to
clone an OCZ 90G from a Crucial 128 using APRICON EZ GIG III but
something seems to be going terribly wrong. I started it at 12
Midnight and now the screen says it's copying bad sectors. It has been
going for over 3 hours and says there are 12 Hours left. I hope MY OCZ
is not a piece of junk. I may have to send it back and ask for a
refund. I have cloned Crucial SSDs several times and nothing like this
ever happened. I have the OCZ connected to an external USB cable. What
do you think?

AL.


Has it copied past the end of one of the drives ? (Size mismatch)

Judging by the datasheet, it does something a bit dangerous.

http://www.apricorn.com/pdf_data_she..._datasheet.pdf

"Dynamic resizing, to match new Hard Drive"

I wonder if they wrote that software themselves ?

If there is a single partition on the 128, maybe it
doesn't fit on the 90G drive ?

EZ_Gig_III_software
Crucial 128 --------------------- OCZ 90G

Paul

Something strange occurred indeed. I have used this application to
clone many of my system HDDs that were mostly 1 Gig in size to the
smaller 256 Gig Crucial making sure the size of the OS was always
smaller then the destination SSD. This time the same was true. The
drive I am using on this ASUS Netbook is a cloned SSD of the original
HDD that has 2 partitions. Today when I arrived home having left the
computer on I found a report that the copy had failed with selections
to delete the troubled copy that may not work or to go forward and try
to repair what ever the problem was. I selected the delete option. I
then removed the OCZ and attached it to another system and formatted
it with Computer manager. Then I attempted the same process with the
Netbook and it worked in less than one hour and have no idea what
actually happen the first time.

I am not sure what the danger is in using their "Dynamic Resizing"
feature as isn't this also done if you clone with other apps to get
the same results? Maybe they call is something else but I remember
having to tell other apps I plan to use a specific type of copy
technique if I am using a smaller destination drive.

On Fri, 09 Mar 2012 12:09:51 +0000, Rob
wrote:

On 09/03/2012 02:26, Paul wrote:
Allen Drake wrote:
On Tue, 06 Mar 2012 21:11:04 -0500, wrote:

Paul wrote:
Metspitzer wrote:
I am not too pleased to be starting over for the 3rd time. Nothing
was backed up, but nothing but my settings were lost.
The good news is that OCZ has agreed to replace it with an Agility 3.

I am considering ordering another Agility 3 and trying RAID.
Also, another item you should be aware of, is the File and Settings
Transfer Wizard or FAST.

Now, I've never used this, and I expect it's a pig, but have a look
at it anyway.

http://technet.microsoft.com/en-us/l.../bb457074.aspx

In the picture, the wizard has an option to just capture
settings.

http://technet.microsoft.com/en-us/l...g(l=en-us).gif

There are differences, between OSes, as to what is captured.
So I don't know if that tool is entirely consistent in its
approach from one OS version to the next. But in terms
of things to read up on, it's something else to consider.

I'd just use a complete backup instead, as that is seamless.

Paul

What would you consider the best cloning SW if you didn't care about
the cost. My theme is money is no object when you get to be my age.

Al.

I'm a cheapskate, so perhaps the wrong person to ask. I tend to
use the things that are free. Perhaps Macrium Reflect, or the
Windows 7 System Image, or even a copy of "dd" and just back up
all the sectors.

Acronis makes tools that a lot of people like, but the latest
versions of Acronis have become bloated. Perhaps someone else
here can comment on that.

I also use disk partitioning software, for cloning tasks.
Like copying my C: from one drive to another. But the software
I use there, is quite old, and not actually able to deal with
all the disks I own. It has something like a 200GB upper limit.

So the stuff I use, is either free, or too old to buy now :-)

Paul

I agree that Acronis True Image Home has become rather bloated,
but it is still possible to make a boot CD after installing it
and use that for cloning drives or partitions.
Cloning from a TI boot CD is very flexible [1], reliable and fast.
I must get around to converting that CD to a bootable USB stick
as I'm probably going to stop including optical drives in future
PC builds.

[1] I found it is capable of accessing my external RAID10 box
which is connected by e-SATA, for example, and pretty sure it
can also access network drives on other machines on my LAN,
allowing multipally redundant online backup locations.

HTH,

Thanks. I have no doubt that TI is a reliable and effective
application as I remember using a version that may have come with a
drive I purchased as an app that can be used with that drive. Maybe a
Lite version or something, I don't really remember. The issue I have
is the cost of $50 for one system and extra for multiple systems. I
have 8 systems and don't feel that price is fair if there are so many
others many being free. I merely want a cloning app and not a full
backup and recovery suite. I think I even have an old copy of Ghost
that might work if I can dig it out somewhere.

On Fri, 9 Mar 2012 20:53:58 +0000 (UTC), Parko
wrote:

On Thu, 08 Mar 2012 16:35:28 -0500, Allen Drake wrote:

What would you consider the best cloning SW if you didn't care about
the cost. My theme is money is no object when you get to be my age.

Al.

Any live Linux CD will perform that function with the dd command executed
on the target partitions. dd if=/dev/sda1 of=/dev/sdb1

I have read that. I must actually get down to using Linux once and
for.


Q: What's an Australian kiss? A: Just like a French kiss, but down
under.

English muffin beats French kissing any day.

Allen Drake wrote:
On Fri, 9 Mar 2012 20:53:58 +0000 (UTC), Parko
wrote:

On Thu, 08 Mar 2012 16:35:28 -0500, Allen Drake wrote:

What would you consider the best cloning SW if you didn't care about
the cost. My theme is money is no object when you get to be my age.

Al.
Any live Linux CD will perform that function with the dd command executed
on the target partitions. dd if=/dev/sda1 of=/dev/sdb1

I have read that. I must actually get down to using Linux once and
for.


The "dd" option is good in certain circumstances. It doesn't resize
anything, so the destination must be the same size or larger than
the source. A port of "dd" is available for Windows, if you want
to try it out.

http://www.chrysocome.net/dd

I use dd-0.5 version quite a bit. The only bug I know of, is the
program doesn't always seem to know where the end of a USB storage
device is properly, and perhaps that's fixed in a later version.
I've never had it trash anything, but you have to be *very careful*
while using this. One typing mistake and... kaboom. You can easily
overwrite the wrong disk if you type too fast.

For an SSD, I recommend using a block size argument. That's to reduce
potential write amplification effects. If you do this flavor

dd if=/dev/sda1 of=/dev/sdb1

that would write in 512 byte chunks.

If you do something like this

dd if=/dev/sda1 of=/dev/sdb1 bs=131072

that writes in 128KB chunks, which are the same size as the flash
blocks.

For the Windows version, you have the added convenience of the list
option.

dd --list

That will list the proper Windows syntax for disk naming.

To store that list in a text file right now, I did this. The list
is printed out on stderr, and 2 redirects stderr to the named file.
(I put the .exe on the end, to make it clear this is Windows :-) )

dd.exe --list 2 output.txt

This is a snipped section from output.txt, which covers the syntax for
one of my two hard drives.

\\?\Device\Harddisk0\Partition0 --- used to ref. the whole disk
link to \\?\Device\Harddisk0\DR0
Fixed hard disk media. Block size = 512
size is 500107862016 bytes
\\?\Device\Harddisk0\Partition1 --- first entry in partition table
link to \\?\Device\HarddiskVolume1
Fixed hard disk media. Block size = 512
size is 20974431744 bytes
\\?\Device\Harddisk0\Partition2
link to \\?\Device\HarddiskVolume2
Fixed hard disk media. Block size = 512
size is 20974464000 bytes
\\?\Device\Harddisk0\Partition3
link to \\?\Device\HarddiskVolume3
Fixed hard disk media. Block size = 512
size is 19197771264 bytes
\\?\Device\Harddisk0\Partition4 --- fourth entry in partition table
link to \\?\Device\HarddiskVolume4
Fixed hard disk media. Block size = 512
size is 438958517760 bytes

To copy one entire disk to the other, you'd do it like this.

dd if=\\?\Device\Harddisk0\Partition0 of=\\?\Device\Harddisk1\Partition0

If the sizes of the disks aren't equal, you have blocksize and count
parameters to use. Switching to Parko's Linux syntax for a moment,
to copy from one hard drive to another, it would look like this.
This transfers 500107862016 bytes. The block size is a multiple of
512 bytes. The first number is 432 sectors, not an even multiple
of a flash block (but then in this case, I'd transferring one
hard drive to another).

dd if=/dev/sda of=/dev/sdb bs=221184 count=2261049

To work out the block size and count parameters, there is a
port of the Linux "factor" program available. I issue the
command like this, in command promot.

factor.exe 500107862016

And the answer comes back like this. I then can pick the
blocksize and count parameters, such that precisely
the entire disk (or a single partition) get transferred,
with no possibility of an overrun.

500107862016: 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 7 67 1607

One factor I see right away there, is 8192 from all those 2's.
So if I was transferring using hard drives with 4K sectors, or
with SSD drives, I might craft a transfer like this.

dd if=/dev/sda of=/dev/sdb bs=8192 count=61048323

The command can also be run without a count, like this,
and this transfers until the source disk runs out of
bytes to give.

dd if=/dev/sda of=/dev/sdb bs=8192

Now, if I did it that way, the Windows port of "dd" reports
the count of items transferred. If all went well, it would
report "61048323" as the number of items (blocks) transferred.
Then I'd have a fair idea it did what I expected.

Using both a blocksize and count, is important for preventing
something you're doing, from overwriting something important.
And the best blocksize, affects the performance of the command.
This command, runs at 13MB/sec on my system.

dd if=/dev/sda of=/dev/sdb

and this command, runs at 39MB/sec on my system. My current
generation drives, "like" multiples of 4096 and the block
size doesn't have to be big. Some previous generation
hard drives, would "like" the 221184 sized number, and
my older (160GB) drives, excel with something 221184 sized.
But the modern drives seem to like the multiple of 4096 a lot.

dd if=/dev/sda of=/dev/sdb bs=8192

And if you're transferring huge chunks of data, it pays off
to use an efficient transfer means. In the case of the SSD,
you'd hope at least some transferring cases there, involve
nice power_of_two numbers, for best flash usage. I don't know
if the SSD behaves that well, when receiving bs=512 (default size)
transfers. It's better to "factor" and work out some good
numbers to use. An SSD prepared on Windows 7 or Vista,
should involve lots of power_of_two type numbers, to align
better to the flash blocks.

The dd command also has "seek" and "skip" parameters, which
allow "moving" a partition, so it doesn't end up with the
same offset. I've used those kinds of options, when "snipping"
a chunk of data off the 500GB disk, for examination with a
hex editor. If you don't own a disk editor, you can snip
manageable chunks out of the disk, and use a hex editor instead.

dd is a very handy command (but bring your hand calculator :-) )

To get the "factor.exe" program, see the coreutils package here.

http://gnuwin32.sourceforge.net/packages.html

Paul

On Fri, 09 Mar 2012 23:40:07 -0500, Paul wrote:

Allen Drake wrote:
On Fri, 9 Mar 2012 20:53:58 +0000 (UTC), Parko
wrote:

On Thu, 08 Mar 2012 16:35:28 -0500, Allen Drake wrote:

What would you consider the best cloning SW if you didn't care about
the cost. My theme is money is no object when you get to be my age.

Al.
Any live Linux CD will perform that function with the dd command executed
on the target partitions. dd if=/dev/sda1 of=/dev/sdb1

I have read that. I must actually get down to using Linux once and
for.


The "dd" option is good in certain circumstances. It doesn't resize
anything, so the destination must be the same size or larger than
the source. A port of "dd" is available for Windows, if you want
to try it out.

http://www.chrysocome.net/dd

I use dd-0.5 version quite a bit. The only bug I know of, is the
program doesn't always seem to know where the end of a USB storage
device is properly, and perhaps that's fixed in a later version.
I've never had it trash anything, but you have to be *very careful*
while using this. One typing mistake and... kaboom. You can easily
overwrite the wrong disk if you type too fast.

For an SSD, I recommend using a block size argument. That's to reduce
potential write amplification effects. If you do this flavor

dd if=/dev/sda1 of=/dev/sdb1

that would write in 512 byte chunks.

If you do something like this

dd if=/dev/sda1 of=/dev/sdb1 bs=131072

that writes in 128KB chunks, which are the same size as the flash
blocks.

For the Windows version, you have the added convenience of the list
option.

dd --list

That will list the proper Windows syntax for disk naming.

To store that list in a text file right now, I did this. The list
is printed out on stderr, and 2 redirects stderr to the named file.
(I put the .exe on the end, to make it clear this is Windows :-) )

dd.exe --list 2 output.txt

This is a snipped section from output.txt, which covers the syntax for
one of my two hard drives.

\\?\Device\Harddisk0\Partition0 --- used to ref. the whole disk
link to \\?\Device\Harddisk0\DR0
Fixed hard disk media. Block size = 512
size is 500107862016 bytes
\\?\Device\Harddisk0\Partition1 --- first entry in partition table
link to \\?\Device\HarddiskVolume1
Fixed hard disk media. Block size = 512
size is 20974431744 bytes
\\?\Device\Harddisk0\Partition2
link to \\?\Device\HarddiskVolume2
Fixed hard disk media. Block size = 512
size is 20974464000 bytes
\\?\Device\Harddisk0\Partition3
link to \\?\Device\HarddiskVolume3
Fixed hard disk media. Block size = 512
size is 19197771264 bytes
\\?\Device\Harddisk0\Partition4 --- fourth entry in partition table
link to \\?\Device\HarddiskVolume4
Fixed hard disk media. Block size = 512
size is 438958517760 bytes

To copy one entire disk to the other, you'd do it like this.

dd if=\\?\Device\Harddisk0\Partition0 of=\\?\Device\Harddisk1\Partition0

If the sizes of the disks aren't equal, you have blocksize and count
parameters to use. Switching to Parko's Linux syntax for a moment,
to copy from one hard drive to another, it would look like this.
This transfers 500107862016 bytes. The block size is a multiple of
512 bytes. The first number is 432 sectors, not an even multiple
of a flash block (but then in this case, I'd transferring one
hard drive to another).

dd if=/dev/sda of=/dev/sdb bs=221184 count=2261049

To work out the block size and count parameters, there is a
port of the Linux "factor" program available. I issue the
command like this, in command promot.

factor.exe 500107862016

And the answer comes back like this. I then can pick the
blocksize and count parameters, such that precisely
the entire disk (or a single partition) get transferred,
with no possibility of an overrun.

500107862016: 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 7 67 1607

One factor I see right away there, is 8192 from all those 2's.
So if I was transferring using hard drives with 4K sectors, or
with SSD drives, I might craft a transfer like this.

dd if=/dev/sda of=/dev/sdb bs=8192 count=61048323

The command can also be run without a count, like this,
and this transfers until the source disk runs out of
bytes to give.

dd if=/dev/sda of=/dev/sdb bs=8192

Now, if I did it that way, the Windows port of "dd" reports
the count of items transferred. If all went well, it would
report "61048323" as the number of items (blocks) transferred.
Then I'd have a fair idea it did what I expected.

Using both a blocksize and count, is important for preventing
something you're doing, from overwriting something important.
And the best blocksize, affects the performance of the command.
This command, runs at 13MB/sec on my system.

dd if=/dev/sda of=/dev/sdb

and this command, runs at 39MB/sec on my system. My current
generation drives, "like" multiples of 4096 and the block
size doesn't have to be big. Some previous generation
hard drives, would "like" the 221184 sized number, and
my older (160GB) drives, excel with something 221184 sized.
But the modern drives seem to like the multiple of 4096 a lot.

dd if=/dev/sda of=/dev/sdb bs=8192

And if you're transferring huge chunks of data, it pays off
to use an efficient transfer means. In the case of the SSD,
you'd hope at least some transferring cases there, involve
nice power_of_two numbers, for best flash usage. I don't know
if the SSD behaves that well, when receiving bs=512 (default size)
transfers. It's better to "factor" and work out some good
numbers to use. An SSD prepared on Windows 7 or Vista,
should involve lots of power_of_two type numbers, to align
better to the flash blocks.

The dd command also has "seek" and "skip" parameters, which
allow "moving" a partition, so it doesn't end up with the
same offset. I've used those kinds of options, when "snipping"
a chunk of data off the 500GB disk, for examination with a
hex editor. If you don't own a disk editor, you can snip
manageable chunks out of the disk, and use a hex editor instead.

dd is a very handy command (but bring your hand calculator :-) )

To get the "factor.exe" program, see the coreutils package here.

http://gnuwin32.sourceforge.net/packages.html

Paul

Well all that is something I just saved as a txt file. Very nice to
know but It will some time before I remember it all but something I
can practice on one my try anything boxes.

One thing about this EZ Gig III application that I find different it
needs no rebooting and does not lock the source drive. It is all done
with Windows still running and still accessible to the operator. It
seems simple to understand and I can't see making any mistakes. I
don't know what would happen if you actually asked it to make C drive
the destination drive. Maybe I'll give that a try on a setup I have
laid out on one of my open air cases.

http://www.amazon.com/Deck-Tech-Stat.../dp/B001JYRZ54

Allen Drake wrote:

Well all that is something I just saved as a txt file. Very nice to
know but It will some time before I remember it all but something I
can practice on one my try anything boxes.

One thing about this EZ Gig III application that I find different it
needs no rebooting and does not lock the source drive. It is all done
with Windows still running and still accessible to the operator. It
seems simple to understand and I can't see making any mistakes. I
don't know what would happen if you actually asked it to make C drive
the destination drive. Maybe I'll give that a try on a setup I have
laid out on one of my open air cases.

http://www.amazon.com/Deck-Tech-Stat.../dp/B001JYRZ54

Neat. The secret is that bar, to keep the plugin cards upright.

That's what is better than "pouring" a system over my kitchen table :-)
You have to be careful not to bump the video card, while the
motherboard sits on a phone book.

Paul