Data recovery from Gparted quited HDD
 

Hello
Gparted quited while was resizing a large HDD. Can you guys figure out from the smartctl -a sdX output what is going on and best way for a beginner to intermediate Linux user to recover the data from the ntfs drive. Testdisk after deep scan thought it's not recoverable.
Really would love to get some of the data back, Thank you very much!

=== START OF INFORMATION SECTION ===
Model Family: * * HGST Deskstar NAS
Device Model: * * HGST HDN724040ALE640
LU WWN Device Id: 5 000cca 24ccf1a4b
Firmware Version: MJAOA5E0
User Capacity: * *4,000,787,030,016 bytes [4.00 TB]
Sector Sizes: * * 512 bytes logical, 4096 bytes physical
Rotation Rate: * *7200 rpm
Form Factor: * * *3.5 inches
Device is: * * * *In smartctl database [for details use: -P show]
ATA Version is: * ATA8-ACS T13/1699-D revision 4
SATA Version is: *SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: *(0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: * * *( * 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( * 24) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: * * * * * *(0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: * * * *(0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( * 1) minutes.
Extended self-test routine
recommended polling time: ( 580) minutes.
SCT capabilities: * * * (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME * * * * *FLAG * * VALUE WORST THRESH TYPE * * *UPDATED *WHEN_FAILED RAW_VALUE
* 1 Raw_Read_Error_Rate * * 0x000b * 100 * 100 * 016 * *Pre-fail *Always * * * - * * * 0
* 2 Throughput_Performance *0x0005 * 136 * 136 * 054 * *Pre-fail *Offline * * *- * * * 81
* 3 Spin_Up_Time * * * * * *0x0007 * 151 * 151 * 024 * *Pre-fail *Always * * * - * * * 570 (Average 454)
* 4 Start_Stop_Count * * * *0x0012 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 367
* 5 Reallocated_Sector_Ct * 0x0033 * 100 * 100 * 005 * *Pre-fail *Always * * * - * * * 0
* 7 Seek_Error_Rate * * * * 0x000b * 100 * 100 * 067 * *Pre-fail *Always * * * - * * * 0
* 8 Seek_Time_Performance * 0x0005 * 119 * 119 * 020 * *Pre-fail *Offline * * *- * * * 35
* 9 Power_On_Hours * * * * *0x0012 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 3255
*10 Spin_Retry_Count * * * *0x0013 * 100 * 100 * 060 * *Pre-fail *Always * * * - * * * 0
*12 Power_Cycle_Count * * * 0x0032 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 168
192 Power-Off_Retract_Count 0x0032 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 417
193 Load_Cycle_Count * * * *0x0012 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 417
194 Temperature_Celsius * * 0x0002 * 122 * 122 * 000 * *Old_age * Always * * * - * * * 49 (Min/Max 0/55)
196 Reallocated_Event_Count 0x0032 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 0
197 Current_Pending_Sector *0x0022 * 100 * 100 * 000 * *Old_age * Always * * * - * * * 0
198 Offline_Uncorrectable * 0x0008 * 100 * 100 * 000 * *Old_age * Offline * * *- * * * 0
199 UDMA_CRC_Error_Count * *0x000a * 200 * 200 * 000 * *Old_age * Always * * * - * * * 4

SMART Error Log Version: 1
ATA Error Count: 4
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 4 occurred at disk power-on lifetime: 1755 hours (73 days + 3 hours)
* When the command that caused the error occurred, the device was active or idle.

* After command completion occurred, registers were:
* ER ST SC SN CL CH DH
* -- -- -- -- -- -- --
* 84 51 80 e8 b3 a4 0b *Error: ICRC, ABRT at LBA = 0x0ba4b3e8 = 195343336

* Commands leading to the command that caused the error were:
* CR FR SC SN CL CH DH DC * Powered_Up_Time *Command/Feature_Name
* -- -- -- -- -- -- -- -- *---------------- *--------------------
* 61 b0 08 b8 b3 a4 40 08 * 2d+14:21:24.761 *WRITE FPDMA QUEUED
* 61 20 00 58 80 99 40 08 * 2d+14:21:24.761 *WRITE FPDMA QUEUED
* 61 18 08 90 73 07 40 08 * 2d+14:21:24.760 *WRITE FPDMA QUEUED
* 61 10 00 50 bc 01 40 08 * 2d+14:21:24.760 *WRITE FPDMA QUEUED
* 60 08 00 58 b4 a4 40 08 * 2d+14:21:24.739 *READ FPDMA QUEUED

Error 3 occurred at disk power-on lifetime: 1121 hours (46 days + 17 hours)
* When the command that caused the error occurred, the device was active or idle.

* After command completion occurred, registers were:
* ER ST SC SN CL CH DH
* -- -- -- -- -- -- --
* 84 51 b0 50 c3 4b 06 *Error: ICRC, ABRT at LBA = 0x064bc350 = 105628496

* Commands leading to the command that caused the error were:
* CR FR SC SN CL CH DH DC * Powered_Up_Time *Command/Feature_Name
* -- -- -- -- -- -- -- -- *---------------- *--------------------
* 61 00 18 00 cf 4b 40 08 * 2d+03:28:16.704 *WRITE FPDMA QUEUED
* 61 00 10 00 c7 4b 40 08 * 2d+03:28:16.702 *WRITE FPDMA QUEUED
* 61 00 08 00 c3 4b 40 08 * 2d+03:28:16.702 *WRITE FPDMA QUEUED
* 61 70 00 c0 aa 4b 40 08 * 2d+03:28:16.702 *WRITE FPDMA QUEUED
* 61 38 20 d0 a6 4b 40 08 * 2d+03:28:16.702 *WRITE FPDMA QUEUED

Error 2 occurred at disk power-on lifetime: 1116 hours (46 days + 12 hours)
* When the command that caused the error occurred, the device was active or idle.

* After command completion occurred, registers were:
* ER ST SC SN CL CH DH
* -- -- -- -- -- -- --
* 84 51 21 df d0 aa 04 *Error: ICRC, ABRT at LBA = 0x04aad0df = 78303455

* Commands leading to the command that caused the error were:
* CR FR SC SN CL CH DH DC * Powered_Up_Time *Command/Feature_Name
* -- -- -- -- -- -- -- -- *---------------- *--------------------
* 61 00 28 00 e4 aa 40 08 * 1d+22:04:10.801 *WRITE FPDMA QUEUED
* 61 00 08 00 dc aa 40 08 * 1d+22:04:10.801 *WRITE FPDMA QUEUED
* 61 00 00 00 d5 aa 40 08 * 1d+22:04:10.800 *WRITE FPDMA QUEUED
* 61 00 20 00 e0 aa 40 08 * 1d+22:04:10.800 *WRITE FPDMA QUEUED
* 61 00 18 00 cd aa 40 08 * 1d+22:04:10.799 *WRITE FPDMA QUEUED

Error 1 occurred at disk power-on lifetime: 1013 hours (42 days + 5 hours)
* When the command that caused the error occurred, the device was active or idle.

* After command completion occurred, registers were:
* ER ST SC SN CL CH DH
* -- -- -- -- -- -- --
* 84 51 c0 40 cb 5b 09 *Error: ICRC, ABRT at LBA = 0x095bcb40 = 157010752

* Commands leading to the command that caused the error were:
* CR FR SC SN CL CH DH DC * Powered_Up_Time *Command/Feature_Name
* -- -- -- -- -- -- -- -- *---------------- *--------------------
* 61 78 a8 10 80 5a 40 08 * * *00:01:43.351 *WRITE FPDMA QUEUED
* 61 08 a0 00 78 5a 40 08 * * *00:01:43.351 *WRITE FPDMA QUEUED
* 61 10 98 08 4a 5a 40 08 * * *00:01:43.351 *WRITE FPDMA QUEUED
* 61 08 90 00 48 5a 40 08 * * *00:01:43.351 *WRITE FPDMA QUEUED
* 61 48 88 78 3a 5a 40 08 * * *00:01:43.351 *WRITE FPDMA QUEUED

SMART Self-test log structure revision number 1
No self-tests have been logged. *[To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
*SPAN *MIN_LBA *MAX_LBA *CURRENT_TEST_STATUS
* * 1 * * * *0 * * * *0 *Not_testing
* * 2 * * * *0 * * * *0 *Not_testing
* * 3 * * * *0 * * * *0 *Not_testing
* * 4 * * * *0 * * * *0 *Not_testing
* * 5 * * * *0 * * * *0 *Not_testing
Selective self-test flags (0x0):
* After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

The options are not limited to these but ...

There are a few dd programs that will not stop on errors where you can take that image, mount it and then try to access it.

You can take a live boot and run testdisk/photorec.

You could try this drive in a new system.

Personally the drive looks at first glance to be bad.

@jefro: It's not apparent to me just what you see that looks "bad" about the drive. There are just 3 scattered error reports, the most recent of which occured 1500 powered-on hours ago. None of them appear to relate to the current problem. There are no bad sectors reported.

@lyub: Resizing filesystems is inherently a dangerous operation, shrinking especially so. Just what were you trying to do, what is the filesystem type, and how long had gparted been running when it unpectedly quit?

Said it was glance. Suggested new system to include all cables to double check.

Internal or external (USB) drive ?.
What caused gparted to quit - did you bump it, power drop ?.

Thanks for the suggestions, which dd programs do you have in mind?

I run testdisk from a life boot to say the data wasn't recoverable.

With photorec I had these issues: 1. Didn't find .avi in the list of files to recover, have home videos in .avi format I very much like to recover.
2. can't figure out the title photorec gives to an external drive I plugged in to save the files on.

Thank you both for great comments and questions.
@rknichols
The filesystem is ntfs on the whole disk/without partitions.
Gparted was running for ~3-4hrs and was move than 2/3 through a disk resize/shrink.

@syg00
Internal drive.
Someone touched the mouse/keyboard and the system logged out! thus quitting the Gparted job - new system, didn't quite get used to it to foresee that coming, had disabled screen saver, etc., though.
Yes, I usually have Backups, was in the middle of doing a major such, obviously due to fatigue 2 of my decisions could have been better.

Yes, there are no bad sectors on the disk, it looks well/ is new.
What do these error reports may mean?

Kind of odd. testdisk/photorec almost always has the ability to find the files on a drive. It may not be able to find by name or extension however.

Messing with the mouse shouldn't worry gparted. I've found it to be very robust over the last few years - so much so I usually don't even bother to take an extra backup before using it these days.
I recall seeing somewhere that it does "safe" copies where data is copied then the inode(s) updated. I'm sure it still does similar, so a simple (???) failure shouldn't be catastrophic. The fact you (and testdisk) can't find the partition is a more serious issue. Is the partition table there at all ? - not that that should worry testdisk.

As for photorec, there is a step-by-step walk-through on the site - have a look at that. It certainly does avi; scroll down some - they are arranged by group, sundry multi-media is probably later. Make sure you have the target mounted somewhere you recognise - it may be under /media/${USER}/ or somesuch by default depending on distro.
If you want to image the entire disk first, I suggest GNU ddrescue.

This has happened once (and only once) to me, too, many years ago.
I just wasn't prepared when I realized that this isn't going to take hours but days (old, slow machine...)!

As you probably realized by now, yours is a messed up filesystem problem, smartctl has nothing to do with that.
If testdisk cannot do its thing, then photorec still can. But filenames are the first thing to go on a broken filesystem. So, if the data is important enough, you'll go through it with a fine-tooth comb.

Pro tip: when I once had to do this timestamps were still intact, which helped me significantly to order photorec's output.

This is the fsck result:
fsck -f /dev/sdb
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb

-- ran ntfsfix as well:

sudo ntfsfix /dev/sdb
Mounting volume... NTFS signature is missing.
FAILED
Attempting to correct errors... NTFS signature is missing.
FAILED
Failed to startup volume: Invalid argument
NTFS signature is missing.
Trying the alternate boot sector
Unrecoverable error
Volume is corrupt. You should run chkdsk.

Not too sure I would have done that.That would be Windows chkdsk, NTFS being a proprietary format. Down the rabbit hole you go.

Solved it: after failing on fsck & ntfsfix
went to Windows and ended this.
Didn't even have to do anything, like running chkdsk:
during a fresh installation W fixed it automatically in seconds.
Happy to have all files incl. directories structure back intact.
(backed up everything already :) )

Thanks to all for the support, tips and comments!

I have 2 drives that also glitched on a gparted resize/move. I haven't had the heart to bring this to the forum yet. I cause enough stress with simple things.
What do you mean you did a fresh windows install. Did you do it over the bad linux system? What did you do to recover your data? Details please.

@sofasurfer
Glad if I could help knowing how stressful that kind of situation could be.
Here is an easy way out, the pinnacle of a few day trials and headache.

1. Gparted was easy to interrupt as (in my experience) a simple touch of the mouse (after it's been idling from input for a while) unexpectedly logged me off, thus cancelling the ongoing (for already 3-4 hrs) Gparted session. That ultimately messed up my drive and life for some days.
2. Installed Win 10 on a different hard drive's partition.
3. The hdd for recovery was plugged in as a secondary internal hdd. (it's good to leave the corrupted hdd unmanipulated as much as possible, installing OS on it was out of Qn). One can get W from M$'s web site as a free (30-day) trial; (for a newer/very large drive, or in general) it might be a good idea to get the latest ver. even if one has a copy already.
4. During the installation W flashed a screen/msg it needed to check a hdd for consistency: in seconds that was done (leaving it behind the scenes what it was actually doing and what was wrong with the hdd).
When the OS installation completed I had the formerly messed up drive entirely fixed, all files and the original directory structure on it intact (accessible from both W & Linux).
Alternatively, if one has already W installed and running, can use chkdsk for that, there are manuals out there.
5. The drive was NTFS. Being a W file system probably has a significance if/how W vs. Linux can handle it.

Hope that helps.
Wish you good luck recovering your drives and keeping your computing a safe & happy experience.