SSD delete file recovery

Sziasztok!

Kérdésem, hogy hogyan lehet adatot ezekről a csodálatos ssdkről visszafejteni?

Letöröltem direkt 3 mappát a d meghajtomról (ntfs) windows alól, de a getdata for ntfs5 csődöt mond. Látja a fileokat, de visszaállításkor mind érthetetlen katyvaty.

Itt már nem jók a régi ntfs recoveryk? vagy a vezérlő elektronika miatt nem lehet?

Köszönöm.

Hozzászólások

SSD vagy HDD ebben az esetben tökmindegy.

 

Getdata support mit mondott amikor ticketet nyitottál?

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Nem, nem mindegy. SSD-n törlés után a TRIM alapállapotba helyezi azokat a NAND cellákat, amikben az adat volt, így a tárolt adat ténylegesen is megsemmisül. Semmilyen ilyen szoftver nem hozza vissza. HDD-nél megmaradnak a tányéron az adatok.

PATA/SATA/SAS-UASP SSD-n annyi könnyebbség van, hogy ha nem volt bekapcsolva a TRIM (vagy SCSI-n UNMAP), akkor vissza lehet nyerni az adatokat. De NVMe-n már a drive működésébe be van építve, így már kikapcsolni sem lehet a TRIM-nek megfelelő mechanizmust.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) ?

Szerintem a TRIM miatt nem tudod visszaszedni az adatot.

Azt PONTOSAN csak a jóisten tudja (és Kumar, a programozó), mert h. a mikroszoft baszik majd elárulni publikusan, az fix. Max. hadovál valamit a félkegyelmű szupport: ilyen optimize, enhance, meg user experience, performance, stability kulcsszavakból jó sok lesz benne, mert a bullshit-generátoruk így lett beállítva.

Sehol. Meg lehet köszönni a zárt forráskódnak. A MS azt mond erről, amit akar. Ennek ellenére hozzám ez úgy jutott el a Blikkből, hogy MS Windows 7 óta az összes Windowsban offline és online TRIM is van. A Windows kernel fájl/mappatörlésekkor is küld ki TRIM-et (hacsak nincs ez letiltva a disabledeletenotify-jal), meg ütemezett offline TRIM is be van ütemezve default heti egyszer (ezt a Windows Defrag service végzi, de nem defragol ilyenkor, hanem optimalizációnak hívva TRIM-et hajt végre). Persze a kettő együtt feleslegesnek tűnik, inkább csak biztos, ami biztos alapon van, mert attól, hogy online is TRIM-ezve van, attól még a user használhatja ugyanazt az NTFS partíciót más olyan OS alatt, vagy más gépben, ahol meg nem megy a TRIM, vagy mert nem támogatott, vagy mert ki van kapcsolva, ezt az offline TRIM van hivatva pótolni.

De ez mind csak urban legend, amíg a forráskódot nem látjuk. Már pedig nem fogjuk, majd 2299. február 31-án talán kinyitja a MS, mint most a GW-BASIC-et, meg a DOS 1-2.x-et.

Linuxok alatt is kétféle TRIM kapcsolható be, egyszer mountoláskor már a fájlrendszerben bekapcsolható online/continuous TRIM, a legtöbb fájlrendszernél a discard mount paramétert kell hívni hozzá. Illetve lehet használni offline/periodic TRIM-et is, ezt az fstrim parancs végzi, ami általában egy systemd service-ként van beütemezve heti egyszeri futásra. De ez disztrónként változik, hogy melyik megoldást alkalmazzák, discard vagy fstrim, ha fstrim, akkor hogyan van beütemezve, init által kezelt service, cron job, vagy valami más. Általában csak az egyik szokott lenni default bekapcsolva, de a default átállításával bekapcsolható akármelyik, akár egyszerre, akármilyen ütemezéssel.

Debian-Ubuntu-Red Hat alapú disztrókon általában systemd által ütemezett fstrim service van, az Arch-vonal meg a discard paramétert tette meg defaulttá a fstab-ban. Ez sokszor szakmai vita tárgya, hogy melyik a jobb megoldás, általában attól függ melyik a default, hogy ki mire esküszik. Van, amikor nem is választás kérdése, mert vannak olyan fájlrendszerek, amik az egyik megoldással nem támogatják a TRIM-et, csak a másikkal. Pl. az ext3, NTFS-3g csak fstrim-et támogat. Régen még többféle kivétel volt, pl. az F2FS és VFAT sokáig csak a discard TRIM-et támogatta, az fstrim-et nem, de utólag ezt javították. A ZFS nem támogatott fstrim által. LVM, LUKS köteteken külön be kell kapcsolni, átengedik rajtuk a TRIM-et.

NVMe SSD-knél az egész nem érdekes, mert azokon nincs semmilyen TRIM parancs már. Ott az NVMe protokoll működése van úgy kialakítva, hogy végrehajtódjon minden vonatkozó utasítás keretében (Dataset Management, ami egy NVMe utasítás) egy olyan részművelet (deallocate), ami a TRIM-nek megfelelő műveletről gondoskodik, ezt ki sem lehet kapcsolni. De emiatt nem kell külön TRIM vagy UNMAP parancsot kiküldözgetni az NVMe SSD-nek. Ez az egész TRIM (SCSI, SAS, stb. SSD-nél az UNMAP) csak PATA/SATA/AHCI SSD-knél fontos, mert az ATA/AHCI protokoll még HDD-khez lett kitalálva, és utólag dobtak bele SSD-hez szükséges utasításokat. NVMe viszont már kezdettől fogva SSD-khez lett kitalálva, és nem kellett utólag kiküldendő extra utasításokat később belehekkelni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) ?

Tök jó összefoglaló, köszi szépen!

Ez az NVMe "TRIM" dolog számomra nem világos: a fájlrendszer alapesetben úgy töröl, hogy csak az inode-ot törli, az ahhoz tartozó datablockokkal nem csinál semmit. Honnan tudja az NVMe disk, hogy azok az adatblokkok már törölhetőek, amik a kitötrölt fájlhoz tartoznak?

Szerencsere sok modern SSD-ben van beepitett titkositas. Amikor egy sectorra kimegy a trim command (Windows eseten peldaul a 7-es verzio ota kuldi NTFS eseten torles utan is), akkor ezek a titkositast is tartalmazo modulok egyszeruen letorlik az adott sectorhoz tartozo kulcsot es generalnak egy ujat. Igy sokkal gyorsabb a torles es az adatok sem hozhatoak vissza. Ez szerintem sokkal de sokkal fontosabb elonye az SSD moduloknak, mint a sebesseg amit okoznak.

Nem értem miért írjátok mindannyian ezt a titkosítást. A legtöbb SSD nem titkosít. Csak a szerverbe, munkaállomásba, üzleti laptopokba szánt, meg a konzumer szegmensben néhány közép-felső kategóriás modell. Sima SSD-n (értsd, nem göcsörtös, nincs benne hardveres öntitkosítás) a TRIM nem titkosít semmit, csak törli a cellát, értve ez alatt, hogy gyári állapotba hozza őket, így niem lesznek bennük semmilyen bitek tárolva. Amolyan szűz állapotba kerülnek, mintha sose történt volna még rájuk írás.

Abban egyetértek, hogy ez jó extra feature, mármint hogy a TRIM mindent töröl. Így kevésbé informatikai vénás felhasználók törölt adatait sem lehet trükközéssel visszanyerni. Viszont amint a topiknyitás is mutatja, néhány felhasználónak ez hátrány is lehet.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) ?

Jelzi neki, hogy törölje, mert magától nem tudja az SSD, hogy melyik szektort törölheti. Márpedig törölnie kell, mert SSD esetén csak üres blokkba lehet adatot irni, ezért ha nem törli ki a blokkot szabadidejében, akkor az első irás művelet ami a szeméttel teli szektorra vonatkozik rohadt lassú lesz, mert előbb teli kell irja nullával és csak utána tudja beleirni a kért adatot.

Igen, ez még precízebb megfogalmazás. De vegyük észre, hogy a gyakorlatban ugyanazt jelenti. Kiküldöd a TRIM parancsot, innentől fogva az SSD vezérlője tudja, hogy x és y szektorokban, amikre ki lett küldve a parancs, már nem kell az adat. Ezért GC alkalmával törli. Bár lehet még egy-két régi garbage collection nélküli modellnél ténylegesen is üríti a vonatkozó NAND lapokat a TRIM hatására. Ez inkább annak függvénye, hogy milyen és mennyire új SSD-ről van szó, és a gyártó ezt hogyan programozta le a firmware-ben.

A lényeg, hogy amire kimegy a TRIM parancs, az végül záros időn (emberi léptékkel vehető azonnalnak) belül törölve lesz. Ezért SSD-ről nagyon megfontoltan törölgessen, akinek nincs biztonsági mentése. Backupnak mindig lennie kell, nem csak a drive meghibásodása, meg véletlen törlés (véletlen felülírás, egyéb user error) miatt, hanem szoftveres bug, malware (pl. ransomware) is okozhat adatvesztést.

De mint a kolléga írta: a TRIM adatmegsemmisítő hatása a felhasználók 99%-ának áldás, nem kell shred, zerofill, dd, egyéb megoldásokkal szenvedni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) ?

Nincs szektoronként másik kulcs. Egy kulcs van ill kettő. Egy asszimetrikus amivel feloldod bootkor jelszóval (vagy TPM-ből vagy akármiből) és ez a kulcs fejti vissza a nagyon hosszú és nagyon erős szimmetrikus kulcsot, amivel az egész SSD titkositva van.

Már amelyik SSD-ben van egyáltalán titkositás (pl. normálisabb samsungokban van) de ennek semmi köze a trimhez.

Talán az SSD wipe-al kevered bios-ban (ill szoftveresen) ott valóban szimplán eldobja mindkét kulcsot és generál egy új szimmetrikus kulcsot, amivel már nem lehet visszafejteni az adatokat -> törlődik a teljes SSD. De az nem szektor ill blokk szintű.

Azon csak én is lestem h. szektoronként külön kulcs van...

Amúgy nem véletlenül kapcsolta vissza alapesetben software-AES módra a bitlockert a microsoft tavaly óta, főleg ilyen SSD hardveres titkosítási katasztrófák után:

https://www.ru.nl/english/news-agenda/news/vm/icis/2018/radboud-univers…

Az h. pl. a Samsung is csak kussol h. a nyamvadt SSD-i milyen módon titkosítanak, nincs róla publikusan elérhető whitepaper. Amikor még arról is sunnyognak pl. egy nyamvadt 860 EVO firmware update changelog-ját publikusan elérhetővé tegyék, akkor én ott 0 bizalmat szavaznék a kontár programozóik crypto képességeire.

TRIM okozhatja a "bajt", de inkább jelenség. Eltitkosítja a törölt dolgokat. Általában a disk drive-ok nem arra vannak, hogy törölt adatokat is tároljanak. A kuka sem arra való. De vannak megoldások: samba trash és társai. Logikailag nem törli csak elrakják.

Ahogy Robika írja nem véletlen törlésről és nagyon kell neki valami adatról van szó.

És igen a legnagyobb probléma, a munkáltatók adatlopása a felhasználóktól.

De akkor most ezek az adatok nem helyreállíthatóak?

még egy kérdés:

Ez akkor csak rontja az ssd élettartamát? (mivel csak újraírja azokat amik törölve vannak)