Fiecare întrebare și răspuns pe care îl pot găsi pare a fi opusul problemei mele actuale.
Unitate USB NTFS de 8 TB (~85% plină) conectată la serverul Ubuntu 20.04 cu un singur boot, partajată cu stațiile de lucru Windows prin Samba. Folosit într-o afacere de predare personală considerată „neesențială”, așa că agățat de unghii și rugăciuni datorită faptului că a fost închis pentru clienți timp de 7 luni anul trecut. Cea mai mare parte a datelor sunt cursuri video create în timpul/de la blocare. Mai bine fail over este în planuri, dar plata salariilor și a chiriei au fost prioritatea. Proprietarii sunt 100% în spatele cheltuielilor IT (unul a fost profesor CSI), așa că nu ies ieftin din ignoranță. Ei au aprobat fiecare bucată de HW & SW de pe lista mea, au aprobat prioritățile și au stabilit ținte pentru fiecare achiziție. Ca tocilar, apreciez cu adevărat sprijinul lor. Nu am lucrat niciodată pentru o companie care să înțeleagă mai bine modul corect de a-și configura infrastructura. Înainte de blocări, ei finanțau IT-ul frumos, dar serverul a fost implementat datorită adaptării pentru a fi „neesențial”. Activitatea sa schimbat de la predare la dezvoltarea curriculară 100%, ceea ce a necesitat o partajare mult mai bună a unor cantități mari de date. Vă rog să iertați această diatribă, dar sper să evit răspunsurile „shoulda, coulda, woulda”.
Copiam fișiere prin rețea (scrieam pe unitate) când s-a întrerupt curentul. UPS este pe listă, dar nu a fost posibil. Toate stațiile de lucru sunt laptop-uri, așa că nu aveau unul pentru a stivui dublu. La repornire, unitatea nu se va mai monta în Linux (pe server sau laptopul meu Ubuntu 20.04). Când rulez fdisk, raportează „Tabelul GPT principal este corupt, dar copia de rezervă pare OK, așa că va fi folosită.” Deoarece unitatea nu se montează, backup-ul sigur nu pare să fie folosit. Poate mă înșel, dar așa pare.
Fdisk afișează ceea ce pare a fi o descriere adecvată pentru /dev/sdb (7,28 TiB, 8001563222016 octeți, 15628053168 sectoare ...)
Afișează ceea ce par a fi informații corecte pentru /dev/sdb1 (început 2048 sfârșit 15628050431 sectoare 15628048374 dimensiune 7.3T tip Microsoft date de bază). Nu există alte partiții.
Unitatea este în format NTFS. Este o unitate USB care trebuie conectată cu ușurință la sistemele Windows fără software suplimentar pe acele sisteme (cerința proprietarului de afaceri pentru portabilitate). Îl pot conecta direct la mașini Windows 7, 8, 10. Se montează corect, iar datele pot fi citite și scrise pe orice sistem de operare Windows. Dacă verific erori în Windows, nu sunt detectate, așa că nu se face nicio încercare de reparare. Nu am încercat niciun instrument de reparare Windows în afară de verificarea discului, deoarece, din experiența mea, de obicei fac mai mult rău decât bine.
Am o copie de rezervă a tuturor datelor (la 1700 de mile distanță - cele mai multe date sunt scrise în picături, așa că am un script care le face copii de rezervă peste noapte într-o locație la distanță, simplu și invizibil) și toate datele sunt accesibile pe unitatea în cauză dacă atașez unitatea la Windows. Partea cea mai dificilă este că, datorită Covid, nu am o unitate de rezervă 8T sau fondurile pentru a cumpăra una - serios. Aș dori să evit și o copie de peste 36 de ore, fie aici, fie pe site-ul nostru de rezervă (casa copilului proprietarului). Ne-am obișnuit atât de mult să fie pe micul nostru server, am dori să-l recuperăm cât mai curând posibil. L-am pus pe un server 20.04 special pentru că respect no BS și instrumentele grozave pe care le oferă Ubuntu. Micul server este sistemul meu preferat, pentru că nu e deloc temperamentală... până acum.
Am acces la sistemele Windows 7, 8, 10, precum și la serverele și desktopurile Ubuntu 20.04. Sunt dispus să folosesc un instrument Windows dacă asta reușește, dar am mai multă încredere în Ubuntu - majoritatea „instrumentelor de recuperare” Windows mă sperie prostiile
