If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Transferring all data from a suspect HDD.
I've bought a new 4000GB Seagate HDD to hold
2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? |
Ads |
#2
|
|||
|
|||
Transferring all data from a suspect HDD.
In article , Peter Jason
wrote: I've bought a new 4000GB Seagate HDD to hold 2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? it sounds like you're using usb 2 hi speed, which is very slow and would take around a day or so to copy it, quite possibly longer if there are a lot of small files versus fewer larger ones. with usb 3 superspeed, it should take several hours. let it run overnight and it should be done by morning. |
#3
|
|||
|
|||
Transferring all data from a suspect HDD.
On Thu, 17 Jan 2019 17:43:07 -0500, nospam
wrote: In article , Peter Jason wrote: I've bought a new 4000GB Seagate HDD to hold 2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? it sounds like you're using usb 2 hi speed, which is very slow and would take around a day or so to copy it, quite possibly longer if there are a lot of small files versus fewer larger ones. with usb 3 superspeed, it should take several hours. let it run overnight and it should be done by morning. Thanks, I'll make sure both disks are connected directly to the MBoard. |
#4
|
|||
|
|||
Transferring all data from a suspect HDD.
In article , Peter Jason
wrote: I've bought a new 4000GB Seagate HDD to hold 2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? it sounds like you're using usb 2 hi speed, which is very slow and would take around a day or so to copy it, quite possibly longer if there are a lot of small files versus fewer larger ones. with usb 3 superspeed, it should take several hours. let it run overnight and it should be done by morning. Thanks, I'll make sure both disks are connected directly to the MBoard. just be sure everything is usb 3. |
#5
|
|||
|
|||
Transferring all data from a suspect HDD.
Peter Jason wrote:
On Thu, 17 Jan 2019 17:43:07 -0500, nospam wrote: In article , Peter Jason wrote: I've bought a new 4000GB Seagate HDD to hold 2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? it sounds like you're using usb 2 hi speed, which is very slow and would take around a day or so to copy it, quite possibly longer if there are a lot of small files versus fewer larger ones. with usb 3 superspeed, it should take several hours. let it run overnight and it should be done by morning. Thanks, I'll make sure both disks are connected directly to the MBoard. If there is any bad news, you'll get the bad news faster that way (with SATA ports). Personally, I would "Macrium Clone" while they're both on SATA ports, because the access is sequential rather than random. Data is transferred in cluster order most of the time. If you "resize" partitions while cloning, all bets are off (you'll hear rattling). Regular drag and drop copy, if the source files are fragmented, you'll likely hear rattling on the (sick) source drive. If you use Robocopy, at least that keeps a log. Robocopy is now native to the OS and no longer needs to be downloaded. It is a folder to folder copy program. Here, the folders are entire hard drives. Note - this command *erases* the destination - do NOT use this command if data already exists on the destination drive. This command is also missing the options needed to (attempt) to copy a C: drive. I assume the drive in question is a data drive when you asked this question, and this command is *only* for data drive to data drive copying. I'm missing the option to step over Junction Points on this one. (Administrator Command Prompt window, to be able to copy everything) cd /d %userprofile%\Downloads === log will go here robocopy L:\ F:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:robocopy_l_to_f.log So what you do there, is make the "new" disk GPT in the Disk Management when it asks. Then, make a new partition out of the entire drive. Let's call that F: as in the example. Then you can copy the contents of L: to F: with Robocopy. (Change the drive letters to reflect your own setup.) Robocopy pipelines the transfer and can read and write the drives at the same time. Rather than alternating back and forth between the separate drives like some other copying methods might. You have many ways to copy the data. "ddrescue" is reserved for cases where the source drive is damaged and the damn transfer stops each time. If you have CRC errors on the drive, expect some hair loss. HTH, Paul |
#6
|
|||
|
|||
Transferring all data from a suspect HDD.
On 1/17/2019 5:12 PM, Peter Jason wrote:
I've bought a new 4000GB Seagate HDD to hold 2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? While all of the suggestions are good, you may consider putting the old disk in a USB enclosure and transfer the data at your leisure. I assume you have a back up of the old disk. Doing it leisurely will give you an chance to sort out duplicate files, and rework the organization of your disk. For me as hard as I try to keep things organized, I periodically have to rework a folder. Breaking up folder to more accurately reflect what I have in a folder. Moving files that were accidentally misfiled. Remove duplicate files after ensuring that they are actually duplicate, or if they are not duplicate renaming them and ensuring they are in the proper folder. -- 2018: The year we learn to play the great game of Euchre |
#7
|
|||
|
|||
Transferring all data from a suspect HDD.
On Thu, 17 Jan 2019 19:09:41 -0500, Keith Nuttle wrote:
you may consider putting the old disk in a USB enclosure One caveat with USB .... I never understood when it mattered for sure, and when it was just a "good idea" or an "extra precaution", but, make sure, whatever you do, that the power doesn't go out or you pull the USB cord before a formal unmount process. USB, for whatever reason, at least historically, needs an engraved invitation to be disconnected from the PC - or it can throw a fit you don't want (ask me how I know). NOTE: This is just a warning - if you use USB "properly", you shouldn't need this warning - but I don't understand USB well - so I have been screwed by my ignorance. |
#8
|
|||
|
|||
Transferring all data from a suspect HDD.
arlen holder wrote:
On Thu, 17 Jan 2019 19:09:41 -0500, Keith Nuttle wrote: you may consider putting the old disk in a USB enclosure One caveat with USB .... I never understood when it mattered for sure, and when it was just a "good idea" or an "extra precaution", but, make sure, whatever you do, that the power doesn't go out or you pull the USB cord before a formal unmount process. USB, for whatever reason, at least historically, needs an engraved invitation to be disconnected from the PC - or it can throw a fit you don't want (ask me how I know). NOTE: This is just a warning - if you use USB "properly", you shouldn't need this warning - but I don't understand USB well - so I have been screwed by my ignorance. The Uwe Sieber site has information on which file systems and setups support caching. https://www.uwe-sieber.de/usbstick_e.html It's when file system operations are outstanding, and you pull the plug, that corruption of the last operations can occur. Using a "safely remove" does a flush() that transfers outstanding write operations to storage. Once the cache is flushed, you can pull the plug. A number of file systems (NTFS and EXT4 for example), are journaled, and even if you pull the plug, at next mount, the corrupted or half-finished transactions can be removed. And that leaves the vast majority of the store intact. If you've managed to disable write caching, then all operations should go immediately to disk, increasing the chances that if the LED has stopped flashing, pulling out the cord will not damage anything. We manage to use floppies in Windows without too much trouble. We don't dismount them. There's no cache that's visible. We wait until the LED stops flashing (or we happen to know no write operations have been done), and can pop out the floppy when the thing is quiet. Other operating systems keep trays or drawers locked to prevent random removal, as another way to enforce good practices. In Unix, issuing several sync() commands would cause flushing of content to actual storage, in an attempt to eliminate damage that could happen soon after that. https://linux.die.net/man/2/sync "sync() causes all buffered modifications to file metadata and data to be written to the underlying file systems." It's when a stack has no buffering, that treatment can be simplified (no need to sync() or flush() ). But with no buffering, there is also poorer performance. Paul |
#9
|
|||
|
|||
Transferring all data from a suspect HDD.
On Fri, 18 Jan 2019 03:13:05 -0500, Paul wrote:
It's when file system operations are outstanding, and you pull the plug, that corruption of the last operations can occur. Hi Paul, Thanks for that information - which - will help everyone who cares. I don't doubt anything you say - as - I have been burned empirically. It's actually embarrassing to admit, but - in the past - about in the days of 100GB and 500GB USB drives being "all the rage", I've "corrupted" entire USB drives more than once - where - while I don't doubt what you say - it isn't always that simple. It "might" be that simple - but - I was "sure" I waited for file transfers to end, and _still_, entire USB drives lost their minds on me. When I "recovered" the data, it was flat (i.e., no folder hierarchy) and all the files lost their first letter, where, for example, if the file name was "foo.txt", it turned into "oo.txt" (as I recall) or maybe "Xoo.txt" (I don't remember - I just remember the first character was gone). Using a "safely remove" does a flush() that transfers outstanding write operations to storage. Once the cache is flushed, you can pull the plug. Yup. That's my point to the OP. If the OP opts for a USB drive, particularly on large file xfers, then a "safe" return to earth is something the OP _must_ be cognizant of. A number of file systems (NTFS and EXT4 for example), are journaled, and even if you pull the plug, at next mount, the corrupted or half-finished transactions can be removed. And that leaves the vast majority of the store intact. This is a good point, where, for example, the power reliability here in the environs of the Silicon Valley is worse than that in equatorial Africa (e.g., we lost power for 18 hours yesterday in a windstorm where we lose power about once a month). We _all_ have our own power generation units, but that doesn't stop the PCs from rebooting (yes, I know, there are ways to ameliorate that). The main point was to the OP to beware of USB drives - that's all. If you've managed to disable write caching, then all operations should go immediately to disk, increasing the chances that if the LED has stopped flashing, pulling out the cord will not damage anything. Nice to know. Me? I avoid USB file transfers like I avoid the plague. That solves my problem (as my internal disks are large enough). We manage to use floppies in Windows without too much trouble. We don't dismount them. There's no cache that's visible. We wait until the LED stops flashing (or we happen to know no write operations have been done), and can pop out the floppy when the thing is quiet. Other operating systems keep trays or drawers locked to prevent random removal, as another way to enforce good practices. This is a good point that, atavistically, the problem has existed. In Unix, issuing several sync() commands would cause flushing of content to actual storage, in an attempt to eliminate damage that could happen soon after that. Oooooh. I remember some of those. I do. I do. It seemed crazy to do the same thing twice (literally); but I remember (way back when) Paul ... you bring back memories ... of days long gone by (I hope)... |
#10
|
|||
|
|||
Transferring all data from a suspect HDD.
On 18/01/2019 19.27, arlen holder wrote:
On Fri, 18 Jan 2019 03:13:05 -0500, Paul wrote: It's when file system operations are outstanding, and you pull the plug, that corruption of the last operations can occur. Hi Paul, Thanks for that information - which - will help everyone who cares. I don't doubt anything you say - as - I have been burned empirically. It's actually embarrassing to admit, but - in the past - about in the days of 100GB and 500GB USB drives being "all the rage", I've "corrupted" entire USB drives more than once - where - while I don't doubt what you say - it isn't always that simple. It "might" be that simple - but - I was "sure" I waited for file transfers to end, and _still_, entire USB drives lost their minds on me. I only damaged one. Then I was more careful. :-p When I "recovered" the data, it was flat (i.e., no folder hierarchy) and all the files lost their first letter, where, for example, if the file name was "foo.txt", it turned into "oo.txt" (as I recall) or maybe "Xoo.txt" (I don't remember - I just remember the first character was gone). FAT marks deleted files by replacing the first character of the name with a certain character, that is otherwise forbidden on file names. I don't remember which - google says it is 0xE5. Part of the procedure when undeleting was to guess what the first char on the name of the files would be. Then somebody invented software that would make a backup. -- Cheers, Carlos. |
#11
|
|||
|
|||
Transferring all data from a suspect HDD.
On Thu, 17 Jan 2019 18:48:27 -0500, Paul
wrote: Peter Jason wrote: On Thu, 17 Jan 2019 17:43:07 -0500, nospam wrote: In article , Peter Jason wrote: I've bought a new 4000GB Seagate HDD to hold 2500GB of data from an old 4000GB suspect one. To copy over all the data will take ages. Is there a faster way? it sounds like you're using usb 2 hi speed, which is very slow and would take around a day or so to copy it, quite possibly longer if there are a lot of small files versus fewer larger ones. with usb 3 superspeed, it should take several hours. let it run overnight and it should be done by morning. Thanks, I'll make sure both disks are connected directly to the MBoard. If there is any bad news, you'll get the bad news faster that way (with SATA ports). Personally, I would "Macrium Clone" while they're both on SATA ports, because the access is sequential rather than random. Data is transferred in cluster order most of the time. If you "resize" partitions while cloning, all bets are off (you'll hear rattling). Regular drag and drop copy, if the source files are fragmented, you'll likely hear rattling on the (sick) source drive. If you use Robocopy, at least that keeps a log. Robocopy is now native to the OS and no longer needs to be downloaded. It is a folder to folder copy program. Here, the folders are entire hard drives. Note - this command *erases* the destination - do NOT use this command if data already exists on the destination drive. This command is also missing the options needed to (attempt) to copy a C: drive. I assume the drive in question is a data drive when you asked this question, and this command is *only* for data drive to data drive copying. I'm missing the option to step over Junction Points on this one. (Administrator Command Prompt window, to be able to copy everything) cd /d %userprofile%\Downloads === log will go here robocopy L:\ F:\ /mir /copy:datso /dcopy:t /r:3 /w:2 /zb /np /tee /v /log:robocopy_l_to_f.log So what you do there, is make the "new" disk GPT in the Disk Management when it asks. Then, make a new partition out of the entire drive. Let's call that F: as in the example. Then you can copy the contents of L: to F: with Robocopy. (Change the drive letters to reflect your own setup.) Robocopy pipelines the transfer and can read and write the drives at the same time. Rather than alternating back and forth between the separate drives like some other copying methods might. You have many ways to copy the data. "ddrescue" is reserved for cases where the source drive is damaged and the damn transfer stops each time. If you have CRC errors on the drive, expect some hair loss. HTH, Paul I notice the errant HDD is not recognized by Macrium 7, so I can't try to clone it. |
#12
|
|||
|
|||
Transferring all data from a suspect HDD.
In article , Peter Jason
wrote: I notice the errant HDD is not recognized by Macrium 7, so I can't try to clone it. can it be seen otherwise? |
#13
|
|||
|
|||
Transferring all data from a suspect HDD.
On Fri, 18 Jan 2019 16:39:21 -0500, nospam
wrote: In article , Peter Jason wrote: I notice the errant HDD is not recognized by Macrium 7, so I can't try to clone it. can it be seen otherwise? Yes, in Disk Management & File Explorer. So I'll buy the new disk & start transferring this very day. |
#14
|
|||
|
|||
Transferring all data from a suspect HDD.
Peter Jason wrote:
On Fri, 18 Jan 2019 16:39:21 -0500, nospam wrote: In article , Peter Jason wrote: I notice the errant HDD is not recognized by Macrium 7, so I can't try to clone it. can it be seen otherwise? Yes, in Disk Management & File Explorer. So I'll buy the new disk & start transferring this very day. Do you have any info on the drive ? https://i.postimg.cc/fbFckGnG/some-disk-info.gif Even that little bit doesn't tell us very much. Some of the utilities I'd like to use, are too hard to get (Cygwin "disktype.exe" being an example). There has got to be some reason Macrium cannot see it. Paul |
#15
|
|||
|
|||
Transferring all data from a suspect HDD.
On Fri, 18 Jan 2019 17:33:38 -0500, Paul
wrote: Peter Jason wrote: On Fri, 18 Jan 2019 16:39:21 -0500, nospam wrote: In article , Peter Jason wrote: I notice the errant HDD is not recognized by Macrium 7, so I can't try to clone it. can it be seen otherwise? Yes, in Disk Management & File Explorer. So I'll buy the new disk & start transferring this very day. Do you have any info on the drive ? https://i.postimg.cc/fbFckGnG/some-disk-info.gif Even that little bit doesn't tell us very much. Some of the utilities I'd like to use, are too hard to get (Cygwin "disktype.exe" being an example). There has got to be some reason Macrium cannot see it. Paul Thank you; I've shunted into panic mode (steels the resolve) and connected a new 4TB HDD and the data is being transferred as I type this. The speed is woeful at between 6 & 50MB/sec. I'll check things as soon as the contents have been copied across. |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|