Quickest Way To Move 160GB?

[rsvr85]

Hi all
Title says it all really!
I need to move 160GB from my internal hdd (C) to my external hdd (M). What's the quickest & most reliable way to do it?
I've tried to use robocopy in the command prompt and the GUI version of it but robocopy /E /MOVE C:\MyData M:\MyData doesn't execute as expected. In a dummy run (20GB) it missed an aweful lot of directories.

 

[AlexRD]

Hi all
Title says it all really!
I need to move 160GB from my internal hdd (C) to my external hdd (M). What's the quickest & most reliable way to do it?
I've tried to use robocopy in the command prompt and the GUI version of it but robocopy /E /MOVE C:\MyData M:\MyData doesn't execute as expected. In a dummy run (20GB) it missing an aweful lot of directories out.

try TeraCopy
Its a program

 

[H2SO4]

Hi all
Title says it all really!
I need to move 160GB from my internal hdd (C) to my external hdd (M). What's the quickest & most reliable way to do it?
I've tried to use robocopy in the command prompt and the GUI version of it but robocopy /E /MOVE C:\MyData M:\MyData doesn't execute as expected. In a dummy run (20GB) it missing an aweful lot of directories out.

Robocopy 4TW.

It doesn't miss stuff. In this instance, it's possible that the account context doesn't have permissions to some of the source subdirs. Use the /v (verbose) switch to get more info.

 

[poin2]

I'd use TeraCopy. Stick with version 1.22 for now.

http://www.codesector.com/download.php

There's also RichCopy out there as essentially a more recent version of RoboCopy.

http://technet.microsoft.com/en-us/magazine/2009.04.utilityspotlight.aspx?pr=blog

But for basic moving I've found Teracopy most reliable and easy to use. The others can be helpful when you need to mirror/sync things up and do other more advanced uses.

 

[harpua]

I like Tera Copy and the good news is that after a long hiatus, the developer has resumed work on the application. A new beta version was released in the past couple of days with minor changes, and hopefully active development will continue.

However, I've noticed that Windows 7 native copy function seems to copy faster than TeraCopy. I still use TeraCopy (latest beta version works best for me) because I prefer the informational popup it provides while copying is in progress, but hopefully, as development continues, the speed issue will be addressed and improved.

 

[H2SO4]

I like Tera Copy and the good news is that after a long hiatus, the developer has resumed work on the application. A new beta version was released in the past couple of days with minor changes, and hopefully active development will continue.

However, I've noticed that Windows 7 native copy function seems to copy faster than TeraCopy. I still use TeraCopy (latest beta version works best for me) because I prefer the informational popup it provides while copying is in progress, but hopefully, as development continues, the speed issue will be addressed and improved.

These utilities are all just front-ends for one or the other of the in-built file copy mechanisms. Every scenario calls for a particular range of attributes:

- Is it multi-threaded? Multiple concurrent copy operations are A Good Thing.
- What's the "chunk" size? Different sizes produce different effects. Bigger is not always better.
- How granular is the control over what to copy?
- Logging? How verbose?
- Scriptable? Easily?
- Robust - can it recover from unanticipated transients or at least report them?
... and so on.

None of these utilities implement some magically new method, but the multi-threaded ones (robocopy, richcopy) will have the performance edge, everything else being equal. Robocopy is highly configurable and scriptable. Richcopy is simpler and easier to use.

Cut'n'paste is the one method which should be avoided for massive transfers. It relies on the clipboard and that introduces extra complexity which cannot hope to match the throughput of the other mechanisms. The copy/xcopy commands are somewhere in between - devoid of the shell "chattiness" overhead inherent in drag'n'drop and cut'n'paste, but single-threaded and therefore not as fast in many cases.

For outright speed: ROBOCOPY <source> <dest> *.* /E /MT:8

 

[bobtran]

Create a TAR ball, copy it to location you want and then extract the tarball giving you all data and directory structure the way it was on original machine.

You can further reduce size by compressing it before transmission and then de-compress before extracting it.

Do a little searching on Google related to TAR balls and it will be easy.

 

[Tews]

Bob, correct me here if Im wrong, but TAR isnt a windows file ... its Linux...

 

[EarlZ]

How about the good old copy and paste method ??

 

[strollin]

If it's a one-time movement of the data it hardly seems worthwhile to DL and install a 3rd party tool to do it, a simple drag and drop within Windows Explorer will accomplish what you want. However, if it's something you need to do on a regular basis then it makes sense to find a faster method.

How your external HDD is attached (USB, FireWire, eSata, etc.) will have a greater impact on how fast the data is moved than the copy method.

 

[Antman]

...Every scenario calls for a particular range of attributes:

- Is it multi-threaded? Multiple concurrent copy operations are A Good Thing.
- What's the "chunk" size? Different sizes produce different effects. Bigger is not always better.
- How granular is the control over what to copy?
- Logging? How verbose?
- Scriptable? Easily?
- Robust - can it recover from unanticipated transients or at least report them?
... and so on.

...

For outright speed: ROBOCOPY <source> <dest> *.* /E /MT:8

I am interested in your analysis of Roadkil's Unstoppable Copier.

 

[zrtom]

Antman,
Is Roadkil's Unstoppable Copier what you use?
If you do, I figure it's worth trying (that's a compliment).
Tom

 

[Antman]

Kind words, indeed.

Actually, I use RoadKil UC during a system recovery only. It is my shotgun for grabbing files off of a failing HDD or failed/failing OS install.

I know there are more elegant methods, but I am all about time on task.

Here, I am probing The Acidic One for in-depth knowledge. When his cookies crumble, the floor gains IQ.

 

[rsvr85]

These utilities are all just front-ends for one or the other of the in-built file copy mechanisms. Every scenario calls for a particular range of attributes:

- Is it multi-threaded? Multiple concurrent copy operations are A Good Thing.
- What's the "chunk" size? Different sizes produce different effects. Bigger is not always better.
- How granular is the control over what to copy?
- Logging? How verbose?
- Scriptable? Easily?
- Robust - can it recover from unanticipated transients or at least report them?
... and so on.

None of these utilities implement some magically new method, but the multi-threaded ones (robocopy, richcopy) will have the performance edge, everything else being equal. Robocopy is highly configurable and scriptable. Richcopy is simpler and easier to use.

Cut'n'paste is the one method which should be avoided for massive transfers. It relies on the clipboard and that introduces extra complexity which cannot hope to match the throughput of the other mechanisms. The copy/xcopy commands are somewhere in between - devoid of the shell "chattiness" overhead inherent in drag'n'drop and cut'n'paste, but single-threaded and therefore not as fast in many cases.

For outright speed: ROBOCOPY <source> <dest> *.* /E /MT:8

It seems clear that robocopy is your favourite for this one. I knew that cut'n'paste should be avoided (i've got stung before!)
All i need, is to move 160GB of data (including empty folders) from my internal drive to my external drive as quickly and reliably as possible with errors/missed files/failures being reported along the way or at the end. It's no problem for the move to consume my entire PC for the duration either.

Bob, correct me here if Im wrong, but TAR isnt a windows file ... its Linux...

I don't think you're wrong , i've been having a bit of a fling with Ubuntu Karmic recently and i've come across alot of TAR files. I've never seen them in a Windows environment before.

 

[ja3hawk]

Bob, correct me here if Im wrong, but TAR isnt a windows file ... its Linux...

I think you can open tar files if you have winrar or 7zip. They're multi-platform I believe.

 

[H2SO4]

I am interested in your analysis of Roadkil's Unstoppable Copier.

I've never used it, so please keep that in mind when gauging the value of my opinion

From looking at the description and screenshots on the Roadkil website, I think the utility's primary trick is to ignore or bypass the NTFS "bad cluster" designation, and then presumably do some statistical analysis of a given cluster's contents. Say we read a byte 10 times. The results are 7 times 'A', two 'H's, and a lone 'X'. We'll conclude the most likely original datum was an 'A' and cross our fingers. The value of such a recovery will depend on the data type's tolerance for anomalies, and admirably he points that out in the tool's description.

I'm curious about the mechanism used to bypass the NTFS $BadClus metadata. It's doable with a driver, but that would imply a degree of sophistication greater than many of the other utilities on the site. Perhaps there are user-mode APIs to query that info without a driver? I don't know.

Either way, the tool's recovery abilities are presumably dependent on first running a full CHKDSK /R so that bad sectors are identified and tagged (in $BadClus). Otherwise, there'd be no way to tell good sectors from bad short of first duplicating CHKDSK sector verification code (which is not conceptually complex), or subjecting every single cluster to the same statistical results analysis - a prohibitively time-consuming strategy which could take many days on large volumes.

===============================

The dropdown list of minor European languages blankets most of the "Settings" tab screenshot, but there seems to be no overt mention of multi-threadedness or other copy throughput enhancements; emphasis seems placed squarely on the recovery aspect of the utility. Hence, my guess is that it wouldn't compete favourably with tools built for speed, and it may not be the best solution in the OP's scenario.

 

[H2SO4]

I don't think you're wrong , i've been having a bit of a fling with Ubuntu Karmic recently and i've come across alot of TAR files. I've never seen them in a Windows environment before.

Without in any way wishing to play down others' suggestions, I don't believe file compression or "cabification" is going to make any difference in your scenario (two local drives). In fact, it would take (far) longer to first compress 160GB into a tight ball, then copy, then decompress on the target drive. That strategy is valid under certain circumstances - very slow network links for example - but the "bandwidth" of the underlying hardware between the source and destination is not the primary bottleneck in this instance. Instead, what's important is the way your chosen copy tool breaks up data into segments and invokes OS functionality to copy it across.

 

[ultraplanet]

Strollin is right USB2 or Firewire 400 is the weakest link for sure. Any copy method you choose can keep them saturated.

 

[ja3hawk]

Without in any way wishing to play down others' suggestions, I don't believe file compression or "cabification" is going to make any difference in your scenario (two local drives). In fact, it would take (far) longer to first compress 160GB into a tight ball, then copy, then decompress on the target drive. That strategy is valid under certain circumstances - very slow network links for example - but the "bandwidth" of the underlying hardware between the source and destination is not the primary bottleneck in this instance. Instead, what's important is the way your chosen copy tool breaks up data into segments and invokes OS functionality to copy it across.

I agree, avoid compression. It will take long to compress and uncompress than it would to just move them.

 

[Antman]

I am interested in your analysis of Roadkil's Unstoppable Copier.

I've never used it, so please keep that in mind when gauging the value of my opinion ...it may not be the best solution in the OP's scenario.

All that and a bag of chips. It can be a bit time consuming to run. I use it even in situations where I do not expect disc damage. Like other utils, it does not stop when it encounters a locked file.

I have to admit - it is a tool I have been using for years, and since it has never failed me (to my knowledge), I just keep using it.

I have to give you some props - I learn something every time you click submit.