Mi-am mutat toate datele pe o unitate nouă și se pare că s-au pierdut. Vă rog să mă ajutați să recuperez datele.
Iată ce am făcut pentru ca problema să apară:
Am mutat, nu am copiat datele. (Prima greseala)
HDD-ul făcea zgomote când am mutat datele. Deoarece unitatea este nouă și toate valorile SMART arătau bine, nu m-am îngrijorat prea mult, dar poate ar fi trebuit?
Pentru a folosi datele, am conectat unitatea la o mașină Windows. (A doua greseala) Am încercat să folosesc DiskInternals LinuxReader pentru a putea citi formatul ext4. Unele fișiere erau lizibile, alte foldere au generat o eroare sau au apărut goale.
Am conectat unitatea la mașina Ubuntu originală, doar pentru a vedea aceleași rezultate.
Ce am încercat să repar:
Prima recomandare a fost de a face a dd
copie de rezervă a întregului disc. Am făcut asta.
Deși la verificarea după aceea cu df -h
discul original arăta 981G utilizat, iar copia arăta doar 80K în uz. Deci poate că ceva a mers prost acolo?
În această dimineață am încercat să continui după o repornire și dintr-o dată nu am reușit să montez niciun disc:
dispozitivul special /dev/sdb1/ nu există (un prefix de cale nu este un director).
Am încercat ceea ce a fost sugerat Aici și fugi sudo blockdev --rereadpt
pe ambele discuri, dar a rulat fără feedback și montarea nu a fost încă posibilă. Din moment ce am plănuit să folosesc e2fsck, nu m-am îngrijorat prea mult pentru asta, deoarece a trebuit să folosesc oricum un disc nemontat.
am fugit gdisk
cu r
pentru a ajunge la opțiunile de recuperare și apoi cu b
și c
pentru a citi și recupera tabelul de partiții din tabelul secundar. De cand v
nu am dat erori, am confirmat scrierea cu w
.
Din moment ce nu a funcționat, am încercat în sfârșit e2fsck
. Am confirmat tot ce mi-a cerut. În cea mai mare parte, sume de control nevalide, inoduri goale sau „gunoi” și numărări greșite pentru grupuri. Tot ce am citit a spus că acest proces ar putea dura ore, dar a durat doar zece minute.
După aceea, montura a funcționat în sfârșit, dar df -h
arată doar 6.9G (Ar trebui să fie 981G) în uz. Unitatea pare să fie goală, în afară de aproximativ 50 de intrări pierdut+găsit
, deci nu este suficient pentru a acoperi toate fișierele pierdute.
Nu știu cum să procedez și se pare că nu pot găsi mai multe răspunsuri pe cont propriu.
De ce nu mai erau montabile unitățile? - Răspuns de @mchid, mulțumesc!
Ce pot încerca în continuare, pentru a avea șansa de a recupera datele?
Și dacă cineva are răbdarea să mă educe:
Conectarea unității ext4 la o mașină Windows a corupt-o? Dacă da, de ce? Din câte am înțeles cu driverele corecte (adică LinuxReader) ar trebui să fie lizibil.
Orice răspuns este foarte apreciat. Multumesc anticipat pentru orice ajutor!
Editați pentru a adăuga:
ieșire lsblk:
NUME MAJ:MIN RM DIMENSIUNE RO TIP PUNCT DE MONTARE
sda 8:0 0 8G 0 disc
ââsda1 8:1 0 1M 0 part
ââsda2 8:2 0 8G 0 parte /
sdb 8:16 0 3.7T 0 disc
ââsdb1 8:17 0 3.7T 0 parte
sdc 8:32 0 3.7T 0 disc
ââsdc1 8:33 0 3.7T 0 parte
sdd 8:48 0 1000G 0 disc
ââsdd1 8:49 0 1000G 0 parte /date
ieșire separată:
(despărțit) imprimare
Model: QEMU QEMU HARDDISK (scsi)
Disc /dev/sdb: 4001 GB
Dimensiunea sectorului (logic/fizic): 512B/512B
Tabel de partiții: gpt
Semnale de disc:
Număr Start Sfârșit Dimensiune Sistem de fișiere Nume Steaguri
1 1049kB 4001GB 4001GB ext2