[Discuss] recover files and foldes from USB pendrive?

[George Farris]

BTW something to think about for those interested in data retention:



  First, about hard disks...it would be enlightening to look up some
statistics on the error rates of modern drives.  The numbers are not
good.  Going back to sub-TB-class drives will give you a much greater
chance of actually reading data back once it's written.  The
conventional wisdom that anything newer will somehow automatically be
more reliable does not apply here...but you can virtually guarantee that
anything newer will have been cheaper to manufacture, which is at odds
with the desire to actually get the data back.

  Bear in mind the typical use case for
absolutely-friggin-gigantic-capacity hard drives, 1TB or larger.  99.9%
of these are used in two basic applications: desktop PCs for the
unwashed masses, and very large RAID arrays.  In the former case, people
believe they "need" that much capacity because it is available for
purchase.  Those few who actually scratch the surface of using that much
disk space generally do so with collections of movies and music, as
those, especially the former, are just about the only thing (again,
99.9%) that actually takes up any appreciable amount of space.  If
there's a bit error in a movie, you'll hear a tiny "tick" in the audio
or get a tiny burst of visual static or color distortion in the video,
which will almost always go unnoticed and, fortunately, never really
hurts anything.  Since most of those poor sods are running old
non-checksumming filesystems (NTFS comes to mind), they will never know
that part of their data has been lost.

  Further, if some bits get corrupted that cause (say) Microsoft Word to
start misbehaving, that world is very well-trained to "just reinstall
it".

  In large disk arrays, data is checksummed and stored redundantly, so
any read errors are dealt with and every bit of data that is delivered
to the host is intact and correct.  The integrity of the data is
verified at the bit level at every read, and in some filesystems, at
other times as well.  These techniques are not employed by the typical
home PC user who just buys and trusts.

  So, to summarize the above, big unreliable disks are nearly always
used in situations in which where the actual data being stored isn't all
that important, or they are used in redundant configurations which
compensate for their shortcomings.  For those 0.1% of situations in
which EVERY BIT COUNTS, like preserving software for vintage computers,
those high bit error rates can be a disaster.

  Anyone interested in seeing the real numbers, which are terrifying,
should go find the disk error rate study that Google did several years
ago.  It is several years old now, but disk error rates have only
worsened since then...not improved.

  So, on to flash memory.  That situation is even worse.  John, you
typed above "it seems that USB sticks can only tolerate a certain number
of write operations before they fail."  This does not "seem" to happen;
it is known and documented.  Flash memory cells have a write endurance
rating.  The flash memory chips that I use in my commercial designs have
an endurance spec of, depending on the chips, anywhere between 100,000
and 1M writes.  For desktop computer use, I have one-year-old 16GB flash
drives (consumer grade) which are already starting to have data
retention problems.

  Older flash drives tend to last a lot longer.  There is a direct
negative correlation between capacity and longevity.  As capacities go
up, bit cells become smaller, and the charge they retain to
differentiate a '1' from a '0' becomes smaller, and leaks away more
quickly.  The situation became far worse with the introduction of "MLC"
(Multi-Level Cell) flash chips.  That uses multiple levels of electrical
charge to represent multiple data bits in a single bit cell, typically
four bits per cell.  This means the differentiation in the amount of
electrical charge (in analog terms here...remember, there's really no
such thing as "digital circuitry" only analog circuitry specified and
described in digital terms) stored in the bit cell required to
differentiate between 00, 01, 10, and 11 is 1/4 of the margin required
to differentiate between 0 and 1.  Write endurance ratings are
commensurately lower...well under 10,000 writes for consumer-grade flash
devices like thumb drives, and less than 1000 writes for cheap clones.
To further brighten your day, note that writing a single file can result
in dozens of actual device writes to directory areas, file allocation
tables, etc.

  The moral of the story here is don't trust really ANY ultra-modern
storage technology for data that would be damaged by the loss of one or
more bytes.  Either spend the money and physical space to store data
WELL, or make friends with someone who has...or make yourself
comfortable with the fact that you WILL lose data, you MAY NOT know
about it, and, statistically speaking, it's essentially impossible that
it hasn't ALREADY HAPPENED unbeknownst to you.

  I myself use a redundant, end-to-end-checksummed filesystem spread
across eight 100%-duty-cycle-rated 1TB hard drives to store data that
cannot be replaced.  Those drives are never powered off and are kept in
a controlled environment.



On Mon, 2014-06-09 at 10:36 -0700, brendan wrote:
> On 14-06-08 08:17 PM, Cy Schubert wrote:
> > Trying something may lose your data permanently. I'd dd the whole USB stick
> > to a file on your Linux system and try a few tricks there. I've done this
> > under FreeBSD and trying a few tools against an md device and depending on
> > the problem have had limited success. I'm sure linux.
> 
> +1 on this. always dd the drive and work against the dd'ed image (mount 
> it as a loopback filesystem). it's often quicker for the repair tools to 
> work against a local file (your hard drive likely being faster than your 
> usb bus) and you can make multiple copies of the dd for testing various 
> recovery methods.
> _______________________________________________
> Discuss mailing list
> Discuss at vlug.org
> http://lists.vlug.org/mailman/listinfo/discuss