Save data in Linux with ddrecovery
“Input / output error (5)” said the system when copying the file and forced to plunge into unpleasant thoughts about the new hard drive and sneaky SMART partisan. Fortunately, all important data was saved in backup copies, but still trying to pull out one file was very desirable - a 34GB virtual machine image contained several documents that would be unpleasant to lose.
It was not the best idea to make an image of the entire disk - there was no place for it, and there was no desire to install another hard one, in addition the disk structure was intact and access to individual files remained possible. The ddrescue utility came to the rescue , the task of which is to copy files which are difficult to read - primarily various optical discs, but also hard drives to the load.
The first step was to download the utility - it comes in standard Ubuntu packages (under the name gddrescue ), but it doesn’t contain the old version and does not contain some useful features.
Release 1.10 is located at ftp.gnu.org/gnu/ddrescue , is built with a simple set of "./configure && make && make install" and is ready for use right away.
A bit of theory - the ddrscue utility has one very useful feature, it maintains a special log in which it notes problem / missing places, and with further launches it already uses this file it tries to read only what it was not possible to recognize before. Therefore, the recovery process will go in several stages, first we try to recognize the most part as quickly as possible, and then we return to the problem areas.
')
The first pass is started by the command
those. disable repeated readings and attempts to minimize problem areas, indicate where and where to copy the log file. It is clear that copying the file to the same disk is a bad idea. The original ext3 file system, the partition where ext2 is copied.
Recovery log - the parameter is optional, but with a multi-pass option, it is needed, and if you forget to create it in the first pass, you can use --generate-logfile , the resulting log will be more optimal, but for further passes it will fully fit.
In my case, the first pass took more than a day and reported the following
the picture is not the most pleasant, but already something, we begin the second pass.
now we try to read the disk in direct access mode and with 2 retries. This number can be increased, but in my case it only increased the time and did not bring results. (But when copying a CD, it may well give a result).
The second pass took about another 15 hours, and significantly improved the picture:
but try to return the balance
In this mode, the speed drops very much, but what the previous two passes failed is being restored.
Two hours later, I interrupt the recovery, the result
it is clear that there should be no dramatic improvement. On the other hand, for small files (10-100mb), it was the third pass that gave maximum data, so it depends on luck and the nature of the problems.
The image was successfully added to VirtualBox, checked by the standard chkdsk and all the necessary data was copied, the dead 60 megabytes fell on the system files. It took a little more than two days to do everything, which is certainly plenty, but acceptable.
Successful recovery, and do not forget to make backups, they are worth the time lost, but in extreme cases, ddrescue will help you.
It was not the best idea to make an image of the entire disk - there was no place for it, and there was no desire to install another hard one, in addition the disk structure was intact and access to individual files remained possible. The ddrescue utility came to the rescue , the task of which is to copy files which are difficult to read - primarily various optical discs, but also hard drives to the load.
The first step was to download the utility - it comes in standard Ubuntu packages (under the name gddrescue ), but it doesn’t contain the old version and does not contain some useful features.
Release 1.10 is located at ftp.gnu.org/gnu/ddrescue , is built with a simple set of "./configure && make && make install" and is ready for use right away.
A bit of theory - the ddrscue utility has one very useful feature, it maintains a special log in which it notes problem / missing places, and with further launches it already uses this file it tries to read only what it was not possible to recognize before. Therefore, the recovery process will go in several stages, first we try to recognize the most part as quickly as possible, and then we return to the problem areas.
')
The first pass is started by the command
ddrescue --no-split --verbose /media/disk-1/broken.vdi /media/disk-4/fixed.vdi /media/disk-4/rescue.logthose. disable repeated readings and attempts to minimize problem areas, indicate where and where to copy the log file. It is clear that copying the file to the same disk is a bad idea. The original ext3 file system, the partition where ext2 is copied.
Recovery log - the parameter is optional, but with a multi-pass option, it is needed, and if you forget to create it in the first pass, you can use --generate-logfile , the resulting log will be more optimal, but for further passes it will fully fit.
In my case, the first pass took more than a day and reported the following
rescued: 22093 MB, errsize: 12264 MB, errors: 3876the picture is not the most pleasant, but already something, we begin the second pass.
ddrescue --direct --max-retries=2 --verbose /media/disk-1/broken.vdi /media/disk-4/fixed.vdi /media/disk-4/rescue.lognow we try to read the disk in direct access mode and with 2 retries. This number can be increased, but in my case it only increased the time and did not bring results. (But when copying a CD, it may well give a result).
The second pass took about another 15 hours, and significantly improved the picture:
rescued: 34292 MB, errsize: 65220 kB, errors: 16659but try to return the balance
ddrescue --retrim --max-retries=2 --verbose /media/disk-1/broken.vdi /media/disk-4/fixed.vdi /media/disk-4/rescue.logIn this mode, the speed drops very much, but what the previous two passes failed is being restored.
Two hours later, I interrupt the recovery, the result
rescued: 34293 MB, errsize: 64579 kBit is clear that there should be no dramatic improvement. On the other hand, for small files (10-100mb), it was the third pass that gave maximum data, so it depends on luck and the nature of the problems.
The image was successfully added to VirtualBox, checked by the standard chkdsk and all the necessary data was copied, the dead 60 megabytes fell on the system files. It took a little more than two days to do everything, which is certainly plenty, but acceptable.
Successful recovery, and do not forget to make backups, they are worth the time lost, but in extreme cases, ddrescue will help you.
Source: https://habr.com/ru/post/56796/
All Articles