Recovering broken USB drive: ddrescue disk to disk vs disk to image?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite
1












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.










share|improve this question



























    up vote
    2
    down vote

    favorite
    1












    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.










    share|improve this question

























      up vote
      2
      down vote

      favorite
      1









      up vote
      2
      down vote

      favorite
      1






      1





      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.










      share|improve this question















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 8 mins ago









      Rui F Ribeiro

      37.3k1374118




      37.3k1374118










      asked Apr 13 '15 at 16:59









      ruuter

      1156




      1156




















          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.






          share|improve this answer




















          • 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










          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          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






























          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.






          share|improve this answer




















          • 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














          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.






          share|improve this answer




















          • 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












          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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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
















          • 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

















           

          draft saved


          draft discarded















































           


          draft saved


          draft discarded














          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













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay