Recovering broken USB drive: ddrescue disk to disk vs disk to image?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I am a bit confused about few things and I hope someone could clear this up for me. Is there any particular difference in disk to disk vs disk to image file approach?
I executed following code to recover my dying 2TB USB drive:
ddrescue --force --no-split /dev/sdc1 /dev/sdd1 ~/ddrescue.log
I thought it will make an image file on sdd1 (4TB USB), but instead it now seems to have full copy of entire filesystem, automatically mounted by Ubuntu. I now understand that I maybe should have done /dev/sdd1/image.img
instead.
Do I understand correctly, that now, because I did disk to disk instead of disk to image, I do not need to do anything any more and I can safely start using data on new disk?
If so, what is the benefit of doing disk to image?. It seems to me that disk to disk is faster and easier because I now do not have to deal with extracting the image file. I understand the need of image file when one needs to split data to different smaller drives, but in case you have at least same size spare drive?
Extra question: I now seemingly have exact copy of broken drive automatically mounted and working. Because, I ran ddrescue only once without copying any error blocks there has to be some data, it could not recover (it can be free space?). How do I know which data was not recovered? Everything seems to be there.
data-recovery disk-image ddrescue
add a comment |Â
up vote
2
down vote
favorite
I am a bit confused about few things and I hope someone could clear this up for me. Is there any particular difference in disk to disk vs disk to image file approach?
I executed following code to recover my dying 2TB USB drive:
ddrescue --force --no-split /dev/sdc1 /dev/sdd1 ~/ddrescue.log
I thought it will make an image file on sdd1 (4TB USB), but instead it now seems to have full copy of entire filesystem, automatically mounted by Ubuntu. I now understand that I maybe should have done /dev/sdd1/image.img
instead.
Do I understand correctly, that now, because I did disk to disk instead of disk to image, I do not need to do anything any more and I can safely start using data on new disk?
If so, what is the benefit of doing disk to image?. It seems to me that disk to disk is faster and easier because I now do not have to deal with extracting the image file. I understand the need of image file when one needs to split data to different smaller drives, but in case you have at least same size spare drive?
Extra question: I now seemingly have exact copy of broken drive automatically mounted and working. Because, I ran ddrescue only once without copying any error blocks there has to be some data, it could not recover (it can be free space?). How do I know which data was not recovered? Everything seems to be there.
data-recovery disk-image ddrescue
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am a bit confused about few things and I hope someone could clear this up for me. Is there any particular difference in disk to disk vs disk to image file approach?
I executed following code to recover my dying 2TB USB drive:
ddrescue --force --no-split /dev/sdc1 /dev/sdd1 ~/ddrescue.log
I thought it will make an image file on sdd1 (4TB USB), but instead it now seems to have full copy of entire filesystem, automatically mounted by Ubuntu. I now understand that I maybe should have done /dev/sdd1/image.img
instead.
Do I understand correctly, that now, because I did disk to disk instead of disk to image, I do not need to do anything any more and I can safely start using data on new disk?
If so, what is the benefit of doing disk to image?. It seems to me that disk to disk is faster and easier because I now do not have to deal with extracting the image file. I understand the need of image file when one needs to split data to different smaller drives, but in case you have at least same size spare drive?
Extra question: I now seemingly have exact copy of broken drive automatically mounted and working. Because, I ran ddrescue only once without copying any error blocks there has to be some data, it could not recover (it can be free space?). How do I know which data was not recovered? Everything seems to be there.
data-recovery disk-image ddrescue
I am a bit confused about few things and I hope someone could clear this up for me. Is there any particular difference in disk to disk vs disk to image file approach?
I executed following code to recover my dying 2TB USB drive:
ddrescue --force --no-split /dev/sdc1 /dev/sdd1 ~/ddrescue.log
I thought it will make an image file on sdd1 (4TB USB), but instead it now seems to have full copy of entire filesystem, automatically mounted by Ubuntu. I now understand that I maybe should have done /dev/sdd1/image.img
instead.
Do I understand correctly, that now, because I did disk to disk instead of disk to image, I do not need to do anything any more and I can safely start using data on new disk?
If so, what is the benefit of doing disk to image?. It seems to me that disk to disk is faster and easier because I now do not have to deal with extracting the image file. I understand the need of image file when one needs to split data to different smaller drives, but in case you have at least same size spare drive?
Extra question: I now seemingly have exact copy of broken drive automatically mounted and working. Because, I ran ddrescue only once without copying any error blocks there has to be some data, it could not recover (it can be free space?). How do I know which data was not recovered? Everything seems to be there.
data-recovery disk-image ddrescue
data-recovery disk-image ddrescue
edited 8 mins ago
Rui F Ribeiro
37.3k1374118
37.3k1374118
asked Apr 13 '15 at 16:59
ruuter
1156
1156
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive.
As for going directly between sdc1
to sdd1
, I've always been reluctant when it comes to copying directly from and to a partition, as opposed to the entire filesystem. What if the partition table on sdd
does not match what's on sdc
?
Identifying broken data is a tedious process. The log file should give you a clue as to what didn't transfer over[2]. In addition, there is the obvious method of checking individual files, in particular the large files, such as any video you might have, as they might start glitch when the keyframes go missing.
Note 1: By always, I mean provided that it's a rescue operation. If it's just a normal disk dump of a fully functioning system, I might do it disk to disk.
Note 2: It is worth mentioning that while the first pass to copy the sector is most likely the only result you're gonna get, ddrescue supports reading the logfile to see which sectors failed copy, and give those another go. Refer to the manpage for details. This helped me once when the limp part of the filesystem seemed to move around.
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
1
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive.
As for going directly between sdc1
to sdd1
, I've always been reluctant when it comes to copying directly from and to a partition, as opposed to the entire filesystem. What if the partition table on sdd
does not match what's on sdc
?
Identifying broken data is a tedious process. The log file should give you a clue as to what didn't transfer over[2]. In addition, there is the obvious method of checking individual files, in particular the large files, such as any video you might have, as they might start glitch when the keyframes go missing.
Note 1: By always, I mean provided that it's a rescue operation. If it's just a normal disk dump of a fully functioning system, I might do it disk to disk.
Note 2: It is worth mentioning that while the first pass to copy the sector is most likely the only result you're gonna get, ddrescue supports reading the logfile to see which sectors failed copy, and give those another go. Refer to the manpage for details. This helped me once when the limp part of the filesystem seemed to move around.
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
1
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
add a comment |Â
up vote
2
down vote
accepted
The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive.
As for going directly between sdc1
to sdd1
, I've always been reluctant when it comes to copying directly from and to a partition, as opposed to the entire filesystem. What if the partition table on sdd
does not match what's on sdc
?
Identifying broken data is a tedious process. The log file should give you a clue as to what didn't transfer over[2]. In addition, there is the obvious method of checking individual files, in particular the large files, such as any video you might have, as they might start glitch when the keyframes go missing.
Note 1: By always, I mean provided that it's a rescue operation. If it's just a normal disk dump of a fully functioning system, I might do it disk to disk.
Note 2: It is worth mentioning that while the first pass to copy the sector is most likely the only result you're gonna get, ddrescue supports reading the logfile to see which sectors failed copy, and give those another go. Refer to the manpage for details. This helped me once when the limp part of the filesystem seemed to move around.
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
1
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive.
As for going directly between sdc1
to sdd1
, I've always been reluctant when it comes to copying directly from and to a partition, as opposed to the entire filesystem. What if the partition table on sdd
does not match what's on sdc
?
Identifying broken data is a tedious process. The log file should give you a clue as to what didn't transfer over[2]. In addition, there is the obvious method of checking individual files, in particular the large files, such as any video you might have, as they might start glitch when the keyframes go missing.
Note 1: By always, I mean provided that it's a rescue operation. If it's just a normal disk dump of a fully functioning system, I might do it disk to disk.
Note 2: It is worth mentioning that while the first pass to copy the sector is most likely the only result you're gonna get, ddrescue supports reading the logfile to see which sectors failed copy, and give those another go. Refer to the manpage for details. This helped me once when the limp part of the filesystem seemed to move around.
The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive.
As for going directly between sdc1
to sdd1
, I've always been reluctant when it comes to copying directly from and to a partition, as opposed to the entire filesystem. What if the partition table on sdd
does not match what's on sdc
?
Identifying broken data is a tedious process. The log file should give you a clue as to what didn't transfer over[2]. In addition, there is the obvious method of checking individual files, in particular the large files, such as any video you might have, as they might start glitch when the keyframes go missing.
Note 1: By always, I mean provided that it's a rescue operation. If it's just a normal disk dump of a fully functioning system, I might do it disk to disk.
Note 2: It is worth mentioning that while the first pass to copy the sector is most likely the only result you're gonna get, ddrescue supports reading the logfile to see which sectors failed copy, and give those another go. Refer to the manpage for details. This helped me once when the limp part of the filesystem seemed to move around.
answered Apr 13 '15 at 18:48
Jarmund
1601310
1601310
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
1
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
add a comment |Â
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
1
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
â ruuter
Apr 13 '15 at 19:55
1
1
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
â Jarmund
Apr 13 '15 at 20:22
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f195996%2frecovering-broken-usb-drive-ddrescue-disk-to-disk-vs-disk-to-image%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password