• In the table to follow, please bear in mind that:
    1. This table assumes that you (know you) have a faulty disk or filesystem. It does not cover things like bad cables, bad controllers, bad motherboards, bad CPU's, bad memory or bad termination, all of which can seem to be bad disks or filesystems at times. If you suspect you may have a bad disk, but aren't sure yet, then if you can see some important data right now that you cannot afford to lose, it's a good idea to use one or more of the "1) make a best copy of what you have" methods below, then check related hardware other than your disk, then resume with one or more of the "2) repair what you have" or "3) hunt for lost data?" methods, because a bad disk can get a lot worse fast sometimes.
    2. If you don't have backups, ask yourself "why not?" You're probably too busy right now dealing with the lost/missing data, but put a time to look into backups on your calendar, right now
    3. Methods that use the POSIX file API will generally have one class of failure modes, and methods that go to the device file will generally have another class of failure modes, so it can be a good thing to try at least one of each if you want to make a copy (assuming the first you try doesn't work).
    4. Methods that try to undelete or search for bit patterns through the device file will tend to have decaying usefulness. That is, every second that elapses from the time the file is deleted or otherwise lost, until you start hunting for the file, is a second that increases the probability that you won't be able to get the file back. To make matters worse, some *ix filesystems will intentionally reuse recently-released blocks, in an effort to reduce disk head motion and consequently increase performance, which means your file's blocks may be allocated to new files before other blocks that have been free for ages. You can reduce the pain of this situation a bit by making the first thing you do, creating an image backup onto another disk, to a file on another filesystem, or to a disk on another host. The best way to do your image backup is the fastest way - usually that means to a file on another filesystem on the same host. If you do choose to do an image backup, you may want to see copying lots of data. If you don't have enough room for an image backup, consider compressing it, especially if the filesystem isn't 100% full (and hasn't been since the last mkfs/newfs/whatever).
  • Approaches for recovering lost data from a damaged disk and/or damaged filesystem:
  • Someday, I hope to find time to add this to the table above:

    Hits: 5841
    Timestamp: 2024-03-01 13:06:48 PST

    Back to Dan's tech tidbits

    You can e-mail the author with questions or comments: