Mapp försvann efter reperation av hårddisks filsystem.

Permalänk
Medlem

Mapp försvann efter reperation av hårddisks filsystem.

Skulle kopiera över filer från C: till D: som är min lagringsdisk. Jag märkte dock att överföringen hade frusit, så jag avbröt den genom att trycka på avbryt och fick därefter upp ett meddelande om att filsystemet på D: hade fått något fel och det gick inte att öppna disken.

Använde mig av Windows inbyggda verktyg för att felsöka och reparera vilket gjorde att jag nu kommer in på disken men hela mappen jag höll på att kopiera till är nu borta.

Har testat att använda mig av Recuva och Testdisk men dom hittar tyvärr inte mappen som är borta. Kan också tillägga att D: fortfarande har lika mycket fritt utrymme som den skulle ha om mappen fortfarande "fanns".

Är det någon som vet hur jag kan rädda och återställa den förlorade mappen?

Visa signatur

UNIX + SFF = <3

Permalänk
Medlem
Skrivet av Kujo:

Skulle kopiera över filer från C: till D: som är min lagringsdisk. Jag märkte dock att överföringen hade frusit, så jag avbröt den genom att trycka på avbryt och fick därefter upp ett meddelande om att filsystemet på D: hade fått något fel och det gick inte att öppna disken.

Använde mig av Windows inbyggda verktyg för att felsöka och reparera vilket gjorde att jag nu kommer in på disken men hela mappen jag höll på att kopiera till är nu borta.

Har testat att använda mig av Recuva och Testdisk men dom hittar tyvärr inte mappen som är borta. Kan också tillägga att D: fortfarande har lika mycket fritt utrymme som den skulle ha om mappen fortfarande "fanns".

Är det någon som vet hur jag kan rädda och återställa den förlorade mappen?

Är den väldigt viktig så måste jag säga samma sak som de flesta andra skulle ha gjort här inne, skicka den till t.ex IBAS.

I annat fall, använd t.ex Recuva eller liknande recovery-program och se om den hittar det som förlorats. I bästa fall har inte sektorerna blivit överskrivna än.

MEN SKRIV FÖR GUDS SKULL INTE TILL DISKEN. Då kan du nästan vara säker på att det är borta sen.

/Lifooz

Visa signatur

Deepcool Matrexx 30 & MSI Z87-G43 Gaming!
Intel Inside Core I7 4790K med AMD Radeon R9 290!
Rubbet strömförsörjs av Corsair RM750X!
Hjälp Teamtrees plantera träd på vår jord. https://teamtrees.org/

Permalänk
Medlem

@Kujo
Det låter som att du gjorde misstag 1 genom att "flytta" filerna, inte kopiera dem.
Det verkar kanske inte som någon skillnad, men om det sker något, som i detta fallet, är det skillnad.

Vad som troligen hänt är att filerna kopierats över till nya disken, sen tagits bort av automatiken på den gamla, och sedan har den fortsatt kopiera. När den sen fått problem så har mappen blivit skadad. Detta är speciellt stor risk då idag cacheas allt till RAM och minnesbuffrar på diskarna.

När sedan chkdsk har lagat detta har den inte kunnat få rätta på mappstrukturen och därför har det blivit fel.

Så, hur löser vi detta?
Som ovan säger, är det ovärderligt, räddningsfirma. Och i fortsättningen har backup (sparar mycket pengar). För risken är att du kan mista saker annars. Är du beredd på att ta den risken så läs vidare.

Det som jag tror har hänt dock är att chkdsk har lagt de filer den hittat i dessa mappar i sin felsöknings mapp.
Titta igenom detta inlägg så finns där en dold mapp som bör innehålla filerna (som gick att rädda iaf)
https://answers.microsoft.com/en-us/windows/forum/windows_7-p...
Notera att detta gör att Recuva inte hittar något, då filerna inte tagits bort. Men du kan nog glömma hitta hela mappen intakt, utan det är fil för fil räddning du får göra nu.

Och viktigaste notisen av alla. Rädda INTE filerna till samma disk, någonsin. Utan om du hittar denna mapp och dess filer, kopiera dem till en annan fysisk disk, sen får du försöka identifiera dem. Har du tur är filnamnet kvar, har du otur är de helt okända och du får försöka identifiera dem en för en, manuellt. Först när du vet att du räddat allt du vill, kan du använda den andra disken igen.

Eftersom dock något slutade svara (då processen inte fungerade) så hade jag också kollat SMART på dem, med tex Crystal Disk Info. Även om den säger "Bra" så kan det vara kommande problem, så vill du ha hjälp att tolka dem, ta en skärmdump på alla raderna i programmet (på dina HDDs SMART data) och ladda upp dem till typ postimages.org eller forumbilder.se så tittar vi på dem.

Och tips till nästa gång... Flytta aldrig viktiga filer. Kopiera dem, och när du vet kopian är säker, först då tar du bort de ursprungliga filerna. Och den det eviga tjatet... backup, backup... för det sker "bla bla"...

Permalänk
Medlem

@Kujo: Förutsatt att disken inte är skadad fysiskt så kan man i Linux öppna upp en NTFS eller FAT-16/-32 disk och även läsa ut metadata i skrivskyddat läge. Till skillnad från Windows så är Linux skrivskyddade läge just skrivskyddat och ändrar inget. I Windows så ändras visst metadata (filinformation, t ex. datum / tid / när partitionen öppnades etc.) även i deras skrivskyddade läge, som ändå kräver massa trix för att aktivera. I Linux kan man även hantera den dolda systemfilen $MFT så man får ut filnamn och metadata om filerna manuellt om det skulle behövas.

Dessutom kan du göra en rå image av hela disken i Linux som skapas som en fil som antingen kan hanteras av specialprogram som kan leta ut data eller monteras som en hårddisk eller partition. I Linux kan du även leta rätt på försvunna partitioner med GParted. Bästa gratisprogrammet för diskhantering som klår många kommersiella program på fingrarna.

Vill du ha hjälp så kan vi kanske tom träffas så kan jag på plats kanske få ut något åt dig.

Visa signatur

Server: Fractal design Define 7 XL | AMD Ryzen 7 5800X 8/16 | ASUS ROG CROSSHAIR VIII DARK HERO | 64GB Corsair @ 3000MHz | ASUS Radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2TB Samsung 850 PRO SSD | 6x Seagate Ironwolf Pro 10TB
WS: Phantex Entoo Elite | AMD Ryzen Threadripper 1950X 16/32 | ASUS Zenith extreme | 128GB G.Skill @ 2400MHz | ASUS Radeon HD7970 | 3x 2TB Samsung 960PRO M.2 | 6x Seagate Ironwolf Pro 10 TB
NEC PA301W 30" @ 2560x1600 | Linux Mint 21.3 Cinnamon

Permalänk
Medlem

@OldComputer: @Paddanx: @Lifooz:

Det som Paddanx beskrev var precis det som hände.

Tack vare länken som Paddanx postade så fick jag reda på att det finns en mapp vid namn FOUND.000 där filerna skulle ligga. Hittade mappen via Testdisk, kunde inte bara visa dolda mappar och filer för att hitta den som i artikeln.

Värt att notera ifall någon annan med liknande problem snubblar in i tråden är att jag var tvungen att återskapa filerna till C: disken för att kunna hitta mappen FOUND.000. Jag försökte först återskapa dom till en annan extern disk vilket gjorde att mappen FOUND.000 återskapades men var förtfarande gömd och jag inte fick tillgång till den. Nu är filerna iaf återskapade och jag har tillgång till dom.

Men nu vill jag ta bort FOUND.000 ifrån D: och E: då dom bara ligger där nu och tar plats. Några idéer på hur jag gör det? Har ett Linux USB jag kan boota till men det kanske finns något smidigt program man kan använda istället?

@Paddanx: Du får gärna slänga ett öga på mina diskar:

Visa signatur

UNIX + SFF = <3

Permalänk
Medlem
Skrivet av Kujo:

@OldComputer: @Paddanx: @Lifooz:

Det som Paddanx beskrev var precis det som hände.

Tack vare länken som Paddanx postade så fick jag reda på att det finns en mapp vid namn FOUND.000 där filerna skulle ligga. Hittade mappen via Testdisk, kunde inte bara visa dolda mappar och filer för att hitta den som i artikeln.

Värt att notera ifall någon annan med liknande problem snubblar in i tråden är att jag var tvungen att återskapa filerna till C: disken för att kunna hitta mappen FOUND.000. Jag försökte först återskapa dom till en annan extern disk vilket gjorde att mappen FOUND.000 återskapades men var förtfarande gömd och jag inte fick tillgång till den. Nu är filerna iaf återskapade och jag har tillgång till dom.

Men nu vill jag ta bort FOUND.000 ifrån D: och E: då dom bara ligger där nu och tar plats. Några idéer på hur jag gör det? Har ett Linux USB jag kan boota till men det kanske finns något smidigt program man kan använda istället?

Låter ju bra, då löste det sig iaf

Du kan enklast få bort dem genom att köra diskrensning, och sen trycka "rensa systemfiler" (tror man måste ha med det), så finns dessa gamla chkdsk filer i denna listan, som du kan välja.

Skrivet av Kujo:

@Paddanx: Du får gärna slänga ett öga på mina diskar:

https://s33.postimg.cc/tihilgvor/image.png

Ser bra ut.
Inga uppenbara fel.
Och 10TB skrivet är ingenting, disken själv säger ca 2% använt.

Denna vill ja slå en varningsflagga för. Backup bör du ta omedelbart på denna disk.
Du har väldigt djup ECC nivå, långt under var den borde ligga. Hardware ECC på 6, som har varit nere på 2, är typ... oläsbar data.
Du har 24 HEX (36) Command Timeout, som är allvarliga fel. Det är att disken helt slutat svara, och inte kunnat slutföra instruktionerna.
Du har 13 HEX (19) UltraDMA fel över SATA kabeln, där överföringen behövts skickats om.
G-Sence Error på 200 HEX (512) gånger låter inte bra, det är att den utsatts för smällar mer än den tål väldigt många gånger, som kan vara orsaken till felen också. Finns även en risk att de nekar dig garanti pga dem.

Hade detta varit en gammal disk, kunde man förstått att den är sliten, men detta verkar vara en som lever i en hård miljö den inte tål, som riskerar rasa rätt snart. Med <2000 timmars drift, bör du inte ha problem att prata med ÅF, normalt, men frågan är hur de tolkar detta.

De command timeout är troligen vad som orsakat ditt fel och problem du hade här i tråden.

Disken här har haft lite incidenter, men verkar okej.
Den har 21 HEX (33) gånger fått kalibrera om och ladda in/ut läsarmen.

Mekaniskt verkar den utsättas för mycket stötar och smällar då du har en G-Sense på 15D9 HEX (5593) gånger. Mao, disken har levt eller lever ett hårt liv. Dessa kan förklara varför armen behövt rätta till sig de 33 gånger ovan.

Den har också 11D HEX (285) skrivfel, vilket inte är bra, men de sker ibland när diskar blir slitna.
Den har iaf inga läsfel, eller omflyttade sektorer, så trots sitt hårda liv, har den klarat sig bra.

Ta o kolla upp varför diskarna får så mycket G-sense smällar, för det dödar moderna HDDs fort. SSDer tål en hel del, men mekaniska diskar gör det inte.

Permalänk
Medlem
Skrivet av Kujo:

@OldComputer: @Paddanx: @Lifooz:

Det som Paddanx beskrev var precis det som hände.

Tack vare länken som Paddanx postade så fick jag reda på att det finns en mapp vid namn FOUND.000 där filerna skulle ligga. Hittade mappen via Testdisk, kunde inte bara visa dolda mappar och filer för att hitta den som i artikeln.

Värt att notera ifall någon annan med liknande problem snubblar in i tråden är att jag var tvungen att återskapa filerna till C: disken för att kunna hitta mappen FOUND.000. Jag försökte först återskapa dom till en annan extern disk vilket gjorde att mappen FOUND.000 återskapades men var förtfarande gömd och jag inte fick tillgång till den. Nu är filerna iaf återskapade och jag har tillgång till dom.

Men nu vill jag ta bort FOUND.000 ifrån D: och E: då dom bara ligger där nu och tar plats. Några idéer på hur jag gör det? Har ett Linux USB jag kan boota till men det kanske finns något smidigt program man kan använda istället?

@Paddanx: Du får gärna slänga ett öga på mina diskar:

https://s33.postimg.cc/tihilgvor/image.png

https://s33.postimg.cc/lpquthxff/image.png

https://s33.postimg.cc/mf9n5v5or/image.png

Skönt att höra att det löste sig för dig, ja du kan radera mappen från D och E, men försök att ha någon hårddisk till backup också.
Det är så här svettigt det kan bli när man bara har sakerna på en enda hårddisk. Fråga mig, jag förlorade i yngre dagar bilder som jag aldrig mer får tillbaka, det var inte jag själv som fixade det utan en klåpare, före detta vän till mig som lyckades formatera disken där det låg.

En gång senare för typ 1-2 år sedan hände det igen, det svider att det materialet försvann, det gör det verkligen även om det inte var lika viktigt som det som klåparen utplånade.

Så nu förtiden är det backup på MINST en disk, oavsett vad.

/Lifooz

Visa signatur

Deepcool Matrexx 30 & MSI Z87-G43 Gaming!
Intel Inside Core I7 4790K med AMD Radeon R9 290!
Rubbet strömförsörjs av Corsair RM750X!
Hjälp Teamtrees plantera träd på vår jord. https://teamtrees.org/

Permalänk
Medlem
Skrivet av Paddanx:

Denna vill ja slå en varningsflagga för. Backup bör du ta omedelbart på denna disk.
Du har väldigt djup ECC nivå, långt under var den borde ligga. Hardware ECC på 6, som har varit nere på 2, är typ... oläsbar data.
Du har 24 HEX (36) Command Timeout, som är allvarliga fel. Det är att disken helt slutat svara, och inte kunnat slutföra instruktionerna.
Du har 13 HEX (19) UltraDMA fel över SATA kabeln, där överföringen behövts skickats om.
G-Sence Error på 200 HEX (512) gånger låter inte bra, det är att den utsatts för smällar mer än den tål väldigt många gånger, som kan vara orsaken till felen också. Finns även en risk att de nekar dig garanti pga dem.

Hade detta varit en gammal disk, kunde man förstått att den är sliten, men detta verkar vara en som lever i en hård miljö den inte tål, som riskerar rasa rätt snart. Med <2000 timmars drift, bör du inte ha problem att prata med ÅF, normalt, men frågan är hur de tolkar detta.

De command timeout är troligen vad som orsakat ditt fel och problem du hade här i tråden.

Det lät ju inget vidare. Förstår jag dig rätt att den har tagit 512 smällar totalt? Disken är inhandlad i början av Maj och sitter i en Dockningsstation 24/7 så det är ingen disk som jag flyttar på.

Jag hade en hel del problem med att montera och partionera disken när jag fick den vilket jag trodde berodde på att den kördes via en dockningsstation men tror du att det kan vara det som du ser i Crystaldiskinfo som kunde vara problemet då också?

Skrivet av Paddanx:

Disken här har haft lite incidenter, men verkar okej.
Den har 21 HEX (33) gånger fått kalibrera om och ladda in/ut läsarmen.

Mekaniskt verkar den utsättas för mycket stötar och smällar då du har en G-Sense på 15D9 HEX (5593) gånger. Mao, disken har levt eller lever ett hårt liv. Dessa kan förklara varför armen behövt rätta till sig de 33 gånger ovan.

Den har också 11D HEX (285) skrivfel, vilket inte är bra, men de sker ibland när diskar blir slitna.
Den har iaf inga läsfel, eller omflyttade sektorer, så trots sitt hårda liv, har den klarat sig bra.

Ta o kolla upp varför diskarna får så mycket G-sense smällar, för det dödar moderna HDDs fort. SSDer tål en hel del, men mekaniska diskar gör det inte.

Denna är en äldre extern 2,5 Seagate disk som flyttas en del så denna har jag förståelse för att den fått några smällar hos bekanta/släktingar.

Skrivet av Lifooz:

Skönt att höra att det löste sig för dig, ja du kan radera mappen från D och E, men försök att ha någon hårddisk till backup också.
Det är så här svettigt det kan bli när man bara har sakerna på en enda hårddisk. Fråga mig, jag förlorade i yngre dagar bilder som jag aldrig mer får tillbaka, det var inte jag själv som fixade det utan en klåpare, före detta vän till mig som lyckades formatera disken där det låg.

En gång senare för typ 1-2 år sedan hände det igen, det svider att det materialet försvann, det gör det verkligen även om det inte var lika viktigt som det som klåparen utplånade.

Så nu förtiden är det backup på MINST en disk, oavsett vad.

/Lifooz

Datan som försvann är som tur e inte livsviktig. På mina viktigare filer så har jag en cloud backup

Visa signatur

UNIX + SFF = <3

Permalänk
Medlem
Skrivet av Kujo:

Det lät ju inget vidare. Förstår jag dig rätt att den har tagit 512 smällar totalt? Disken är inhandlad i början av Maj och sitter i en Dockningsstation 24/7 så det är ingen disk som jag flyttar på.

Jag hade en hel del problem med att montera och partionera disken när jag fick den vilket jag trodde berodde på att den kördes via en dockningsstation men tror du att det kan vara det som du ser i Crystaldiskinfo som kunde vara problemet då också?

Kan det vara så att disken får stryk när du sätter in andra saker i dockningsstationen? Eller att den inte sitter fast nog?
De tål väldigt lite rörelse när de väl spinner och jobbar. Jag hade sett över hur den sitter och kanske se vad du kan göra.

Du kan se G-sense värdet, och det du ser i RAW är i Hexadecimalt läge. Du kan i programmet ställa om det till decimalt om du vill och hålla öga på det.

Ev så är disken okej, men har alla problem den har pga sina rörelser. Då skulle en omskrivning av hela disken när den är i bättre miljö kanske räcka.

Skrivet av Kujo:

Denna är en äldre extern 2,5 Seagate disk som flyttas en del så denna har jag förståelse för att den fått några smällar hos bekanta/släktingar.

Mjo jag antog den var någon äldre extra disk. 2,5" diskar brukar tåla mer, och har kortare stroke, så det är lättare att få in armen för att skydda skivorna. Räcker ju med en enda repa... så är det kört.

Och bra du har backup

Permalänk
Medlem

Som skrivet - dina mekaniska diskar har levt ett hårt liv mekaniskt medans de är strömsatta och kanske skriver/läser samtidigt.

Ha koll på dom siffrorna i din vidare användning och se om G-sense värdet ökar på dina diskar, kolla före och efter om du lånar ut diskarna för att se om det är låntagarna som misshandlar dem i (oftast) okunskap - för då blir det att fundera på varför - tänk på att slå i knäet på bordsbenet/bordet kan räcka för att diskdockan ovanpå bordsskivan skal förmedla stöten så att det registreras i G-sense...

Har man problem med sådan så får man titta efter annan plats för disken (eller låta bli att låna ut dem om det visar sig beror på externa faktorer om disken inte är 'offringsbar').

För 6TB-disken (förutom att göra backup innehållet på annan media) så skulle jag prova med tömma på all data (till annan disk) - eller vart fall göra en diskimage på _hela disken_ från första till sista sektorn lagrad på en annan stor disk - och sedan skriva tillbaka hela diskimagen.

Processen gör att varenda sektor på disken tvingas att skrivas om och i samband med detta så kollas läskvaliten i samband med skrivning (den enda tillfället faktiskt) och är det för dålig kvalitet så skrivs sektorn om ett antal gånger och går det fortfarande inte så reallokeras sektorn och din reallokeringsräknare stegar upp (pos. 05).

Om det sker så vet du att disken kan ha potentiella skador - men behöver inte betyda att disken är oanvändbar om värdet håller sig stabil och inte ökar vid lite flitigare skriv-användning senare.

Den låga ECC-värdet (pos C3) bör efter denna fulla omskrivning i aktuell-kolumnen sakta öka med mängden läst data med ingen eller liten insats i felrättningen (värdet är förmodligen i en kombination hur djupt viterbi/LDPC behövde cykla för korrekt data samt stegningstakten till högre värde förmodligen bestäms av hur ofta rättning görs gentemot mängden läst total data i typ senaste 20 TB fönster eller liknande) - att det har varit så lågt betyder att det har varit väldigt besvärligt med läsningen och nyttjat nästa allt den har i felrättningsförmåga men ändå alltid lyckas felrätta då du fortfarande har värdet 0 hex i position C6.

Mycket felrättnings-insats hela tiden gör också disken långsam vid läsning då förutom kanske flera fysiska omläsningar med en diskvarv i tid mellan varje läsning, ompositionering av läshuvuden mm. också spenderar mycket tid på att loopa viterbi/LDPC-algoritm för att försöka höja S/N och därmed allt färre bitfel så att redundansen i lagrade ECC-informationen räcker till för en full och felfri rättning (detta görs också i SSD - mycket mer än vad folk är medveten och det hela tiden - en långsammare läsning => flervarv med viterbi/LDPC innan godkänd data)