Welk bestanden zijn "stuk" door deze slechte sector?

[Lucky Luke 008]

Mijn vraag:

Ik heb een harddisk met 8 slechte sectoren (512 byte elk, dus totaal 4096 byte). Deze zijn echt onleesbaar, zelfs ddrescue komt er niet uit, maar gelukkig is het maar weinig data.

Toch zou ik graag weten welk bestand nu corrupt geraakt is.

Deels uit nieuwsgierigheid, deels om zeker te weten dat het niks belangrijks was / als het wel iets belangrijks was te controleren of ik daar een backup van heb (Ik heb backups, sterker nog, net voor de schijf defect bleek heb ik een backup gemaakt en ik wil dus ook weten of die 100% correct is, maar ik heb ook oudere backups waar eventueel een beschadigd bestand nog uit gevist kan worden.)

Er is hopelijk een tweaker die uit ervaring ongeveer weet welke software bruikbaar is om adhv een sector/adres uit te zoeken welk bestand daar staat?

Relevante software en hardware die ik gebruik:

Debian
De hitachi 500gb schijf met slechte sectoren
Een backupschijf met het image dat ddrescue ervan heeft weten te bakken
De ddrescue mapfile waarin staat op welk adres/punt/sector de boel niet meer te lezen viel
Een laptop, waardoor de disks via USB zitten aangesloten omdat de interne sata aansluitingen niet heel handig bereikbaar zijn en bovendien in gebruik voor de bootdisk en de cd-drive (er is een hdd caddy onderweg).

Wat ik al gevonden of geprobeerd heb:

Ik wilde oorspronkelijk alleen de partitie met mijn data door ddrescue laten lezen, omdat de rest van de schijf eigenlijk niet belangrijk is. Echter, de schijf lijkt ook zijn partitietabel kwijt te zijn. "Schijven" (dit beest: https://wiki.gnome.org/Design/Apps/Disks) ziet ' m als leeg en ongeformatteerd.

De partitiei-ndeling die ik me herinner:
| EFI (Paar 100 mb) | Iets fabrikantigs (Paar 100mb) | Lege ruimte waar ooit Windows stond (200-nogwat GB) | Linux / (Geen idee, 50gieg?) | Linux /home (200-nogwat GB) | SWAP (8GB) | Iets fabrikantigs (zo' n 20GB) |

(de fabrikantige dingen zijn diagnose en herstelpartities van de laptopfabrikant)

De mapfile van ddrescue geeft aan waar het geen data meer kon lezen (overigens, ook met tig keer herproberen kan het die data niet lezen. Ik kan het er wel een dag op loslaten, maar ik wil graag eerst weten of het überhaupt belangrijke data is...)

# Retrying bad sectors... Retry 16 (backwards)
# current_pos current_status
0x542B1FF200 -
# pos size status
0x00000000 0x542B1FF000 +
0x542B1FF000 0x00001000 -
0x542B200000 0x2045A00000 +

Ofwel, sectoren 0x542B1FF000 tot 0x542B200000 kan 'ie niet lezen.
Da's dus vanaf ongeveer 361,5GB, wat als ik mijn partitie-indeling correct herinner, inderdaad ergens in de /home partitie zit en dus ergens in mijn data

(Ervan uitgaande dat die indeling zoals "schijven" 'm weergaf toen de disk nog netjes werkte, ook daadwerkelijk vanaf 0 begint aan de linkerkant. Zit de 0 rechts, dan zit de fout ergens in de onbelangrijke lege ruimte )

(Mogelijk had "alleen even uitzoeken waar die slechte sector zit" een stuk sneller gekund dan de hele zooi ddrescue-en, maar als de boel nu "stukker" gaat, heb ik iig een image van alles dat nog niet stuk was...)


tldr; Welk bestand staat op sector 0x542B1FF000 van mijn disk? (Your disk might, obviously, differ)

[pixeled]

Volgens een antwoord op een soortgelijke vraag als die jij stelde op Superuser is dit te doen middels een hex-editor, in dit geval WinHex:

Here's the process using WinHex, a handy hex editor that can examine and edit drives directly. Be very careful; this tool can damage your system if used inappropriately. Open disks read-only whenever possible.

- Since you have the bad sector locations already, you can open the drive in WinHex directly ("Open Disk" toolbar button) and then navigate to the sector to view the data ("Go to Sector" toolbar button). Assuming your sector locations are physical sector addresses, you need to open your physical drive in this step.

- This won't identify the file directly, but the left-hand pane should identify the partition that contains this sector and its corresponding relative sector address.

- If the partition you've identified is an NTFS or FAT partition, we can open the partition directly ("Open Disk" again). This will open the partition in a new tab, so you can switch back and forth as needed. In the partition tab, use the "Go to Sector" function again, but this time input the translated sector (the "relative sector" identified in the drive view).

- Now, in the left-hand pane, you should see a section on "Alloc. of visible drive space". Under this is the cluster #, physical sector #, logical (relative) sector #, and the filename if this sector actually belongs to a file.

If these steps don't give you an immediate answer, your bad sectors may not be in use. If the results are unclear, you may have to do some more digging to find your answer.

Denk dat dat je vraag beantwoordt?

Edit: Oh, je gebruikt Linux
In dat geval: https://wiki.archlinux.or...iles#Find_damaged_files_2

Hoewel dat voor Arch is, zijn de benodigde tools (tunefs, debugfs, icheck, ncheck) ook op Debian-like systemen te vinden, misschien zelfs al pre-installed maar dat weet ik zo niet (gebruik zelf Arch).

[ Voor 8% gewijzigd door pixeled op 12-12-2017 16:44 ]

[u_nix_we_all]

Ik neem aan dat het een Linux filesystem is dus ik weet niet of een windows tooltje je veel verder gaat helpen.
Gebruik je Linux voor de datarecovery ? Ik zou dan gewoon dat /home filesystem eens mounten, en dan gewoon alle bestanden proberen te lezen, dan zie je vanzelf op welk bestand het fout gaat.
Je hebt al een kopie, dus wellicht zoiets:

code:

 # find -type f /home |xargs cat > /dev/null

[hcQd]

Als het ext4 is: met het icheck commando van debugfs om de inode te vinden, en vervolgens ncheck om te zien welke file daarachter zit.

[ Voor 43% gewijzigd door hcQd op 12-12-2017 17:01 ]

[Lucky Luke 008]

Dank jullie wel voor de tip over icheck en ncheck Zonder de goede zoektermen te weten had ik dat niet gevonden.

Ik heb geprobeerd ermee aan de slag te gaan, maar in plaats van ze op een device los te kunnen laten zit ik met een image file van een device.

Allereerst heb ik met wat verder rondzoeken sleuthkit gevonden, waarmee met mmls pad/naar/en/naam_van_imagefile -B te onderzoeken valt welke partities er in zitten, om vervolgens die info te gebruiken om de getroffen partitie te mounten.

(https://blog.cadena-it.co...y-with-ddrescue-on-linux/ heeft iemand anders notities gemaakt van een dergelijk proces, en met de manpages heb ik achterhaald wat die commando's daadwerkelijk doen. Z'n -b moet een -B zijn...)

$ mmls /pad/naar/image.img -B
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

Slot Start End Length Size Description
00: Meta 0000000000 0000000000 0000000001 0512B Safety Table
01: ----- 0000000000 0000002047 0000002048 1024K Unallocated
02: Meta 0000000001 0000000001 0000000001 0512B GPT Header
03: Meta 0000000002 0000000033 0000000032 0016K Partition Table
04: 00 0000002048 0000821247 0000819200 0400M Basic data partition
05: 01 0000821248 0001353727 0000532480 0260M EFI system partition
06: ----- 0001353728 0413945855 0412592128 0196G Unallocated
07: 05 0413945856 0465242399 0051296544 0024G
08: ----- 0465242400 0465244159 0000001760 0880K Unallocated
09: 07 0465244160 0922054655 0456810496 0217G
10: 06 0922054656 0938610687 0016556032 0007G
11: 04 0938610688 0976773119 0038162432 0018G Basic data partition

De schade zit dus in slot 9, wat inderdaad mijn ext4 /home partitie is. (7 was /, 6 is inderdaad 196 GB lege ruimte, dat wilde ik nog bij /home trekken maar die schijf ging stuk voor ik kans zag dat te doen)

Die homepartitie kan ik nu ook mounten:

# mkdir /media/montagepunt
# mount -o loop,offset=238205009920 /pad/naar/image.img /media/montagepunt/

Vervolgens kan ik mijn bestanden zien op media/montagepunt.

Vervolgens kom ik er nog niet helemaal uit met debugfs.

Uit de debugfs manpage: (man debugfs)
[quote]
icheck block ...
Print a listing of the inodes which use the one or more blocks
specified on the command line.
[/quote
Ik vermoed echter dat ik debugfs ook moet vertellen welk filesysteem ik dit van wil weten. Er is een "open" commando:

open [-weficD] [-b blocksize] [-s superblock] [-z undo_file] device
Open a filesystem for editing. The -f flag forces the filesys‐
tem to be opened even if there are some unknown or incompatible
filesystem features which would normally prevent the filesystem
from being opened. The -e flag causes the filesystem to be
opened in exclusive mode. The -b, -c, -i, -s, -w, and -D
options behave the same as the command-line options to debugfs.

Maar dat is bedoeld voor devices... Dus ik kan dat niet verwijzen naar /media/montagepunt:

$ sudo debugfs
debugfs 1.43.4 (31-Jan-2017)
debugfs: open /media/montagepunt
/media/montagepunt: Is a directory while opening filesystem
debugfs:
debugfs: ^D

Dat klopt, het ís een directory. Maar ik wil het eigenlijk benaderen als een device, zodat ik icheck (en ncheck) kan doen.

Kan dat? Weet een van jullie hoe? (Of is er een andere manier om iets als icheck op een directory los te laten?)

(/media/montagepunt is de directory waar het relevante deel van de imagefile gemount zit. Misschien kan ik dat stuk imagefile benaderen alsof het een device is, zonder te mounten, maar hoe?)


tldr; Ik zit vast bij icheck, omdat dat een device wil zien en ik een directory heb (Waar een deel van een image van een device is gemonteerd).

EDIT:
het antwoord van u_nix_we_all moet ik nog proberen... Dat lijkt eigenlijk veel handiger, ik zit te slapen...

[White Feather]

Weet je trouwens wel zeker dat er corrupte data op staat?
Normaliter ziet een schijf dat er sectoren slechter worden dan worden die sectoren gerelocate naar reserve sectoren. De slechte sectoren worden dan gemarkeerd.

En zou je niet alle files kunnen kopiëren naar een andere schijf? Welke hij dan aangeeft als niet te kopiëren omdat hij ze niet kan lezen, zijn de foute.

[Daedalus]

Je kunt met losetup block devices van de partities in je image maken (zie Reading a filesystem from a whole disk image). Vervolgens kun je met debugfs /dev/loopXpY (waarbij X het loop device is en Y de partitienummer) het filesysteem uitlezen (er vanuitgaande dat het EXT2/3/4 is). Als de superblock niet beschadigd is, kun je met stats uitvogelen wat de block size is, en vervolgens welk block nummer bij de beschadigde sector hoort.

[Lucky Luke 008]

Ik heb toch even de moeilijke route gekozen (Met debugfs), gewoon, om misschien per ongeluk wat te leren over filesystems.

$ cd pad/naar
$ sudo losetup -f -r -L -v -o 238205009920 image.img

Nu heb ik /dev/loop0 die ik eventueel kan mounten (Om te zien dat ik inderdaad het goede stuk van mijn image heb, wat inderdaad zo bleek te zijn, dus weer ge-u(n)mount om met debugfs aan de slag te gaan).

debugfs: stats geeft heel veel informatie, waaronder

Block size: 4096

Zijn dat 4096 bytes, of 4096 sectoren? Ik neem voorlopig aan bytes.

Vervolgens dus icheck

debugfs: icheck 0x542B1FF002
Block Inode number
361500766210 <block not found>

(Overigens met 0x542B1FF000 krijg ik ook <block not found>, zei het uiteraard 2 blocks eerder)

Righto. Wat ik er nu in stop is een hoeveelheid bytes en het wil een blocknummer, dus delen door de blocksize zou dan het blocknummer moeten geven, en dan zou het toch wat moeten vinden...

4096 is 0x1000. 0x542B1FF000 / 0x1000=542B1FF

debugfs: icheck 0x542B1FF
Block Inode number
88257023 <block not found>

Hmmz.

debugfs: icheck 0x542B200
Block Inode number
88257024 <block not found>
debugfs: icheck 0x542B201
Block Inode number
88257025 <block not found>

Wat moet ik hier van maken? Betekend dit, dat ik iets fout doe (bijv. met de berekening van het blocknummer) waardoor 'ie het block niet kan vinden?

Of betekend het dat dit blok in geen enkele inode wordt gebruikt en dus in geen enkel bestand zit?

(If so, is er een manier om dit te proberen met een block dat geheid in een inode zit zodat 'ie iets móet vinden? Zodat ik zeker weet dat ik de commando's goed toepas)

[ Voor 5% gewijzigd door Lucky Luke 008 op 16-12-2017 12:32 ]

[Thralas]

Lucky Luke 008 schreef op donderdag 14 december 2017 @ 00:25:
Allereerst heb ik met wat verder rondzoeken sleuthkit gevonden, waarmee met mmls pad/naar/en/naam_van_imagefile -B te onderzoeken valt welke partities er in zitten, om vervolgens die info te gebruiken om de getroffen partitie te mounten.

fdisk en gdisk lusten ook gewoon een file - dat leest een stuk handiger dan mmls wmb.

EDIT:
het antwoord van u_nix_we_all moet ik nog proberen... Dat lijkt eigenlijk veel handiger, ik zit te slapen...

Daar heb je niets aan. Als de bad sector in data zit dan vertelt het je niets (ext houdt immers geen checksums bij) - als het in metadata zit dan zou fsck je dat ook wel moeten kunnen vertellen, maar dan beter en sneller.

Ik heb toch even de moeilijke route gekozen (Met debugfs), gewoon, om misschien per ongeluk wat te leren over filesystems.

Heel goed

Nu heb ik /dev/loop0 die ik eventueel kan mounten (Om te zien dat ik inderdaad het goede stuk van mijn image heb, wat inderdaad zo bleek te zijn, dus weer ge-u(n)mount om met debugfs aan de slag te gaan).

Als je -P met losetup gebruikt dan doet de kernel een partscan en krijg je loopXpY devices voor individuele partities. Handiger dan handmatig de offset berekenen..

Zijn dat 4096 bytes, of 4096 sectoren? Ik neem voorlopig aan bytes.

Bytes lijkt me correct.

Wat moet ik hier van maken? Betekend dit, dat ik iets fout doe (bijv. met de berekening van het blocknummer) waardoor 'ie het block niet kan vinden?

Volgens mij maak je een cruciale fout.

Je ddrescue log offset is absoluut (start van de disk). Dat zul je om moeten rekenen naar de offset binnen de partiie. Even alle sector offsets minus de partition offset nemen dus.

(If so, is er een manier om dit te proberen met een block dat geheid in een inode zit zodat 'ie iets móet vinden? Zodat ik zeker weet dat ik de commando's goed toepas)

Ja. Zie de debugfs manpage. 'blocks' is vast handig.

[Lucky Luke 008]

Thanks! Ik was inderdaad de partitie-offset vergeten.

(
Daarvoor zou inderdaad die -P optie handig geweest zijn ja, zoals bij https://unix.stackexchang...m-from-a-whole-disk-image genoemd. Ik heb dat geprobeerd, maar zonder

If you can, make sure your loop driver supports and is loaded with the max_parts option; you may need to run rmmod loop; modprobe loop max_part=63.

Dan kreeg ik alleen een /dev/loop0, die ik ook niet als loop0p ... (loop0p6 bijvoorbeeld) kon benaderen. Dus toen heb ik maar de -o optie gebruikt omdat ik de offset toch al bepaald had... Leek eenvoudiger.
)

Anyway.

0x542B1FF000 - 238205009920(dec) = 238205009920 (dec, bytes vanaf start partitie)

0x542B1FF000 is waar het slechte block begint, of eigenlijk 8 slechte sectoren maar dat is toevallig 1 block.
(Om gelijk White feather te beantwoorden: Ja, ik weet zeker dat ik corrupte data heb had, die sectoren stonden als "nog opnieuw in te delen" (Pending sectors), en dat herindelen is niet gebeurd omdat ik er niet naar geschreven heb, omdat ik niet meer kon lezen welke data er hoorde te staan.)

(38205009920 is de partitie-offset, maar die is al in decimaal. Het antwoord heb ik ook maar weer decimaal gehouden)

Dat is echter in bytes, dus omgerekend naar blocks:

238205009920 / 4096 = 30101503 blocks vanaf start partitie.

Dan icheck:

debugfs: icheck 30101503
Block Inode number
30101503 5637115

En omdat ik mezelf niet genoeg vertrouw betreffende off-by-one, ook even de blocks ernaast:

debugfs: icheck 30101503
Block Inode number
30101503 5637115
debugfs: icheck 30101504
Block Inode number
30101504 5782224
debugfs: icheck 30101502
Block Inode number
30101502 5637115

Joepie. Deze blocks horen inderdaad inodes bij. Nu eens kijken of ik daar(mee) een beschadigde file kan vinden.

Inode 5637115 en 5782224 zijn dus interessant (De eerste het meest interessant, want die zou bij het beschadigde file moeten horen)

debugfs: ncheck 5637115
Inode Pathname
5637115 /Luke/Opslag/datasheets/tektronix_465b_sm.pdf
debugfs: ncheck 5782224
Inode Pathname
5782224 /Luke/arduino-1.8.4/hardware/esp8266com/esp8266/tools/xtensa-lx106-elf/bin/xtensa-lx106-elf-gdb

Goed. Dan zou dus tektronix_465b_sm.pdf beschadigd moeten zijn. (Service Manual van een tektronix 465b oscilloscoop, voor de duidelijkheid).

Ik heb dat bestand dus opgezocht, en het valt inderdaad niet te openen!
("document bevat geen pagina's" is de waarschuwing die evince geeft).

We hebben dus het corrupte bestand gevonden! Dank jullie wel!

Omdat ik verder geen slechte sectoren had, hoop ik dat het ook bij dit ene bestand gebleven is.

Nadeel: Het bestand dat ik heb geprobeerd te openen, wat dus stuk was, kwam uit mijn backup. Die dus blijkbaar ook al stuk was en ik heb daar nooit een waarschuwing over gehad. Alleen door zelf naar S.M.A.R.T te kijken en daar te zien dat mijn disk stuk aan het gaan was (8 pending sectors) ben ik er achter gekomen. (Terzijde heb ik op die manier dus weinig aan een backup, als er stilletjes op de achtergrond dingen stuk kunnen gaan zonder waarshuwing. Backup staat ook nog 's op een USB drive die dus niet aan SMART doet... En bij kopieren/lezen dus geen waarschuwing gehad dat het bestand niet leesbaar zou zijn...)

Voordeel: Die service manual valt opnieuw te downloaden en wel hier. (Als het niet opnieuw te downloaden viel, was het eerder geweest dan of overigens, al ben ik alsnog liever een datasheet of servicemanual kwijt dan -zeg- een pcbontwerp of een foto.)

Het andere bestand zou ten eerste niet stuk moeten zijn, en is ten tweede ook gewoon opnieuw downloadbaar. (Arduino opnieuw instaleren, board files opnieuw installeren, doe ik wel een keer als ik weer wat met ESPtjes ga knoeien)

(Om "blocks" te kunnen gebruiken had ik eerst een filenaam nodig gehad, ik wilde echter precies het omgekeerde: uitzoeken welk file bij een slecht blok hoorde... Oh, wacht, om te testen had ik inderdaad een bestaand file kunnen kiezen om zo het blocknummer op te zoeken... *Probeert* --- Whoa, dat zijn heel wat blokjes... ('t is een PDF van 40+ MB...) )

Anyway, dank jullie wel voor de hulp bij het vinden van het defecte bestand.

(Nu heeft mijn vader ook nog een defecte disk, maar hij wil alleen z'n files terug, dus daar zou ik het moeten redden met alleen ddrescue zonder de extra speurtocht achteraf. Ik heb in elk geval vast kunnen oefenen op mijn eigen data. Had ik natuurlijk andersom moeten doen .)

(Nu zou ik het beste antwoord moeten markeren, maar eigenlijk is een combinatie van alle antwoorden die tot een oplossing heeft geleid...)

[Thralas]

Goed gewerkt!

Om corruptie te kunnen detecteren zou ik btrfs overwegen; bovendien backuppen snapshots erg gemakkelijk. Mocht je dat ooit uit willen bouwen naar een multi-disk setup dan is ZFS weer erg interessant.