Partitie data terugvinden met TestDisk en/of andere too

[Jeroen]

Ik heb een 6 TB externe schijf die gisteren plotseling corrupted is geraakt. Waarschijnlijk heb ik dit zelf veroorzaakt door een van de volgende dingen te doen. Ik was geboot in Xubuntu 20.04 via een live USB, de 6TB disk is aangesloten via USB:

- Een interne SSD die waarschijnlijk defect is via SATA loskoppelen en weer terugkoppelen op een andere SATA-poort, terwijl het systeem draait.
- Uitvoeren `sudo partprobe` in de hoop dat hij gedetecteerd zou worden.

Vanaf dat moment geeft `fdisk -l` plotseling geen partities meer weer op de 6TB schijf. Misschien zijn er dus bytes de verkeerde kant op geslingerd of zo. Wie weet helpt deze informatie.

Als ik de schijf nu verbind met mijn Windows 10 laptop dan vindt die hem 'not initialized'. Omdat ik volgens mij 'niks' gedaan heb, heb ik hoop dat alleen het begin van de schijf corrupted is en de data nog bestaat. Alternatief is dat de harddisk gewoon defect aan het raken is, en de timing toevallig was.

Ik weet dat de partitie exFAT was. Ik weet niet zeker met welk systeem ik de partitietabel en partitie heb aangemaakt, maar het is een losse 'interne' disk met een aparte USB behuizing dus er zitten geen bloatware partities op uit de fabriek. Waarschijnlijk heb ik macOS of Windows gebruikt om de full-disk partitie aan te maken.

Ik heb TestDisk geprobeerd en hij vindt een exFAT partitie die start op sector 26k ongeveer. Als ik de bestanden bekijk met 'p' dan zit er het een en ander tussen dat leesbaar is, maar voornamelijk totale onzin. De bestandsnamen zijn 'blokjes', de datums zijn random tussen het jaar 1970 en 2100, etc.

Daarop volgt mijn vraag: is dit het beste wat ik kan bereiken? Wat kan ik doen om de bestandsdata nog fatsoenlijk te recoveren, gegeven wat ik weet over de partitie? En heeft het zin om de drive uit de USB-behuizing te halen en in een PC direct aan te sluiten?

[Jeroen]

Ik heb de volgende updates: uit de SMART test (uitgebereid van 13 uur) lijkt dat de disk zelf nog OK is. Hier is een afbeelding van de Testdisk data die ik al noemde. Wat kan dit veroorzaken? Ik heb op dit moment nog geen grotere schijf om een image op te zetten dus ik schrijf liever nog niet naar de disk, maar dat komt eraan.

code:

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-42-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     HGST Deskstar NAS
Device Model:     HGST HDN726060ALE614
Serial Number:    K1K5NNUD
LU WWN Device Id: 5 000cca 255ecd9f7
Firmware Version: APGNW7JH
User Capacity:    6,001,175,126,016 bytes [6.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:   ACS-2, ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Nov  7 13:11:29 2020 UTC
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:        (  113) 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:    (   2) minutes.
Extended self-test routine
recommended polling time:    ( 774) 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   138   138   054    Pre-fail  Offline      -       101
  3 Spin_Up_Time            0x0007   137   137   024    Pre-fail  Always       -       482 (Average 479)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       55
  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   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       951
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       9
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       70
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       70
194 Temperature_Celsius     0x0002   136   136   000    Old_age   Always       -       44 (Min/Max 19/63)
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       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%       790         -
# 2  Short offline       Completed without error       00%       778         -

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.

[Thralas]

Jeroen schreef op dinsdag 27 oktober 2020 @ 09:16:
Vanaf dat moment geeft `fdisk -l` plotseling geen partities meer weer op de 6TB schijf. Misschien zijn er dus bytes de verkeerde kant op geslingerd of zo.

Dat laatste klinkt plausibel. Maar de zaken die je noemt zijn op zichzelf geen logische oorzaak.

Ik heb de volgende updates: uit de SMART test (uitgebereid van 13 uur) lijkt dat de disk zelf nog OK is. Hier is een afbeelding van de Testdisk data die ik al noemde. Wat kan dit veroorzaken?

Omdat je met het omprikken van disks in de weer was en ik ook nog eens een aantal recente disk images zie in je TestDisk output: wat was je exact aan het doen? Disks imagen? Hoe? Niet perongeluk wat disk identifiers omgewisseld en daarmee de verkeerde disk overschreven?

User error is een stuk waarschijnlijker dan een disk die geen enkele indicator van hardwarefalen vertoont maar wel spontaan z'n partitietabel (en/of meer) kwijtraakt. Weten wat er exact is misgegaan kan helpen om recoverykansen in te schatten.

Heb je al gecheckt wat een reguliere exFAT-driver van je filesystem vindt? Of dat er uberhaupt nog een filesystem header is? Testdisk's implementatie is mogelijk bedoeld om zoveel mogelijk terug te vinden, consistentie is dan wat minder van belang.

Ik heb op dit moment nog geen grotere schijf om een image op te zetten dus ik schrijf liever nog niet naar de disk, maar dat komt eraan.

Je kunt met losetup een readonly loop device maken op de partitieoffset, dan kun je daar naar hartelust op experimenteren.

losetup -fro $((264192*512)) /dev/sdX
losetup -a
file -s /dev/loopX

Om naar de disk (of partiie) te 'schrijven' zonder risico kun je het volgende doen: https://unix.stackexchange.com/a/67681

Zorg er wel voor dat je altijd als eerste stap een readonly loop device van de disk (of partitie, zoals in bovenstaand voorbeeld) maakt, dat verkleint het risico op fouten.

Met virtualisatie kun je bovenstaande block devices ook aan een Windows VM hangen. Dan kun je chkdsk uitvoeren..

[Jeroen]

Bedankt voor de tip, dat klinkt handig. Dan kan ik gewoon met Testdisk dingen proberen die mogelijk werken, en het resultaat inderdaad gewoon mounten en echt bekijken.

Ik denk ook dat ik iets fout kan hebben gedaan, maar helaas was ik bezig in een live USB omgeving en is er dus geen shell history meer. Ik was juist bezig een poging te doen een andere SSD te redden (de bovenste items zijn inderdaad disk images daarvan) met dd. Die heeft denk ik wel degelijk hardwarekuren. Als die verbonden is (sata) dan vertraagt het booten, soms verschijnt die dan in de boot lijst en soms niet, en als ik er dan van kan lezen dan gaat dat uiteindelijk met kilobytes per seconde (vandaar ook dat ik experimenteerde met block sizes voor dd) en leek hij na verloop van tijd te vertragen. Onder Windows trekt hij de volledige disk IO vol na een paar minuten zonder dat er iets mee gedaan wordt, en vertraagt het OS. (dit ging over de SSD, niet de schijf in kwestie)

Ik zou normaal niet verwachten dat er het een en ander geschreven wordt naar het verkeerde device, maar ik heb dus wel onder deze omstandigheden die SSD hot losgekoppeld en wie weet of er iets even out of sync was. Het kan ook zijn dat ik met dd de output file verkeerd heb gehad, maar als dat gebeurt realiseer ik me dat wel uiteindelijk en in dit geval heb ik niks kunnen vinden dat fout was gegaan in de gestuurde commands.

Als ik de grote schijf verbind met een Windows machine en ook onder Xubuntu live met fdisk dan vindt hij uberhaupt geen partitietabel. Omdat ik de disk nog niet heb kunnen backuppen heb ik dus nog geen edits gemaakt met Testdisk (hij vindt wel een partitie, lijkt het) en ben ik daarmee nog niet verder. Nu kan ik dat wel proberen. Chkdsk is misschien ook wel de betere tool voor exFAT, of valt dat wel mee?

[Renault]

Aan de disk mankeert niets (op grond van de SMART data), je bestandssysteem of de partitiertabeld is dus corrupt geraakt.
Blijkbaar heb je geen backups, maar ben je wel in live disks aan het rommelen geslagen met dit resultaat.

Ik zou de harddisk benaderen als "te recoveren", dus uit het systeem halen (als het uit staat), en eerste afmaken waar je mee bezig was met "die corrupte SSD".
Daarna maak je met dd een diskcopy en ga je datarecovery pogingen doen op de kopie.
Het origineel bewaar je voorlopig voor professionele recovery (als de eigen poging niet lukt en het je voldoende waard is).

[Jeroen]

Dit is inderdaad het plan, daarvoor moet ik eerst mijn nieuwe disks binnenkrijgen (6TB kan ik niet zomaar kwijt). Dit was juist mijn backup/archive schijf. Ik had hem alleen verbonden voor de recovery van de genoemde SSD. Ik kan dat dus ook niet afmaken op dit moment.

Woensdag heb ik waarschijnlijk al mijn onderdelen binnen om m'n NAS te bouwen waar ik de image van de 6TB schijf op kwijt kan. Tot die tijd doe ik er waarschijnlijk niks mee. Eerst zal ik de nieuwe disks moeten SMART testen na verzending, en de NAS goed instellen.