Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Debian and derivatives; dabbled in others
Posts: 26
Rep:
ddrescue best practices
The source disk is a 300GB PATA boot drive in a mythbuntu BE/FE. I discovered the drive making some "bad noises" one day. When I tried to reboot it, it would not reboot. I left it sit for a few days and yesterday ran ddrescue to a new 2TB SATA drive receiving this report:
Code:
root@mythbuntu:/home/pat# time ddrescue -f -v -n /dev/sda /dev/sdc /home/pat/ddrlog.txt
GNU ddrescue 1.17
About to copy 300069 MBytes from /dev/sda to /dev/sdc
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 128 sectors
Sector size: 512 Bytes
Press Ctrl-C to interrupt
rescued: 300069 MB, errsize: 4096 B, current rate: 4096 B/s
ipos: 173040 MB, errors: 1, average rate: 28054 kB/s
opos: 173040 MB, time since last successful read: 0 s
Finished
real 178m15.932s
user 0m58.918s
sys 28m54.348s
root@mythbuntu:/home/pat#
Do I now run ddrescue again on the source drive to try to recover additional information? Does this report say the error is 4096B? How best to zero in on the error? Would ddrescueview or some other tool help? Thanks.
[edit]On further review I found this https://www.technibble.com/guide-usi...-recover-data/ rather thorough and practical guide to some options available to ddrescue users. I'm still not exactly clear about what to do once I isolate the error(s). Some errors I suppose are harmless. Others aren't. How do I tell the difference? Then how do I go about fixing those that need fixing?
I also see that R Tools Technology ("R-Studio") has a product called R-Linux (over on the right side of their website menu). Has anyone used R-Linux or the RTT products? Is there any other or better alternative? [/edit]
Last edited by pgreenwood; 10-24-2016 at 10:40 AM.
Reason: Further research
Distribution: Debian and derivatives; dabbled in others
Posts: 26
Original Poster
Rep:
Quote:
Originally Posted by syg00
As you used "-n", you need to let ddrescue go back and see if it can scrape anything missed.
See the examples in the manual on the homepage here
As suggested, I reran ddrescue without the -n flag.
Code:
root@mythbuntu:/home/pat# time ddrescue -f -v /dev/sda /dev/sdc /home/pat/ddrlog.txt
GNU ddrescue 1.17
About to copy 300069 MBytes from /dev/sda to /dev/sdc
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 128 sectors
Sector size: 512 Bytes
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 300069 MB, errsize: 4096 B, errors: 1
Current status
rescued: 300069 MB, errsize: 4096 B, current rate: 0 B/s
ipos: 173040 MB, errors: 1, average rate: 0 B/s
opos: 173040 MB, time since last successful read: 14 s
Finished
real 0m14.314s
user 0m0.002s
sys 0m0.003s
root@mythbuntu:/home/pat#
It doesn't seem any further progress was made with this run. Thanks for your suggestion, syg00. My thought is to clone the rescue disk (Disk 1) to another disk (Disk 2) then try to boot from Disk 1 to see if the OS will "repair" whatever is wrong with the 4096B error. Should I expect MD5sum Disk 1=MD5sum Disk 2? Any further ideas for next steps will be appreciated.
You have one 4K sector that is bad. You could write a pattern to that one sector (ie, <Unread>) and then grep search to see which file is associated with that sector. If you were to have some fancy data recovery hardware imaging systems, you would be able to quickly cross reference the unreadable sectors to the file tables.
All-in-all, 4K missing from 300GB is insignificant.
Distribution: Debian and derivatives; dabbled in others
Posts: 26
Original Poster
Rep:
I'm marking this "solved". I was [lazy and] hoping for a "bigger picture", more comprehensive approach to my particular problem, but there really isn't a one-size-fits-all. ddrescue is a powerful piece of software. It's best practices are completely described in its man page. Once it has done its job, the next piece of software may be called. It may be fsck or something else. Every situation is different. The real solution is to become familiar with all available tools and study the forums. Many thanks to those who weighed in!
The closest thing I know of to a "big picture" is the Bad Block HOWTO at smartmontools. It covers ext2/ext3 filesystems (ext4 should be similar) and, to a lesser extent, ReiserFS, but not other filesystems. As was mentioned, one bad 4K block in 300GB is very minor, but it's nice to know which (if any) file was affected.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.