Fórum Root.cz
Hlavní témata => Software => Téma založeno: wakatana 04. 05. 2020, 00:23:02
-
Pekny den,
Snazim sa obnovit data z NTFS disku, disk sa sklada z 3 particii:
sdc1 - 1.5 GB - toto ma nezaujima
sdc2 - 116 GB - particia ide precitat vo Windows aj Linux a teda data z nej som uz zalohoval
sdc3 - 115 GB - z tejto particie potrebujem dostat data - vo Windows ani v Linuxe nejde precitat
Ak spravne chapem vypis z ddrescue tak bol schopny skopirovat 99.9% dat z sdc3.
Taktiez photorec bol schopny obnovit cca 95 GB obrazkov a videii - v obnovencych datach je ale pekny gulas (vsetko v jednom adr.), preto by som sa rad dostal ku strukturovanejsej podobe.
Povodne som skusal aj testdisk avsak ten nenasiel ziadnu inu particiu okrem tych ktore tam uz su, a na sdc3 mi nevylistoval ziadne subory.
Myslim ze disk je teda po fyzickej stranke OK, a zrejme je nejakym sposobom poskodeny file system.
Zatial som teda urobil nasledovne:
- vytvoril image z sdc3 cez ddrescue
- spustil ntfsfix nad sdc3
- spustil chkdsk nad sdc3
- cez photorec vytiahol data z sdc3
Co mozem este vyskusat? Ma zmysel skusit napr gpart (nemylit s gparted)?
Viem si nejakym sposobom urychlit nasledne analyzi v dlasich nastrojoch (vyuzit log z ddrescue a pod?)
Po tomto mi NTFS nepride moc spolahlivy (ano viem treba zalohovat), aky je Vas nazor, je lepsie pouzit ext4 alebo radsej BTRFS resp ZFS ?
Dakujem za kazdu radu, nizsie pripajam vypisy
#################################################
[root@sysresccd /mnt/sda2/HTS543225L9SA00_250GB]# fdisk -l /dev/sdc
Disk /dev/sdc: 232.91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: HTS543225L9SA00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x2fc1518f
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 3074047 3072000 1.5G 27 Hidden NTFS WinRE
/dev/sdc2 * 3074048 246945791 243871744 116.3G 7 HPFS/NTFS/exFAT
/dev/sdc3 246945792 488395119 241449328 115.1G 7 HPFS/NTFS/exFAT
#################################################
[root@sysresccd /mnt/sda2/HTS543225L9SA00_250GB]# ddrescue -d -r3 /dev/sdc3 sdc3.img sdc3.logfile
GNU ddrescue 1.25
Press Ctrl-C to interrupt
ipos: 19302 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 19302 MB, non-scraped: 0 B, average rate: 16856 kB/s
non-tried: 0 B, bad-sector: 11776 B, error rate: 128 B/s
rescued: 123622 MB, bad areas: 5, run time: 2h 2m 14s
pct rescued: 99.99%, read errors: 101, remaining time: 28m
time since last successful read: 50s
Finished
#################################################
root@sysresccd ~]# ntfsfix /dev/sdc3
Mounting volume... ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read of MFT, mft=6 count=1 br=-1: Input/output error
Failed to open inode FILE_Bitmap: Input/output error
FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read of MFT, mft=6 count=1 br=-1: Input/output error
Failed to open inode FILE_Bitmap: Input/output error
Remount failed: Input/output error
#################################################
[root@sysresccd /mnt/sda2]# mount /dev/sdc3 /mnt/sdc3
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read of MFT, mft=6 count=1 br=-1: Input/output error
Failed to open inode FILE_Bitmap: Input/output error
Failed to mount '/dev/sdc3': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
#################################################
c:\Users\ledgo\Desktop>chkdsk /F g:
The type of the file system is NTFS.
Volume label is Multimedia.
Stage 1: Examining basic file system structure ...
File record segment 5 is unreadable.
File record segment 6 is unreadable.
File record segment 7 is unreadable.
File record segment 1F is unreadable.
File record segment 1C6 is unreadable.
File record segment 1C7 is unreadable.
38400 file records processed.
File verification completed.
1 large file records processed.
6 bad file records processed.
An unspecified error occurred (766f6c756d652e63 470).
#################################################
# TOTO JE VYSTUP Z GPARED PO TOM CO SOM DAL CHECK SDC3
Check and repair file system (ntfs) on /dev/sdb3 00:00:10 ( ERROR )
calibrate /dev/sdb3 00:00:02 ( SUCCESS )
path: /dev/sdb3 (partition)
start: 246945792
end: 488395119
size: 241449328 (115.13 GiB)
check file system on /dev/sdb3 for errors and (if possible) fix them 00:00:08 ( ERROR )
ntfsresize -i -f -v '/dev/sdb3' 00:00:08 ( ERROR )
ntfsresize v2017.3.23 (libntfs-3g)
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read of MFT, mft=6 count=1 br=-1: Input/output error
Failed to open inode FILE_Bitmap: Input/output error
ERROR(5): Opening '/dev/sdb3' as NTFS failed: Input/output error
NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
The usage of the /f parameter is very IMPORTANT! No modification was
and will be made to NTFS by this software until it gets repaired.
-
NTFS je spolehlivý a dobrý filesystem pro Windows. V Linuxu má smysl Ext4, nebo, pokud je pro to použití, tak ZFS či Btrfs.
Na obnovu dat vždy dobře fungovalo: https://www.runtime.org/data-recovery-software.htm
-
Co ti napise dmesg kdyz udelas mount -o loop ?
Ja obnovoval 1TB disk, z image ve kterem bylo taky poskozeni, ale chce to jit do struktur systemu a vedet jak FS funguje.
Neco jako zazracny samocinny tool neexistuje.. stejne jako kdyz se ti pokazi pracka, tak neexistuje "repair praci prasek", ktery staci nalit a ona se zprovozni :-)
-
Co ti napise dmesg kdyz udelas mount -o loop ?
Ja obnovoval 1TB disk, z image ve kterem bylo taky poskozeni, ale chce to jit do struktur systemu a vedet jak FS funguje.
Neco jako zazracny samocinny tool neexistuje.. stejne jako kdyz se ti pokazi pracka, tak neexistuje "repair praci prasek", ktery staci nalit a ona se zprovozni :-)
Po tom co mountujem image v dmesg nieje nic
[root@sysresccd /mnt/sda2/HTS543225L9SA00_250GB]# mount -o ro,loop sdc3.img /mnt/img
ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 1024 usa_ofs: 0 usa_count: 0: Invalid argument
Record 6 has no FILE magic (0x0)
Failed to open inode FILE_Bitmap: Input/output error
Failed to mount '/dev/loop1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
avsak ked skusam mountovat priamo disk tak je tam toto:
[root@sysresccd /mnt/sda2/HTS543225L9SA00_250GB]# mount -o ro /dev/sdb3 /mnt/sdb3/
ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read of MFT, mft=6 count=1 br=-1: Input/output error
Failed to open inode FILE_Bitmap: Input/output error
Failed to mount '/dev/sdb3': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
[ 1891.633163] sd 6:0:0:0: [sdb] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1891.633187] sd 6:0:0:0: [sdb] tag#16 Sense Key : Hardware Error [current]
[ 1891.633193] sd 6:0:0:0: [sdb] tag#16 Add. Sense: Internal target failure
[ 1891.633198] sd 6:0:0:0: [sdb] tag#16 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 1891.633205] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 1895.724420] sd 6:0:0:0: [sdb] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1895.724440] sd 6:0:0:0: [sdb] tag#17 Sense Key : Illegal Request [current]
[ 1895.724444] sd 6:0:0:0: [sdb] tag#17 Add. Sense: Invalid field in cdb
[ 1895.724449] sd 6:0:0:0: [sdb] tag#17 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 1895.724453] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0
[ 1895.724459] Buffer I/O error on dev sdb3, logical block 6291464, async page read
[ 1895.724464] Buffer I/O error on dev sdb3, logical block 6291465, async page read
[ 1895.724467] Buffer I/O error on dev sdb3, logical block 6291466, async page read
[ 1895.724471] Buffer I/O error on dev sdb3, logical block 6291467, async page read
[ 1895.724474] Buffer I/O error on dev sdb3, logical block 6291468, async page read
[ 1895.724477] Buffer I/O error on dev sdb3, logical block 6291469, async page read
[ 1895.724480] Buffer I/O error on dev sdb3, logical block 6291470, async page read
[ 1895.724483] Buffer I/O error on dev sdb3, logical block 6291471, async page read
-
Nebyl náhodou ten NTFS přeplněný? Byl jsem překvapený, jak snadno se naboří systém pouhým zaplněním na 100%. Tuším, že to byl také NTFS (už je to delší dobu).
-
Nebyl náhodou ten NTFS přeplněný? Byl jsem překvapený, jak snadno se naboří systém pouhým zaplněním na 100%. Tuším, že to byl také NTFS (už je to delší dobu).
Myslim ze na 100% nebol. Mozno nejakych 90-95 tazko povedat. Cisto teoreticky keby bol preplneny tak je sposob ako potom z neho dostat data?
Medzicasom som skusil gparted: Device -> Attempt Data Rescue ... ktory vola spominany gpart. Tato operacia mi zobrazila 3 existujuce particie ale ked som dal view na particii ktoru sa snazim obnovit operacia skoncila s chybou. V dmesg toho priubudlo hodne
[ 2179.844968] sd 6:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2179.844995] sd 6:0:0:0: [sdb] tag#18 Sense Key : Hardware Error [current]
[ 2179.845000] sd 6:0:0:0: [sdb] tag#18 Add. Sense: Internal target failure
[ 2179.845005] sd 6:0:0:0: [sdb] tag#18 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2179.845010] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 2183.991761] sd 6:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2183.991793] sd 6:0:0:0: [sdb] tag#19 Sense Key : Illegal Request [current]
[ 2183.991801] sd 6:0:0:0: [sdb] tag#19 Add. Sense: Invalid field in cdb
[ 2183.991809] sd 6:0:0:0: [sdb] tag#19 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2183.991818] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2183.991827] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2183.991913] blk_update_request: I/O error, dev loop1, sector 6291464 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 2188.114088] sd 6:0:0:0: [sdb] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2188.114092] sd 6:0:0:0: [sdb] tag#4 Sense Key : Illegal Request [current]
[ 2188.114095] sd 6:0:0:0: [sdb] tag#4 Add. Sense: Invalid field in cdb
[ 2188.114097] sd 6:0:0:0: [sdb] tag#4 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2188.114100] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2188.114104] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2188.114149] blk_update_request: I/O error, dev loop1, sector 6291464 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2188.114154] Buffer I/O error on dev loop1, logical block 6291464, async page read
[ 2192.247642] sd 6:0:0:0: [sdb] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2192.247667] sd 6:0:0:0: [sdb] tag#16 Sense Key : Illegal Request [current]
[ 2192.247673] sd 6:0:0:0: [sdb] tag#16 Add. Sense: Invalid field in cdb
[ 2192.247680] sd 6:0:0:0: [sdb] tag#16 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2192.247688] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2192.247695] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2192.247815] blk_update_request: I/O error, dev loop1, sector 6291465 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2192.247821] Buffer I/O error on dev loop1, logical block 6291465, async page read
[ 2196.358938] sd 6:0:0:0: [sdb] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2196.358958] sd 6:0:0:0: [sdb] tag#5 Sense Key : Illegal Request [current]
[ 2196.358965] sd 6:0:0:0: [sdb] tag#5 Add. Sense: Invalid field in cdb
[ 2196.358971] sd 6:0:0:0: [sdb] tag#5 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2196.358979] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2196.358987] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2196.359080] blk_update_request: I/O error, dev loop1, sector 6291466 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2196.359087] Buffer I/O error on dev loop1, logical block 6291466, async page read
[ 2200.481304] sd 6:0:0:0: [sdb] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2200.481308] sd 6:0:0:0: [sdb] tag#17 Sense Key : Illegal Request [current]
[ 2200.481311] sd 6:0:0:0: [sdb] tag#17 Add. Sense: Invalid field in cdb
[ 2200.481314] sd 6:0:0:0: [sdb] tag#17 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2200.481318] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2200.481322] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2200.481364] blk_update_request: I/O error, dev loop1, sector 6291467 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2200.481367] Buffer I/O error on dev loop1, logical block 6291467, async page read
[ 2204.570331] sd 6:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2204.570343] sd 6:0:0:0: [sdb] tag#18 Sense Key : Illegal Request [current]
[ 2204.570345] sd 6:0:0:0: [sdb] tag#18 Add. Sense: Invalid field in cdb
[ 2204.570348] sd 6:0:0:0: [sdb] tag#18 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2204.570351] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2204.570358] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2204.570393] blk_update_request: I/O error, dev loop1, sector 6291468 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2204.570396] Buffer I/O error on dev loop1, logical block 6291468, async page read
[ 2208.659451] sd 6:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2208.659466] sd 6:0:0:0: [sdb] tag#19 Sense Key : Illegal Request [current]
[ 2208.659471] sd 6:0:0:0: [sdb] tag#19 Add. Sense: Invalid field in cdb
[ 2208.659476] sd 6:0:0:0: [sdb] tag#19 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2208.659480] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2208.659486] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2208.659541] blk_update_request: I/O error, dev loop1, sector 6291469 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2208.659545] Buffer I/O error on dev loop1, logical block 6291469, async page read
[ 2212.737425] sd 6:0:0:0: [sdb] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2212.737440] sd 6:0:0:0: [sdb] tag#16 Sense Key : Illegal Request [current]
[ 2212.737445] sd 6:0:0:0: [sdb] tag#16 Add. Sense: Invalid field in cdb
[ 2212.737450] sd 6:0:0:0: [sdb] tag#16 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2212.737456] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2212.737462] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2212.737509] blk_update_request: I/O error, dev loop1, sector 6291470 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2212.737513] Buffer I/O error on dev loop1, logical block 6291470, async page read
[ 2216.826482] sd 6:0:0:0: [sdb] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2216.826500] sd 6:0:0:0: [sdb] tag#17 Sense Key : Illegal Request [current]
[ 2216.826507] sd 6:0:0:0: [sdb] tag#17 Add. Sense: Invalid field in cdb
[ 2216.826512] sd 6:0:0:0: [sdb] tag#17 CDB: Read(10) 28 00 0f 18 18 08 00 00 08 00
[ 2216.826519] blk_update_request: critical target error, dev sdb, sector 253237256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2216.826527] Buffer I/O error on dev sdb, logical block 31654657, async page read
[ 2216.826594] blk_update_request: I/O error, dev loop1, sector 6291471 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 2216.826601] Buffer I/O error on dev loop1, logical block 6291471, async page read
-
Nebyl náhodou ten NTFS přeplněný? Byl jsem překvapený, jak snadno se naboří systém pouhým zaplněním na 100%. Tuším, že to byl také NTFS (už je to delší dobu).
inac, nejde mi celkom do hlavy ako je mozne ze sa NTFS len tak pokazi ked disk vyzera byt ze je po fyzckej stranke OK (vid testdisk/ddrescue)
-
inac, nejde mi celkom do hlavy ako je mozne ze sa NTFS len tak pokazi ked disk vyzera byt ze je po fyzckej stranke OK (vid testdisk/ddrescue)
Pokud jste na něj střídavě přistupoval z Windows a Linuxu, úplně bych se tomu nedivil. Jelikož se stále ze strany linuxové implementace jedná dost o reverse engineering (zdrojáky nějaké verze NTFS z dob Windows NT se najít dají, ale je to přece jen dávno), takže se některé změny Windows nemusí úplně pozdávat a pokusí se o "automatickou opravu".
Co se týče obnovy dat... zkoušel jste program Recuva?
-
Nedávno jsem někomu amatérsky zachraňoval omylem přeformátovaný disk (Windows only, Linux v tom prsty neměl) - na disku byly dva začátky oddílu na dvou různých offsetech :-( Než jsem to provedl naostro, zkoumal jsem trial verze softů Recuva, EaseUS a GetDataBack - schopnostmi na celé čáře vyhrál EaseUS, druhý co do úspěšnosti byl teoreticky GetDataBack (ale ještě pomalejší než Recuva, která byla na 3-4TB disku ohavně pomalá). EaseUS byl nejschopnější a nejrychlejší.
Ty hlášky v dmesg vypadají dost hrůzostrašně, přesto se nejedná o jasnou "media failure". Možná bych zkusil zkontrolovat/vyměnit SATA kabel. A obnovu pomocí EaseUS provádět na kopii, kterou pořídíte DDčkem na zdravý disk o shodné či větší kapacitě. Pokud větší, tak si být jistý, že ve zbývajícím místě nejsou nějaké halušky, které by EaseUS taky našel - případně cílový disk před DDčkováním přepsat nulami (DDčkem z /dev/zero).
Výsledek/úspěšnost konkrétního softu může záležet taky na formátu souborů, které obnovujete. V mém případě se jednalo o fotky (v JPEGu a dalších formátech) a video (v různých kontejnerech). Podle mého EaseUS měl citelně pokročilejší heuristiku pro rekonstrukci dat. Našel nejvíc souborů a poskládal nejvíc poztrácených adresářů.
-
Nebyl náhodou ten NTFS přeplněný? Byl jsem překvapený, jak snadno se naboří systém pouhým zaplněním na 100%. Tuším, že to byl také NTFS (už je to delší dobu).
inac, nejde mi celkom do hlavy ako je mozne ze sa NTFS len tak pokazi ked disk vyzera byt ze je po fyzckej stranke OK (vid testdisk/ddrescue)
Koukněte, zda se Vám nebude hodit něco z tohoto: https://www.abclinuxu.cz/poradna/hardware/show/410372
-
Nedávno jsem někomu amatérsky zachraňoval omylem přeformátovaný disk (Windows only, Linux v tom prsty neměl) - na disku byly dva začátky oddílu na dvou různých offsetech
Toto ma celkom zaujima, ako ste zistili ze tomu tak je?
Než jsem to provedl naostro, zkoumal jsem trial verze softů Recuva, EaseUS a GetDataBack - schopnostmi na celé čáře vyhrál EaseUS, druhý co do úspěšnosti byl teoreticky GetDataBack (ale ještě pomalejší než Recuva, která byla na 3-4TB disku ohavně pomalá). EaseUS byl nejschopnější a nejrychlejší.
Mozete prosim povedat blizsie o ake verzie islo? Od EaseUS som zatial skusil Partition Recovery Trial - A ten nedokaze pracovat s image. Jedina moznost by bola ako pisete zapisat data na iny disk. Ked som pustil nad spominanym diskom analyzu cez tento software tak sice trvala par minut ale bez nejakeho pouzitelneho vysledku.
Ty hlášky v dmesg vypadají dost hrůzostrašně, přesto se nejedná o jasnou "media failure". Možná bych zkusil zkontrolovat/vyměnit SATA kabel.
Mozem sa opytat co by vyzeralo viac hrozostrasne? a o com tieto hlasky vlastne hovoria? Chapem ze topicaci sa slamky chyta, ale ma zmysel menit sata kabel ked ddrescue skopiroval disk na 99%?
Co se týče obnovy dat... zkoušel jste program Recuva?
Dakujem za odpoved, neskusal, mozete mi prosim prezradit konkretne ktoru verziu?
Koukněte, zda se Vám nebude hodit něco z tohoto: https://www.abclinuxu.cz/poradna/hardware/show/410372
Vyzera zaujimavo dakujem
-
Dakujem za odpoved, neskusal, mozete mi prosim prezradit konkretne ktoru verziu?
Recuvu používám poměrně dlouho (nejdříve jsem používal free verzi, později jsem jim ty peníze dal, neb jsem dospěl k závěru, že si je zaslouží) a nikdy mě v zásadě nezklamala.
EaseUS Partition Manager jsem před lety (10?) zkoušel myslím na defragmentaci (či něco podobného) a skončilo to dost katastrofou (poškozený FS); od té doby jsem jej neměl potřebu používat (viz předchozí odstavec).
Nedávno jsem někomu amatérsky zachraňoval omylem přeformátovaný disk (Windows only, Linux v tom prsty neměl) - na disku byly dva začátky oddílu na dvou různých offsetech
Nebylo to způsobeno tím, že NTFS boot sektor ($Boot) ukládá ve dvou kopiích?
-
Recuvu používám poměrně dlouho (nejdříve jsem používal free verzi, později jsem jim ty peníze dal, neb jsem dospěl k závěru, že si je zaslouží) a nikdy mě v zásadě nezklamala.
OK vyskusam a dam vediet, som ani nevedel ze Recuva ma nieco spolocne s ccleanerom. Posledne som zachytil ze ccleaneru infikovali binarky malwarom tak dufam ze si spolu s Recuva nenainstalujem aj ransomware, to potom asi tazko nieco obnovim :D
-
OK vyskusam a dam vediet, som ani nevedel ze Recuva ma nieco spolocne s ccleanerom. Posledne som zachytil ze ccleaneru infikovali binarky malwarom tak dufam ze si spolu s Recuva nenainstalujem aj ransomware, to potom asi tazko nieco obnovim :D
O tom, že má něco společného s CCleanerem, nic nevím. Jestli jej nabízí při instalaci, tak jej zkrátka neinstalujte.
K infekci binárek CCleaneru došlo pár let zpátky přímo na buildovacím stroji společnosti, která jej vyvíjela. Podle popisu incidentu z interního zdroje mi přišla reakce Avastu (který tu firmu tehdy vlastnil a snad pořád vlastní) adekvátní (myslím, že jiné firmy by tak silná opatření ani neprovedly).
-
O tom, že má něco společného s CCleanerem, nic nevím. Jestli jej nabízí při instalaci, tak jej zkrátka neinstalujte.
Tento Recuva (http://www.ccleaner.com/recuva) mam na mysli neviem ci je aj nejaky iny.
-
Nedávno jsem někomu amatérsky zachraňoval omylem přeformátovaný disk (Windows only, Linux v tom prsty neměl) - na disku byly dva začátky oddílu na dvou různých offsetech
Toto ma celkom zaujima, ako ste zistili ze tomu tak je?
Nepamatuju si podrobnosti, bylo to cca v září 2019 a co mám asi stránku zápisků, týkají se vlastně jenom recenze těch wokenních recovery softů.
Určitě jsem začal DDčkem na druhý disk stejný nebo větší. Zmrvené disky byly dva, 3TB a 4TB. Náhradní jsem měl 4TB.
Protože je to nad 2 TB, nestačila mi historická znalost BIOS partition table, ale musel jsem si nepatrně osvěžit vědomosti ohledně GPT. Rozhodně byla v MBR obvyklá "falešná/předsunutá/držhubná" partition table, která obsahuje jenom odkaz na GPT - ta je o kus dál. A je možné, že jsem měl na disku dvě verze už GPT. Nehrabal jsem se v tom kdovíjak do hloubky rukama, používám čerstvé verze linuxových "variant fdisku", z nichž značná část už GPT umí. Pochopitelně z MBR vede odkaz jenom na tu "nově vytvořenou GPT". Je možné, že jsem druhou/starou GPT ani nezkoumal. Ono na ní ostatně moc nezáleží, na celém disku byl vždycky jenom jeden oddíl - a kýžená informace je začátek NTFS oddílu (boot sektor), který se dá najít i přímo, možná snáz než GPT. Tuším bajt 3-6 (počítáno od nuly) obsahují řetězec "NTFS" a v posledních dvou bajtech ultra-klasicky 55AA hexa. Myslím že jsem zašel tak daleko, že jsem si zkusmo zkopíroval prvních pár megabajtů diskového prostoru DDčkem do image souboru a zkoušel jsem do toho koukat hexaeditorem, nejdostupnější je asi ten v Midnight Commanderu, umí vyhledat hexa sekvenci. No a tím ruční práce asi zhruba skončila - našel jsem dva různé boot sektory, zvedl jsem ruce z klávesnice a zabručel jsem "tak pozor".
Následoval zmíněný průzkum trhu recovery toolů (trial verzí), už v režimu "klikající cvičená opice". A už netuším jestli všechny, ale určitě EaseUS mi rovnou řekl, že tam vidí dva různé začátky oddílů, a dokonce vyrobil dva různé seznamy nalezených souborů (které měly společnou podmnožinu, jak se později ukázalo). Takže než klepnete na "restore", musíte si vybrat, podle kterého z těch dvou seznamů se pojede.
Mimochodem... @Martin Dráb, jste si jistej, že NTFS má dvě kopie Boot Sektoru? Mám pocit, že Boot sektor je jenom jeden, jsou dvě kopie MFT - primární a náhradní, umístěné kdesi v prostoru oddílu. NTFS používá stromovou strukturu metadat, rozptýlenou po ploše oddílu - podobně jako UNIXové FS. MFT je IMO jakási analogie EXT2/3/4 "superblocku" (ten se ukládá tuším dokonce v několika kopiích). FAT FS si vede dvě kopie FAT, uložené těsně za sebou hned za boot sektorem... (což není náš případ).
Já jsem ty svoje dvě verze NTFS bootsektoru našel v prvních pár megabajtech. Ony totiž existují různé konvence, jak zarovnat oddíly na geometrii disku (tzn. kolik prostoru před prvním oddílem vyplýtvat zarovnáním). Třeba klasický legacy BIOS styl s bootsektorem prvního oddílu na LBA sektoru č.63, typicky s LBA sektorem o velikosti 512B (nultá stopa zůstane kromě MBR prázdná) vs. zarovnání na nějaké "binárně kulaté číslo", typicky s LBA sektorem o velikosti 4 kB na moderních discích a flashkách - čímž se promrhá třeba první megabajt. Ale ono těch konvencí je zřejmě víc, moderní OS a třeba i různé verze Windows používají různé zarovnání i v rámci kategorie "4kB sektory a binárně hezká geometrie", matně si něco vybavuju o existenci "vycpávkového oddílu" v GPT před prvním vlastním datovým oddílem apod.
Vlastník těch nabořených disků dokonce tvrdí, že jednoho dne přišel ráno do práce, a Win10 se po aktualizaci po rebootu spontánně rozhodly, že externí disky v USB kastlíku zformátují s novým rozložením partišen... čemuž jsem ochoten věřit jenom s určitou mírou pravděpodobnosti, menší než stoprocentní :-) Taky už jsem dřív zažil případ, že človíček vzal disky, které do té doby používal jednotlivě v jednoduchém USB šuplíku, a vrazil je do levného RAIDového boxu pro dva disky, a představoval si, že ty disky uvidí tak jako dřív... a RAIDový box na tom vyrobil mirror a posunul začátek prezentovaný Windowsům a průser byl na světě... tehdy stačilo na discích odhadem vyrobit novou GPT, která odpovídala původní skutečnosti. Tentokrát jsem takové štěstí neměl.
Než jsem to provedl naostro, zkoumal jsem trial verze softů Recuva, EaseUS a GetDataBack - schopnostmi na celé čáře vyhrál EaseUS, druhý co do úspěšnosti byl teoreticky GetDataBack (ale ještě pomalejší než Recuva, která byla na 3-4TB disku ohavně pomalá). EaseUS byl nejschopnější a nejrychlejší.
Mozete prosim povedat blizsie o ake verzie islo? Od EaseUS som zatial skusil Partition Recovery Trial - A ten nedokaze pracovat s image. Jedina moznost by bola ako pisete zapisat data na iny disk. Ked som pustil nad spominanym diskom analyzu cez tento software tak sice trvala par minut ale bez nejakeho pouzitelneho vysledku.
V zápiscích čtu Recuva 1.53, EasUS 12.9.1, GetDataBack nemám napsané číslo verze. Každopádně všechny byly čerstvé v září 2019.
Měl jsem dva nabořené disky, a tuším ke každému dva náhradní, tzn. celkem čtyři náhradní. Po dohodě s vlastníkem, který věděl předem, že ty disky beztak obratem užije na větší objem úložiště. V prvním kroku jsem zkopíroval celý nabořený disk na první záložní. V druhém kroku EaseUS prohlásil, že zásadně nedělá in-place recovery, ale že je ochoten zachráněné soubory nakopírovat "někam jinam", asi by se dalo i na fileserver apod. Takže prostě dostal další disk, zformátovaný na NTFS :-)
Tyhle tooly mají většinou konfigurovatelnou "úroveň důkladnosti", a v defaultním nastavení víceméně projdou souborový systém od boot sektoru přes MFT a přeživší adresářovou strukturu, snad se snaží v těch metadatech něco hledat. Vy ale chcete zkusit hloubkový sken = úplně se vykašlat na stávající rozdělení disku a to co je na něm normálním způsobem vidět, a namísto toho hledat heuristicky po ploše disků poztrácené sekvence bloků. Je potřeba to v konfiguraci recovery toolu explicitně povolit. (Teď si nejsem jistý, jestli toto platí o EaseUS.) Hloubkový sken rozhodně netrvá pár minut - na 3TB disku trval v EaseUS cca "přes noc" (7 hodin), Recuva 20 hodin (a našla toho mnohem míň) a GetDataBack jel zpočátku snad ještě pomaleji než Recuva, ale nakonec dojel taky cca za 20 hodin. EaseUS točí diskem pořád. Ostatní dva většinu času nad něčím dumají a disk se fláká (občas mrkne). Přečíst celý disk sekvenčně od A do Z prostě trvá pár hodin. Pokud byl EaseUS během pár minut hotov, tak podle mého nemohl projít plochu disku "hloubkovým" způsobem.
EaseUS když skenuje, hlásí "nesmyslně" vysoký počet nalezených souborů. V mém případě zřejmě dva různé "náhledy" (protože dvě různé partišny) s velkým vzájemným překryvem, navíc zřejmě dost "crosslinkovaných" různě starých verzí souborů... prostě těsně před koncem skenu hlásil na 3TB disku průběžný stav 11.5 TB nalezených dat! Ovšem při obnově to zřejmě protřídí a velký počet "duchů" vynechá, ve finále obnovil asi 2.5 TB dat a vlastník tvrdil, že mu nejspíš nic nechybí. Nějaké crosslinkované soubory naházel bokem do adresáře viditelně označeného jako "další nalezené soubory a složky" - tyto jsou z větší části poškozené, ale jedná se zjevně o přízraky = starší a částečně přepsané verze jiných, úspěšně obnovených souborů.
Pokud skutečně EaseUS při hloubkovém skenu nic moc nenajde, může to mít různé příčiny: na Vaše formáty souborů nemá EaseUS vhodnou skenovací heuristiku (znalost), nebo jste nabořenému souborovému systému dále ublížil unáhleným použitím programu chkdsk, který opravuje metadata filesystému do konzistentního stavu tím způsobem, že uřízne a zahodí to, co mu nedává smysl... na tomhle serveru zřejmě dost lidí chápe pojem "fscked" :-) Věřím tomu, že hloubkový analyzátor by z poškozeného filesystému před chkdiskem vytěžil o něco víc.
Trial EaseUS je ochoten provést kompletní sken = i ten trial Vám dá poměrně přesnou představu, kolik se toho z disku dá zachránit. Dokonce se dá výsledek toho skenu ("mezistav obnovy") uložit na disk a později načíst. Trial ale obnoví jenom asi 2 GB dat. V mém případě si vlastník dat koupil licenci, a pak úspěšně proběhla kompletní obnova.
Recuva a CCleaner jsou podle mého dva různé softwarové produkty firmy Piriform, kterou v roce 2017 koupil Avast. Recuva na mě v září působila dojmem, že Avast dává zelenou spíš CCleaneru a Recuva chřadne. Ale mohlo se mezitím něco změnit, a můžu mít úsudek pomýlený konkrétním formátem datových souborů v mém případě = jedno pozorování není zrovna hodnotná statistika.
Ty hlášky v dmesg vypadají dost hrůzostrašně, přesto se nejedná o jasnou "media failure". Možná bych zkusil zkontrolovat/vyměnit SATA kabel.
Mozem sa opytat co by vyzeralo viac hrozostrasne? a o com tieto hlasky vlastne hovoria? Chapem ze topicaci sa slamky chyta, ale ma zmysel menit sata kabel ked ddrescue skopiroval disk na 99%?
...no je fakt, že já mám z dob svého mládí zafixované hlášky z linuxového IDE subsystému, jako "DriveReady SeekComplete Errror", což je ještě dost obecná chyba, ale bývala následovaná konkrétnějším kódem chyby.
Ty Vaše chybové hlášky se sypou ze SCSI vrstvy - kteroužto abstrakci už drahně let používá Linux a jeho moderní libata. Každopádně ta hláška nezní jako "sector not found" nebo "uncorrected error".
A máte pravdu, že nezní ani jako "CRC error" - kterážto chyba by poukazovala na nějaký analogový vakl v SATA data kabelu nebo konektory nebo HBA řadičem.
Ve Vašem případě "Illegal Request" a "Invalid field in CDB" (nedoprovázeno CRC errory, tzn. kontrolní součty na SATA/SCSI příkazech sedí) spíš vypadají, že ta chyba v CDB přišla od HBA a že vakl v datovém kabelu za to nemůže.
Našel jsem k této chybě zajímavou debatu na StackExchange (https://unix.stackexchange.com/questions/237204/filesystem-is-reporting-a-write-error-on-a-specific-sector-even-after-the-partit) = mohlo by to znamenat bug spojený s konkrétní značkou čipu SATA řadiče v Linuxu...
Hardware error / internal target failure vypadá o něco závažněji, ale ten popis závady není zrovna specifický. SCSI Target = koncové zařízení = disk nebo RAIDový řadič apod.