ddrescue is taking ages
OK, so my hard disk crashed the other day and I sent the entire notebook for servicing; now I have a brand new hard disk installed in it and the damaged one out in the open. I've installed Ubuntu and ddrescue with the intention of recovering all data from the C drive (200GB); so far it's been about 2 hours and I think it's going to be a very long time.
I ran the following line:
sudo dd_rescue /dev/sdb2 /mnt/sda4/backup.img
Things started looking good; it expected to retrieve 195354624kB from /dev/sdb2
and started copying stuff; however it's copying in chunks of 2119808kB with avg.rate
of just above 400kB/s and an ETA of almost 130:00:00. I have to wait 5 days just to get all my data out?!
This webpage says that he took just 12+h to do 1TB, but given that my hard disk is damaged I should expect the time taken to be longer. Should I be optimistic and pray that it'd take less than 5 days? Currently the state of the hard disk is so bad that I can't view any of the files in Windows, the C drive says it's corrupted and unreadable, and the D drive hangs up the system when navigating through the files, and eventually disconnects each and every single time.
Is there any way to expedite ddrescue (while preserving as much data as possible), or am I doing something wrong?
hard-drive data-recovery dd
add a comment |
OK, so my hard disk crashed the other day and I sent the entire notebook for servicing; now I have a brand new hard disk installed in it and the damaged one out in the open. I've installed Ubuntu and ddrescue with the intention of recovering all data from the C drive (200GB); so far it's been about 2 hours and I think it's going to be a very long time.
I ran the following line:
sudo dd_rescue /dev/sdb2 /mnt/sda4/backup.img
Things started looking good; it expected to retrieve 195354624kB from /dev/sdb2
and started copying stuff; however it's copying in chunks of 2119808kB with avg.rate
of just above 400kB/s and an ETA of almost 130:00:00. I have to wait 5 days just to get all my data out?!
This webpage says that he took just 12+h to do 1TB, but given that my hard disk is damaged I should expect the time taken to be longer. Should I be optimistic and pray that it'd take less than 5 days? Currently the state of the hard disk is so bad that I can't view any of the files in Windows, the C drive says it's corrupted and unreadable, and the D drive hangs up the system when navigating through the files, and eventually disconnects each and every single time.
Is there any way to expedite ddrescue (while preserving as much data as possible), or am I doing something wrong?
hard-drive data-recovery dd
add a comment |
OK, so my hard disk crashed the other day and I sent the entire notebook for servicing; now I have a brand new hard disk installed in it and the damaged one out in the open. I've installed Ubuntu and ddrescue with the intention of recovering all data from the C drive (200GB); so far it's been about 2 hours and I think it's going to be a very long time.
I ran the following line:
sudo dd_rescue /dev/sdb2 /mnt/sda4/backup.img
Things started looking good; it expected to retrieve 195354624kB from /dev/sdb2
and started copying stuff; however it's copying in chunks of 2119808kB with avg.rate
of just above 400kB/s and an ETA of almost 130:00:00. I have to wait 5 days just to get all my data out?!
This webpage says that he took just 12+h to do 1TB, but given that my hard disk is damaged I should expect the time taken to be longer. Should I be optimistic and pray that it'd take less than 5 days? Currently the state of the hard disk is so bad that I can't view any of the files in Windows, the C drive says it's corrupted and unreadable, and the D drive hangs up the system when navigating through the files, and eventually disconnects each and every single time.
Is there any way to expedite ddrescue (while preserving as much data as possible), or am I doing something wrong?
hard-drive data-recovery dd
OK, so my hard disk crashed the other day and I sent the entire notebook for servicing; now I have a brand new hard disk installed in it and the damaged one out in the open. I've installed Ubuntu and ddrescue with the intention of recovering all data from the C drive (200GB); so far it's been about 2 hours and I think it's going to be a very long time.
I ran the following line:
sudo dd_rescue /dev/sdb2 /mnt/sda4/backup.img
Things started looking good; it expected to retrieve 195354624kB from /dev/sdb2
and started copying stuff; however it's copying in chunks of 2119808kB with avg.rate
of just above 400kB/s and an ETA of almost 130:00:00. I have to wait 5 days just to get all my data out?!
This webpage says that he took just 12+h to do 1TB, but given that my hard disk is damaged I should expect the time taken to be longer. Should I be optimistic and pray that it'd take less than 5 days? Currently the state of the hard disk is so bad that I can't view any of the files in Windows, the C drive says it's corrupted and unreadable, and the D drive hangs up the system when navigating through the files, and eventually disconnects each and every single time.
Is there any way to expedite ddrescue (while preserving as much data as possible), or am I doing something wrong?
hard-drive data-recovery dd
hard-drive data-recovery dd
asked Aug 24 '13 at 8:24
mattmatt
10614
10614
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
If you use ddrescue
command from gddrescue
package (it's not clear), then to speed up the process (and ensure your drive doesn't die too quickly!) you can use a log file:
sudo ddrescue /dev/sdb2 /mnt/sda4/backup.img logfile
After a couple of ours (or a day) of copying, you can stop ddrescue
, let your drive rest (or put it in a colder room or storage), and when it's cooled down you can resume the process where it left off using the same command as above. Since the hard-drive will have time to breath, it will improve operational performance and might speed up the process. It is recommended to do that if the drive is dying.
add a comment |
What is the file system of the hard disk where you save the rescue image and the logfile? I just made the experience of rescuing a 500GB internal hard drive (connected via SATA) on a Laptop running Linux Mint from a USB Stick, saving the rescue image and logfile on an exFat
formatted USB hard drive.
It starting rather slowly (1-2MB/sec) but after around 250GB it was only crawling at <100KB/sec. It seemed to become slower the larger the rescue image file was growing.
Then I moved the rescue image and logfile to another temporary place, re-formatted the USB hard drive with the ext4
file system, moved the files back on it and resumed the ddrescue
process - and now it runs with 1-20MB/sec again (fluctuating but around 7MB/sec on average)!
Seems like exFat
does not play very well with very large files (several hundred gigabytes), so you might want to give ext4
a shot.
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f336559%2fddrescue-is-taking-ages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If you use ddrescue
command from gddrescue
package (it's not clear), then to speed up the process (and ensure your drive doesn't die too quickly!) you can use a log file:
sudo ddrescue /dev/sdb2 /mnt/sda4/backup.img logfile
After a couple of ours (or a day) of copying, you can stop ddrescue
, let your drive rest (or put it in a colder room or storage), and when it's cooled down you can resume the process where it left off using the same command as above. Since the hard-drive will have time to breath, it will improve operational performance and might speed up the process. It is recommended to do that if the drive is dying.
add a comment |
If you use ddrescue
command from gddrescue
package (it's not clear), then to speed up the process (and ensure your drive doesn't die too quickly!) you can use a log file:
sudo ddrescue /dev/sdb2 /mnt/sda4/backup.img logfile
After a couple of ours (or a day) of copying, you can stop ddrescue
, let your drive rest (or put it in a colder room or storage), and when it's cooled down you can resume the process where it left off using the same command as above. Since the hard-drive will have time to breath, it will improve operational performance and might speed up the process. It is recommended to do that if the drive is dying.
add a comment |
If you use ddrescue
command from gddrescue
package (it's not clear), then to speed up the process (and ensure your drive doesn't die too quickly!) you can use a log file:
sudo ddrescue /dev/sdb2 /mnt/sda4/backup.img logfile
After a couple of ours (or a day) of copying, you can stop ddrescue
, let your drive rest (or put it in a colder room or storage), and when it's cooled down you can resume the process where it left off using the same command as above. Since the hard-drive will have time to breath, it will improve operational performance and might speed up the process. It is recommended to do that if the drive is dying.
If you use ddrescue
command from gddrescue
package (it's not clear), then to speed up the process (and ensure your drive doesn't die too quickly!) you can use a log file:
sudo ddrescue /dev/sdb2 /mnt/sda4/backup.img logfile
After a couple of ours (or a day) of copying, you can stop ddrescue
, let your drive rest (or put it in a colder room or storage), and when it's cooled down you can resume the process where it left off using the same command as above. Since the hard-drive will have time to breath, it will improve operational performance and might speed up the process. It is recommended to do that if the drive is dying.
answered Feb 3 '14 at 17:24
landronilandroni
4,29462249
4,29462249
add a comment |
add a comment |
What is the file system of the hard disk where you save the rescue image and the logfile? I just made the experience of rescuing a 500GB internal hard drive (connected via SATA) on a Laptop running Linux Mint from a USB Stick, saving the rescue image and logfile on an exFat
formatted USB hard drive.
It starting rather slowly (1-2MB/sec) but after around 250GB it was only crawling at <100KB/sec. It seemed to become slower the larger the rescue image file was growing.
Then I moved the rescue image and logfile to another temporary place, re-formatted the USB hard drive with the ext4
file system, moved the files back on it and resumed the ddrescue
process - and now it runs with 1-20MB/sec again (fluctuating but around 7MB/sec on average)!
Seems like exFat
does not play very well with very large files (several hundred gigabytes), so you might want to give ext4
a shot.
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
add a comment |
What is the file system of the hard disk where you save the rescue image and the logfile? I just made the experience of rescuing a 500GB internal hard drive (connected via SATA) on a Laptop running Linux Mint from a USB Stick, saving the rescue image and logfile on an exFat
formatted USB hard drive.
It starting rather slowly (1-2MB/sec) but after around 250GB it was only crawling at <100KB/sec. It seemed to become slower the larger the rescue image file was growing.
Then I moved the rescue image and logfile to another temporary place, re-formatted the USB hard drive with the ext4
file system, moved the files back on it and resumed the ddrescue
process - and now it runs with 1-20MB/sec again (fluctuating but around 7MB/sec on average)!
Seems like exFat
does not play very well with very large files (several hundred gigabytes), so you might want to give ext4
a shot.
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
add a comment |
What is the file system of the hard disk where you save the rescue image and the logfile? I just made the experience of rescuing a 500GB internal hard drive (connected via SATA) on a Laptop running Linux Mint from a USB Stick, saving the rescue image and logfile on an exFat
formatted USB hard drive.
It starting rather slowly (1-2MB/sec) but after around 250GB it was only crawling at <100KB/sec. It seemed to become slower the larger the rescue image file was growing.
Then I moved the rescue image and logfile to another temporary place, re-formatted the USB hard drive with the ext4
file system, moved the files back on it and resumed the ddrescue
process - and now it runs with 1-20MB/sec again (fluctuating but around 7MB/sec on average)!
Seems like exFat
does not play very well with very large files (several hundred gigabytes), so you might want to give ext4
a shot.
What is the file system of the hard disk where you save the rescue image and the logfile? I just made the experience of rescuing a 500GB internal hard drive (connected via SATA) on a Laptop running Linux Mint from a USB Stick, saving the rescue image and logfile on an exFat
formatted USB hard drive.
It starting rather slowly (1-2MB/sec) but after around 250GB it was only crawling at <100KB/sec. It seemed to become slower the larger the rescue image file was growing.
Then I moved the rescue image and logfile to another temporary place, re-formatted the USB hard drive with the ext4
file system, moved the files back on it and resumed the ddrescue
process - and now it runs with 1-20MB/sec again (fluctuating but around 7MB/sec on average)!
Seems like exFat
does not play very well with very large files (several hundred gigabytes), so you might want to give ext4
a shot.
edited Aug 10 '16 at 8:08
Anwar
56.6k22146254
56.6k22146254
answered Aug 8 '16 at 11:32
DirkDirk
1011
1011
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
add a comment |
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
I've done the same for the recover target drive, but there's no speed improvement though, still ~60 KB/sec average rate. This means that it will take ages for the entire 1 TB drive ! The source drive is an external USB as well, NTFS formatted.
– qdev
Nov 14 '17 at 10:12
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f336559%2fddrescue-is-taking-ages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown