Using Partition Work to recover large NTFS / GPT drive?

[timg11]

I have two Seagate Ironwolf Pro 22TB drives formatted for GPT Windows NTFS, one as primary and one as backup.
I had both drives in a StarTech.com Dual-Bay USB 3.0 / eSATA to SATA Hard Drive Docking Station, and copied the primary to the backup. Everything seemed normal and the copy completed as expected.
Now, after a day, Windows is suddenly displaying both drives as a RAW drives and not the expected volumes.

How can I use Partition Work in Bootit Collection to recover these drives? Is there a KB or procedure?

[TeraByte Support]

I'd first move the drives to something else since some of those types of devices may not like such large drives. Also try different cable/etc.. You can start by just looking at what shows on the drive and the property of each.

[timg11]

I already moved them to a different computer and tried two different drive docks (Plugable and Inatek). No change - drives still seen as RAW in disk management in all cases.

[Brian K]

Have you tried installing the source 22 tb drive internally in a computer. Is it still seen as RAW?

[timg11]

BrianK, No I have not tried directly installing it in a computer. Do you think there is a failure mode where 3 different USB 3 docks on two different computers (docks which work fine with other similar drives) would show the drive as RAW, but installing it in a computer on a local SATA port would give a different result?
It seems unlikely but I'm interested to understand the underlying theory.

[timg11]

Getting back to my original question on how to use Partition Work for this recovery, here''s the advice given by AI. I don't think Claude has much specific knowledge about Partition Work in BIC (Which is why I posted here), but it offers these suggestions:


That's a significant detail about StarTech—they're usually reliable, but this particular dual-bay model has documented issues. Let me address both the UASP question and your recovery options.

UASP and the StarTech Dual-Bay Issue

Yes, UASP (USB Attached SCSI Protocol) is likely part of the problem, but probably not in the way you might think:

UASP is supposed to be safer than older USB Mass Storage Class (MSC) protocol
However, if the dock's firmware doesn't properly implement UASP, it can cause:
Incomplete write cache flushing before disconnect
Improper command sequencing during safe removal
The drive staying in an inconsistent state if the dock loses power or resets

The ejection problem combined with corruption suggests the dock either:

Crashed mid-operation and forced an abrupt disconnect
Failed to flush pending writes to the drive before the connection was severed
Corrupted the partition table rather than the data itself (which is actually good news for recovery)

Going forward: You can disable UASP on problem docks by disabling it in Device Manager > USB Mass Storage Device > Properties > Advanced, but this isn't a real fix—it just masks the underlying firmware issue.

Drive Recovery Strategy

The fact that it shows as RAW is actually excellent news—it means the file system metadata is corrupted, but the data sectors are almost certainly intact. This is one of the easiest recovery scenarios.

Boot It Collection's Partition Work should work, but here's my recommended approach:

Step 1: Assess the Damage (Non-Destructive)
Boot from your USB stick into the Linux environment
Run fdisk -l or parted -l to see if the partition table is still readable
If you see the partition but it's marked as "RAW"—that's repairable
Step 2: Try Partition Table Recovery First

This should be your first attempt because if it works, you recover everything:

TestDisk (part of most Linux live USB kits, free) is designed exactly for this
It can often rebuild a corrupted partition table without touching data
Run: sudo testdisk /dev/sdX (replace X with your drive)
Select "Proceed" → "Intel" → "Analyse" → let it scan
If it finds your partition, you can write it back to the MBR
GParted (if included in Boot It) can also attempt partition recovery
Step 3: If Partition Table Is Unrecoverable

Then use file recovery tools on the raw sectors:

PhotoRec (comes with TestDisk) can recover files by searching for file headers/footers—works on RAW disks
Ddrescue (GNU ddrescue) to create an image of the drive first:
bash
sudo ddrescue -n /dev/sdX /path/to/backup-image.img

This creates a working copy so you don't risk further damage to the original.

Step 4: For 22TB of Data

Given the size, do this methodically:

Connect the drive via a different docking station or external enclosure (not the StarTech)—this is critical
If you don't have an alternative dock, a USB-to-SATA cable ($10-20) is safer than another dock
Boot into Linux environment
Run TestDisk/Partition Work first (fastest if it works)
If that fails, ddrescue to an external drive (you'll need 22TB+ target storage)
Run PhotoRec or specialized recovery software on the image

[TeraByte Support]

not sure if you missed this: You can start by just looking at what shows on the drive and the property of each.

[timg11]

not sure if you missed this: You can start by just looking at what shows on the drive and the property of each.

Hi, here's what IFL reports about the problem drive: /dev/sda2

ifl:~# gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.6

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sda: 42970644480 sectors, 20.0 TiB
Model: Plugable USB3-SA
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 056F1EA3-49D0-4933-9C01-2EE9AC187628
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 42970644446
Partitions will be aligned on 8-sector boundaries
Total free space is 4063 sectors (2.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 34 32767 16.0 MiB 0C01 Microsoft reserved ...
2 32768 42970640383 20.0 TiB 0700 Basic data partition

Command (? for help):


ifl:~#
ifl:~# blkid /dev/sda2
/dev/sda2: PARTLABEL="Basic data partition" PARTUUID="3b6d66ae-1312-4694-8ab3-9702e78cf463"
ifl:~#


ifl:~# ntfsfix /dev/sda2 -n
bash: ntfsfix: command not found
ifl:~#



After reviewing the IFL and BIC manuals, here's what Claude recommends to repair:

OPTION 1: Resize with Automatic Filesystem Check (RECOMMENDED FIRST STEP)

This is your best recovery option. When you resize a partition in Partition Work, it automatically performs a filesystem error check that can often repair NTFS metadata issues.

Steps:

In Partition Work, select /dev/sda2 (your 20TB Basic Data Partition)
Click Resize under Actions
In the Resize dialog box, click OK to start the error check
Wait for the error-checking process to complete (this can take a VERY long time for 20TB - may be hours)
The hard disk indicator light will continue flickering while in progress
DO NOT interrupt this process
Once complete, you can review the partition information
You don't actually need to resize it - just click OK or Cancel once the error check finishes
The filesystem error check may repair the NTFS metadata


PS - I was going to attach screen shots from Partition Work, but I can't find the key in IFL. The manual has hundreds of occurances of the work "screen", and zero of "screenshot" and "capture". I vaguely remember it exists, but I can't seem to find it.

[Brian K]

You can use scrot in IFL to take screenshots.

Basic examples of usage:

1. Capture entire desktop to a time stamped PNG file:

scrot

2. Capture entire desktop to a specified filename:

scrot filename.png

3. Capture window selected by the mouse to a time stamped PNG file:

scrot -s

Type scrot -s
press Enter
click mouse (make sure you can see the entire window)

[Brian K]

Saving screenshot files:

All files will be saved to the /tbu directory unless otherwise specified in the filename path on the command line. The contents of the /tbu directory can be viewed by using Midnight Commander (MC icon), or by running the 'ls' command in a terminal window.

Since the files in /tbu only exist in RAM on the running boot disk, they will be lost when the system is rebooted or powered down. The files can be saved from the running boot disk by using the 'mnt' icon (Mount Drive or Partition) to mount a drive/partition, or the 'net1' icon (Mount Network Shares) to mount a network share, and then using Midnight Commander to copy the files to the mounted file system.
UNMOUNT target partition before closing IFL