Member Avatar for Miklos_1

Hi!
There once again everyone, and thanks in advance. I had a customer with a raid-0 array on a Win7 Ultimate box. He had roughly 30 gigs of Extremely important pictures on the drive, Unfortunately he didn't recall them being there until a new OS was re-installed. That's when we got the machine. I've been able to recover roughly 75% of the pics through various recovery tools. Problem is that when I'm viewing these pics within a folder in thumbnail view they look fine (most anyway, some are jumbled, like the head on the feet of a person, and the sky on the bottom and the ocean on top) when i attempt to open the pics through ALL programs from coral to Adobe Photoshop I get an initial error of File is damaged, could be truncated or incomplete when using adobe photo shop, and pretty much the same thing within all the other programs. Another oddity is that when these pics came back in the recovery they came back within the Recovered Jpeg folder, but when actually recovering and copying to a folder windows states that they were GIF. I changed the files type from gif to JPEG and anything else i could think of with the same result, I did try PIXRECOVERY demo witch i believe it fixed 1 of about 15 i tried but the demo has a big black box in the middle. What do you think?

Edited by happygeek because: moved
  • 2 Contributors
  • 1 Reply
  • 301 Views
  • 3 Minutes Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

Quick diagnosis and next best steps (for ): the thumbnails you see can be created from embedded EXIF thumbnails or because the recovery tool found JPEG markers in the raw data — that doesn’t mean the full image stream or headers are intact. Simply renaming a file from .gif to .jpg won’t change the file’s internal signature; the OS/viewer relies on the file’s magic bytes and internal segments, not the extension. (exiftool.org)

Recommended, non-destructive workflow (do these in order and stop if unsure):

  • Stop using the original RAID and do not copy recovered files back to it.
  • Make sector-by-sector images of every member disk (work from the images, never the originals). Use a tool designed for fragile media; ddrescue is a standard choice. (gnu.org)

Example imaging command (Linux) — adapt paths/devices for your environment:

ddrescue -n /dev/sdX /mnt/recovery/diskX.img /mnt/recovery/diskX.map
  • Reconstruct the RAID from the disk images (correct disk order, stripe/unit size and offsets are critical). If reconstruction is wrong the carved files will be scrambled and show the symptoms described. (diskinternals.com)
  • Run carved recovery on the reconstructed virtual volume or on the images (PhotoRec/TestDisk can carve JPEGs from images without relying on the filesystem). Inspect recovered files with ExifTool/JPEGsnoop to see whether headers or EXIF thumbnails survive and whether files are truncated. (cgsecurity.org)

If thumbnails look OK but full images fail to open, the common causes are truncated JPEG streams, wrong stripe alignment on RAID-0, or interleaving that broke after the OS reinstall. If the pictures are extremely important, stop experimenting and consult a professional RAID/data-recovery service (they can image failing drives with hardware tools and try multiple stripe/order hypotheses safely). As noted, this reinforces why offsite backups are essential.

Member Avatar for rproffitt

I think this is how most folk learn that backups are not optional.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.