J. P. Gilliver (John) wrote:


For the hard-to-read files, I'd be tempted to seek - or write -
something which opens them, then copies them byte by byte (to a file on
a good drive) until a read error occurs; that way you'd have at least
part of the file, which may or may not be usable. (Ideally, something
which then carries on after the bad patch, maybe writing blanks to the
copy for the unreadable bytes - so that the copy at least is the same
size and has the tail, which for some filetypes - I think .zip is one -
is where important information about the contents is.)

Paul (or anyone else) - do you know of any such utility? [Preferably not
involving command lines, either in Windows or Linux (-:!] I did (a long
time ago - I think in BBC BASIC!) write one that did the first part
(copy byte by byte until error), but not beyond. [IIRR, BBC BASIC closed
the input file when there was an error reading.]

That's ddrescue, made available as "gddrescue" package on Linux.
Near the bottom of this page. It's used to clone entire, damaged
hard drives. You can "clone to an image file" or "clone to the
physical disk". If cloning to physical disks, the destination
has to be the same size, or be a larger disk, so the end of
the source disk is not chopped off by accident.

http://www.cgsecurity.org/wiki/Damaged_Hard_Disk

sudo apt install gddrescue # Get the package

which ddrescue # Check it is present

# first, grab most of the error-free areas in a hurry:
# Make sure ~ (your home directory), has enough storage space for logging.
# The "rescued.log" keeps track of which sectors are read and copied OK.

sudo ddrescue -n /dev/sda /dev/sdb ~/rescued.log

# then try to recover as much of the dicey areas as possible:

sudo ddrescue -r 1 /dev/sda /dev/sdb ~/rescued.log

The /dev/sda is the old disk.

The /dev/sdb is the new disk (same size of larger).

You can use

sudo gparted

and use that to view some information about the disks,
and get some idea whether yours is sda or sdb or whatever.

I'd provide a link to a Windows one, but I'm not convinced
one exists. The dude who wrote this one, knows exactly how
to port (or combine) the source files, and that person
would be the perfect person to write one for us. But
this one is not equipped to keep track of what was done,
or to do retries like the other one does. But at least this
person has figured out the namespace for low level
storage access (whatever it is).

http://www.chrysocome.net/dd

The chrysocome program only has one bug I know of. If
cloning a USB stick to something else, the program does
not reliably detect "the end" of the device. It's advised
to use a blocksize parameter and count, to tell the program
exactly when to stop copying. If your source USB is 1GB,
then you set a blocksize and count that transfers that
exact amount.

*******

The ddrescue program also has the ability to copy using a dynamic
block size. In essence, it knows it has to transfer the
whole disk, and it will vary the size of the read command
until it's snagged the whole source disk. That's unlike
how the chrysocome (Windows) one works.

This is an example from my notes. This is a backup to
an image file, rather than a low-level disk-to-disk clone.
The "sdb.raw" file, stored somewhere, will be the same
size as the source disk. If the sdb.raw file has any
512 byte blocks filled with zeros, they will take no
storage space on the destination file system. That's
the "sparse" notation, the "-S". But such a technique,
is reserved for situations where the disk owner sweeps
the white space on the drive with sdelete or similar,
causing blocks full of zeros to appear in any area where
no files are stored. If you fill the white space with
zeros, it allows archival copies made this way, to take
less space. "Sparse" is a feature of the NTFS file system,
and there's even a utility for interacting with sparse files.
The reason this is in my notes file, is I actually ran this.

ddrescue -S -b8M /dev/sdb /mount/external/backup/sdb.raw /mount/external/backup/sdb.log

The -b8M says "you can use block transfers as large as 8MB
if you feel like it". The actual program will not issue
a size that big, as the hard drive will tell it to get
lost if it tries. Disks have a limit on the size of
individual commands. And ddrescue has a way to "probe"
the supported size. In a way, my using that value is
a way of saying "unlimited... use the biggest one that
works" :-) Since my disk was not damaged, the contents
of the sdb.log file later were rather small.

Paul