HDD data recovery – intermittent disconnect/reconnect

[Hohgua]

Hi everyone,

I’m looking for some advice from people experienced in HDD repair and data recovery before I take any further steps with this drive.

The HDD is an old IDE/PATA drive Hitachi DK222A-54 540MB, probably dating from around 1995. I have not opened it yet. The data on it is important, so I would like to avoid doing anything that could make the situation worse.

The main problem is that the drive repeatedly disconnects and reconnects. I have tried several different USB-to-IDE/PATA adapters and an old pc with native ide/pata connector. The drive is detected by SystemRescue with the proper model name, and appears in the system logs, but it then disconnects and reconnects approximately every 3 seconds.

When this happens, I can hear the drive spinning normally, but I also hear the heads moving and then returning, followed by the drive apparently resetting and being detected again.

I made many attempts to read the drive, and at one point I was surprisingly able to recover approximately 70% of the disk using `ddrescue`. After that, however, I could no longer recover additional data. The situation has since deteriorated to the point where I cannot reliably read even the first sector because the drive keeps disconnecting and reconnecting.

The original HDD – the drive containing the data I am trying to recover.

Original PCB – front side.

Original PCB – back side.

The donor HDD – the drive I found as a possible donor for replacement components.

I made a list of the components I could identify on the PCB:

- Zilog Z86C9524ASC Z8 DSP 9439 KJ
- SRM2A256LLRM70 JAPAN V4Z3487
- ATMEL AT29C256 12TC 9502
- 32P4742-CGT ZS9502 55524F1
- 24.000 KDS 4L JAPAN
- HM62864LT7 9507 000 JAPAN 0G330
- CIRRUS LOGIC CL-SH4600-44VC-D 38642-310BF 9504 F KOREA-B
- GPS CLA71023CG 9502FPL
- Philips TDA5341G J11781 JvJ9448 2
- 4C TY2352
- 51 TY2342
- 9952 EY W448
- 51 TY2342

I’m not sure which of these components, if any, are relevant to diagnosing the failure, so I would appreciate any insight from someone familiar with HDD electronics from this era.

I also have an xGecu T48 if it could be useful to recover the data from the ATMEL AT29C256 12TC 9502.



At this point I have not opened the drive, as I don't have a proper clean environment yet. I am also trying to obtain a suitable laminar-flow/clean-air setup before considering any internal work.

Any advice on how to diagnose this failure mode would be greatly appreciated. I would especially like to understand what the symptoms indicate before proceeding with the donor drive.

Thanks in advance!

[Hohgua]

DDrescue log:

# Mapfile. Created by GNU ddrescue version 1.30
# Command line: ddrescue -n -R /dev/sdc /mnt/backup/hitachi.img /mnt/backup/hitachi.log
# Start time: 2026-08-12 16:21:07
# Current time: 2026-08-12 16:27:14
# Copying non-tried blocks... Pass 1 (backwards)
# current_pos current_status current_pass
0x18440000 ? 1
# pos size status
0x00000000 0x0FD40000 +
0x0FD40000 0x00010000 *
0x0FD50000 0x00010000 ?
0x0FD60000 0x084E0000 +
0x18240000 0x00010000 *
0x18250000 0x00010000 ?
0x18260000 0x00140000 +
0x183A0000 0x00010000 *
0x183B0000 0x00010000 ?
0x183C0000 0x00010000 *
0x183D0000 0x00020000 ?
0x183F0000 0x00010000 *
0x18400000 0x00040000 ?
0x18440000 0x00030000 *
0x18470000 0x00010000 ?
0x18480000 0x00010000 *
0x18490000 0x08040000 ?

[Hohgua]

Photos of system rescue

[ora]

Judging by the ddrescue log, you have almost the entire disk image, missing only the last 160 megabytes. I would first try opening the image with a data recovery tool that supports disk images - such as R-Studio or DMDE - to check if the data you need is already there; further copying of the hard drive might not be necessary. Because further copying could lead to major problems. Judging by the ddrescue log, there is a chance the heads reached a damaged area and failed completely.

I have not opened it yet. The data on it is important, so I would like to avoid doing anything that could make the situation worse.

The first thing you must not do - if the data is truly important - is attempt to open the drive at home or replace the heads yourself without prior experience. The first few attempts at a head swap, even in a laboratory setting and under professional guidance, almost always end in failure.

[Hohgua]

Thanks you for your answer, unfortunately the one I needed to recover hasn't been recovered yet:

| Directory | 8.3 Name | LFN | Cluster | Offset (MB) | Status | Key Content |
|-----------|----------|-----|---------|-------------|--------|-------------|
| **ROOT** | (root) | — | 2 | 1.06 | ✅ **Complete** | 51 entries, 5 deleted |
| **WINDOWS** | WINDOWS | WINDOWS | 24,714 | 97.6 | ✅ **Complete** | SYSTEM, INF, COMMAND, HELP, FONTS, config files |
| **PROGRA~1** | PROGRA~1 | Program Files | 29,978 | 118.1 | ✅ **Complete** | 930WIN (non-tried), standard Win dirs |
| **RECYCLED** | RECYCLED | RECYCLED | 45,758 | 179.8 | ✅ **Dir entries only** | 45+ DC*.CAL, DC9.ZIP, DC21.XLS, INFO — **all data in non-tried** |
| **MAXPLUS2** | MAXPLUS2 | maxplus2 | 53,329 | 209.4 | ✅ **Complete** | 25 Altera FPGA files extracted (4.5 MB) |
| **FILESA~1** | FILESA~1 | Filesaltera | 103,774 | 406.4 | ❌ **Non-tried** | Altera FPGA files |
| **CAL_ORIG** | CAL_ORIG | Cal_orig | 105,346 | 412.6 | ❌ **Non-tried** | Calibration original data |
| **CALIBRA** | CALIBRA | calibra | 106,468 | 416.9 | ❌ **Non-tried** | Calibration working directory |
| **DAPIEL~1** | DAPIEL~1 | Dapiel OBP | 118,944 | 465.7 | ❌ **Non-tried** | Project directory |
| **MIMMOE~1** | MIMMOE~1 | Mimmo Elind | 105,435 | 412.9 | ❌ **Non-tried** | User directory |
| **A68K** | A68K | — | 105,663 | 413.8 | ❌ **Non-tried** | 68K assembler |
| **930WIN** | 930WIN | — | 112,151 | 439.1 | ❌ **Non-tried** | Under PROGRA~1 — Optodyne 930? |
| **CLIPTEST** | CLIPTEST | — | 108,715 | 425.7 | ❌ **Non-tried** | Unknown |
| **X** | X | x... | 22,119 | 88.7 | ✅ **Recovered region** | Unknown |
| **LDDM** | LDDM | LDDM | 118,200 | 462.9 | ❌ **Non-tried** | **TARGET DIRECTORY** |
| **PE2** | PE2 | — | 113,919 | 446.1 | ❌ **Non-tried** | Unknown |
| **_C5_1** | _C5_1 | — | 106,720 | 417.1 | ❌ **Non-tried** | Duplicate of c5_1 |


The "LDDM" one is the important one, at the end of the disk