Skrivet av Chris_Kadaver:
Tack för tipset! Men hade gärna sluppit boota från en USB bara för att skapa en image som borde gå enkelt att göra direkt i windows?
Nu får du tänka efter igen - hur lätt är det att göra en diskimage på en systemdisk där OS själv kör på och där saker hela tiden ändras medans kopieringen görs ??? - detta är receptet för att skapa en inkonsistent och trasigt filsystem såvida du inte kör windows i read-only mode på systemdisken.
i Linux kan man både gå ned i single usermode där bara en program körs i taget utan parallella processer och att man kan starta OS med systemdisken i skrivskyddat läge - det är bara i det läget ett OS kan ta kopia av sin filsystem medans den samtidigt kör på denna.
windows med VSS (aka Volume Shadow System) försöker skapa en liknande vy med emulerad 'fryst' filsystem och även emulerad 'fryst' diskimage men dessa är alltid i status 'som efter en plötslig strömavbrott' med öppna filer och halvskriven data - vilket går bra i de flesta fallen men inte alltid - som tex. äldre databasmotorer med databaser som blir korrupta och behöver göra integritetstester och sedan hoppas att det går igenom felfritt. (moderna databasmotorer är bättre byggda att tåla 'plötslig strömavbrott' med parallell journalföring mm.) - ett filsystem är i grunden en databas den också.
Med andra ord en windows-genererad diskimage oavsett använda winbackupprogram (som macrium reflect, windows egna backupprogram etc.) då alla använder samma 'VSS' som gör disk-klonen är inte av samma 'kvalitet' som en motsvarande gjord via en USB-sticka och tex. kör 'clonezilla' eller i linux använder 'dd' för att göra diskimagen, då den kör från en av windows nedstängd och korrekt filsystem.
Sedan är som redan skrivet skäl att undersöka att din D: verkligen är äkta och inte fått en fejkmodell som skriver om början igen när du skrivet över 1/8-del av disken och först när den sabbar redan skriven $MFT som du märker att disken är inte bra och kanske förlorat det mesta av datat på köpet.
med andra ord om du fyller disken med data så måste du också verifiera alla filer som läggs där att de tex. har samma hash-värde som orginalet - blir det knas där så har du en fejkdisk.
'Total commander' har lite mer användarvänliga funktioner att tex. kunna skapa hashvärden av ett filträd - kopiera filträdet (kanske i många upplagor för att fylla ut disken) på den misstänkta disken och sedan verifiera att hasvärdena stämmer för alla filer var i och en av mappträden.
H2testw mfl är specialgjorda just för att upptäcka fejklagring och kan ta lite genvägar för att snabbare se om det är ett problem eller inte.
kör man linux och BTRFS på disken och fyller disken med data och sedan läser igen så kommer den att upptäcka om delar av disken fått förändrade sektorer på tidigare delar av disken av senare skrivningar längre ut på disken - dock bör datat vara annat än zero-fyllda filer då den gör en checkvärde per 4k block och är det samma data hela vägen (som 0-fyllda filer) kan den inte se felen iom. med att checkvärdet också är samma hela vägen
