Recovery Methods & Script (Re: Did v7.4.0 step on my NTFS disk?)
Hello Jim,
I still cannot think of a different reason why your drive failed. For a
seminar, I now flashed 100 8GB USB Sticks with Knopix, while a 500GB
harddisk is attached to the internal SATA, a 1TB harddisk and a 3TB
harddisk to USB3, and a USB3 hub with 7 sticks for each flash procedure
are all actively used. So far, not a single failure or overwrite of the
wrong disk, so I'm really puzzled about how this could have happened to
you. :-(
For Knoppix 7.4.1., I'll make the flash-knoppix script batch-able, so
you specify all options on the commandline and it just does its job on
the specified drive without ever asking anything. This is potentially
dangerous, but the interactive way will continue to work as usual.
Please read on.
On Thu, Aug 14, 2014 at 01:32:59AM -0500, Jim Pritchett wrote:
> Update:
>
> I've been working on this for about a week now. The
> usual disk repair tools failed to repair the NTFS partition table.
> Testdisk and gparted failed to correctly analyze the drive. I
> found a newer version of gparted, but that failed too. I found an
> NT utility that seemed to work. It actually found my files, but the
> version that claims to be able to actually repair it costs $55. No
> guarantees or refunds. I decided to keep working instead. I
My best guess is that you, by mistake, accidentially clicked on sda
instead of sdb and did not notice the mistake until the script was
finished.
It's the only way which could make the script overwrite the internal
disk, which never changes its address.
Another explanation could be the disk just failing unrelated to
flash-knoppix, but in this case, you should see a lot of "unrecoverable
read/write errors" in the dmesg log when reading or writing the first
sectors.
> researched MBR, partition table, and a bit of NTFS. I finally found
> the backup copy of the bootsector and copied it to the bootsector. I
> thought that would fix it, but although gparted could now see the
> partition, it wouldn't mount.
If my guess above is true, then the first 4GB of the disk were
overwritten, which would totally mess up the NTFS file system structure.
You could compare the bytes starting from sector 2048 with the content
of a knoppix-flashed USB stick (which also starts at sector 2048 for
alignment reasons).
In order to be able to mount the disk again, you would have to
quick-format an empty NTFS volume header (mkntfs -Q), but that will iof
course not recover the old file names. "photorec" will be able to read
most of your files back to a directory on a different disk. In some
(rare) cases, the original file names can be extracted from the header
data of those files, but for most of them, you will end up with a file
name numbered by the block/sector where it was found on the disk. At
least that's a way to get the content back where it was not overwritten.
> The attached picture shows the message from gparted. You might have
> to blow it up a bit to read it. It says something about a
> SoftRAID/FakeRAID problem. I'm not using any RAID of any kind, so I
> don't know why it says that.
Probably because your SATA-controller is capable of doing softraid, even
that you don't use it. The program apparently assumes it will find a working
raid installation when re-assembling the raid structure. I think it's lying.
> I'm thinking that the bootsector and partition table is still messed
> up somehow.
Again, please compare the sectors 2048 and following with a
flash-knoppix prepared USB flash disk. You can use a hex editor like
"hexedit" for that. If you find matches, my guess above is -
unfortunately - correct.
> It is strange that some utilities correctly see the
> single partition while others seem to think there are three
> overlapping partitions.
They just find the two-byte partition signature that's present in
various file systems, and offer different partition schemes based on
what they found. It's no magic. But these partition signature byte
combinations can also occur inside normal files.
> The NT utilitiy is now in the confused
> category too. I'm missing something here.
>
> P.S. I couldn't reply directly to the previous messages because my
> mail is on that drive. That is why this one's subject is not quite
> the same as before. 8(
Did you try the tools from the ntfspros package yet? ntfsfix, ntfsck,
ntfsundelete, ntfsinfo, ...? It's unlikely, but giving them an offset to
search for, may be helpful.
And another think I can think of, which is a non-destructive test: You
could try, even with a broken partition table, to mount an NTFS volume
by giving an offset to mount, on the straight disk, not a partition. The
attached script will try to mount NTFS in read-only mode using a loop
with increasing offsets to try. Since the NTFS structure, if still
intact, would be on the fist sectors of the disk, it should find
something quickly, or nothing at all. You may have to decrease the SKIP
variable if the NTFS was badly aligned, down to 512. Call the script
with /dev/sda, not /dev/sda1, as first parameter.
Regards
-Klaus
#!/bin/bash
[ -n "$1" -a -n "$2" ] || { echo "Usage: $0 device mountpoint [start_offset] [filesystems...]" >&2; exit 1; }
[ "`id -u`" = "0" ] || { echo "Must be root to use $0." >&2; exit 1; }
DEV="$1"
MNT="$2"
[ -d "$MNT" ] || mkdir "$MNT" || { echo "Mountpoint $MNT not found, and cannot be created." >&2; exit 1; }
[ -n "$3" -a "$3" -ge 0 ] 2>/dev/null && offset="$3" || offset=32256
[ -n "$4" ] && FILESYSTEMS="$4" || FILESYSTEMS="ntfs vfat ext2"
# Higher values speed up searching, but may miss the actual start of filesystem
SKIP="32256"
if [ -b "$DEV" ]; then
final_offset="$(blockdev --getsz "$DEV")"
else
final_offset="$(du -sb "$DEV" | awk '{print $1}')"
fi
LOOP="$(losetup -f)"
[ -b "$LOOP" ] || { echo "losetup -f did not find a free loop device. :-(" >&2; exit 1; }
while [ "$offset" -lt "$final_offset" ]; do
echo -n -e "\rTrying $offset..."
for f in $FILESYSTEMS; do
mount -t "$f" -o loop="$LOOP",ro,offset=$offset $DEV $MNT >>mount.log 2>&1 && \
{ echo -e "\nFound $f filesystem, now mounted on $MNT"; exit 0; }
losetup -d "$LOOP" >/dev/null 2>&1
done
let offset+="$SKIP"
done
echo "No filesystem(s) $FILESYSTEMS found on $DEV" >&2
Reply to: