# Záchrana smazných dat z RAID0 v notebooku Oficiální HTML: Poslední aktualizace této textové reprezentace: 2026-10-22T14:27:57+02:00 Toto je textová reprezentace veřejné stránky MyBlueDay. Aktuální podmínky a kontakty ověřte na oficiálním webu. Řešený případ záchrany smazných dat z notebooku Dell osazeného dvojicí NVMe SSD Samsung 512 GB v konfiguraci RAID 0, šifrovaného BitLockerem a dalšímu bezpečnostními protokoly na úrovni UEFI. Tento případ dobře ukazuje na technologické limity obnovy po smazání dat a třídenním provozu na šifrovaných discích s TRIM v kombinaci s nešťastně zvoleným diskovým polem RAID 0. ## Smazaná dat v notebooku a RAIDem 0 Firemní notebook Dell Vostro 5502 (Intel Core i5-1135G7, chipset HM470) využíval dva OEM SSD Samsung PM991 512 GB připojené přes Intel RST do **softwarového RAID 0**. Systém Windows 10 Pro byl **plně šifrován BitLockerem** s klíčem uloženým v TPM 2.0; v UEFI byly aktivní Secure Boot, Boot Guard a UEFI Boot Path Security. Na konci běžné směny zaměstnanec bez oprávnění **vymazal data** (Shift+Delete **bez použití koše**). Nepoužil žádný nástroj na bezpečný přepis smazaných souborů. Notebook pak zůstal další tři dny v provozu - proběhly aktualizace Office, indexace MS Search a běžná uživatelská činnost. Poté firemní IT oddělení zjistilo ztrátu souborů a pokusilo se o samostanou logickou obnovu nástroji na záchranu dat LIve CD Linux; ty však neviděly nejen původní soubory ale ani interní SSD. Následně byl stroj vypnut a doručen k diagnostice. ![Smazaná data na notebooku s SSD diskem](https://www.myblueday.cz/assets/img/obrazky/vostro-5502-raid-0-problem.jpg) ## Přijaté zařízení a diagnostika Notebook jsme otevřeli v ESD prostředí a vzhledem k uživatelsky vlídnému chování firmy Dell jsme měli okamžitý přístup k M.2 slotům. Další postup byl následující, i když ne zcela rutinní. Bylo třeba: 1. **Prvním zjištěním bylo** že jsou osazený oba sloty M2. Po konzultaci se zákazníkem a podporou Dell jsme zjistili, že je zařízení dodáno v konfiguraci RAID 0 2x 515GB (zjistit konfiguraci bychom mohli sami, ale ideální je mít maximum vstupních informací). To není ideální. Čeká nás tedy, vzhledem k okolnostem velmi obtížná [záchrana dat na RAID poli](https://www.myblueday.cz/zachrana-a-obnova-dat-z-diskoveho-pole-raid/). 2. **Vyjmout oba disky** a přečíst je individuálně v režimu NVMe Passthrough, aby nedošlo k dalším zápisům. 3. **Zaznamenat metadata Intel RST** (Offset 0x0B s DTL - Disk Topology Layout) potvrzující stripe 128 kB a sekvenci disků (Disk 0 = PM991-A, Disk 1 = PM991-B). 4. **Vytvořit bitové obrazy** obou SSD pomocí PC-3000 (NVMe HW-imager) s parametrem *Disable TLER* a *Ignore CRC* pro stabilní čtení při opotřebení bloků. Odezva byla bez chyb; SMART hlásil pouze 6 procent opotřebení NAND. Kontrola hexadecimálních dumpů potvrdila, že **TRIM příkazy byly provedeny téměř okamžitě po mazání** - typické pro Windows 10 na NVMe. Trimované oblasti nesly vzorek ` 00 00 00 00 ` v souvislých rozsazích. To indikovalo, že FTL mapování uvolnilo logické LBAs a FW řadiče je následně "přemapoval" na volné bloky. ## Vlastní práce na záchraně - postup ### Rekonstrukce RAIDu - Pomocí modulu **Data Extractor RAID Edition** jsme vytvořili virtuální pole se základním nastavením: velikost stripe 128 kB, disk-order \[0, 1\], start offset 0 B. - Kontrolním čtením jsme identifikovali BitLocker podpis FVE-FS na sektoru 0x4000 (ale až po de-stripingu). ### Dekryptování svazku Zákazník naštěstí uložil **BitLocker Recovery Key** v Azure AD. Po importu klíče a zadání správného GUID jsme disk dešifrovali v read-only módu. Souborový systém NTFS byl konzistentní; MFT ukazoval 18 247 záznamů s atributem '**file\_deleted**'. ### Snaha o obnovení souborů které jsou smazané Algoritmy **NTFS Undelete** (R-Studio Technician, UFS Explorer Professional) procházely MFT a vyhledávaly nezačleněné Clusters Runs. Výsledek: | Typ souboru | Nalezeno | Obnovitelné | Poznámka | | --- | --- | --- | --- | | TXT/DOCX/PPTX | 2 814 | 57 | 100 % datových sektorů zachováno | | CAD/DWG | 196 | 0 | Clustery přepsány automatickými zálohami AutoCADu | | XLSX | 743 | 14 | Fragmentováno s chybějícími CRC | | Zdrojové kódy (.cs, .js) | 1 104 | 0 | Přepsáno službou OneDrive Sync | --- Analýza volných clusterů ukázala **\> 92 % lokalit vyplněno nulami**. Třídenní provoz znamenal cca 47 GiB nového zápisu, který ve stripe 0/1 způsobil plošné přepisování - na SSD disku Samsung PM991 funkce garbage-collection migruje data poměrně agresivně, takže reálné přepsání dat po logickém výmazu proběhne i na fyzických NAND blocích. ### Forenzní carve & Pattern Search - poslední možnost Na virtualizované diskové pole jsme následně spustili utilitu **Photorec 7.2 custom build s NVMe no-trim heuristikou** (Photorec obecně vykazuje podle našich zkušeností vynikajících výsledků v případech, kdy není možné zachránit data nealokovaná v souborovém systému) a kontrolní regex look-ahead na uživatelem specifikované firemní šablony. Intenzivní "carving" přinesl několik fragmentů XML z DOCX, bohužel nečitelných. Bez zachování fragmentační logiky NTFS RAID0 nelze tyto fragmenty složit. ## Výsledek a doporučení | Metoda | Úspěšnost | Poznámka | | --- | --- | --- | | Logická obnova metodou undelete | 3 % | 71 souborů plně, 14 částečně | | File carve - (RAW metoda) | \< 1 % | Pouze textové fragmenty | | Obnova celé složky "Projekty2025" (hlavní požadavek) | **neúspěšná** | 0 % dat přítomno | --- **Hlavní příčina neúspěchu**: kombinace TRIM, FTL wear-levelingu NVMe SSD a třídenního provozu vedla k fyzickému přepisu bloků dříve, než se k nám notebook dostal. V RAID 0 navíc v tomto konkrétním případě každý 128 kB stripe zapisuje střídavě na oba disky, takže i krátké zápisy operačního systému přepisují logicky souvislé soubory ve dvou fyzických zařízeních najednou. V tomto případě byla [záchrana dat na notebooku](https://www.myblueday.cz/zachrana-a-obnova-dat-z-notebooku-nebo-laptopu/) i přes velké množství odvedené práce neúspěšná. Zákazník se tedy musel smířit s tím, že **o data definitivně přišel**. My jsme z důvodu neúspěchu **práci na záchraně dat neúčtovali**. ### Doporučení vycházející z tohoto "nevyřešeného" případu 1. **Okamžitě vypnout zařízení (!)** po zjištění smazání dat, která jsou vymazaná omylem. Platí na jakémkoliv paměťovém zařízení. Na systémových discích je to naprosto zásadní. 2. Uvažovat o **RAID 1** místo RAID 0 na notebooku, **pokud je vůbec nutné diskové pole používat**. Vzhledem k velikostem a rychlosti aktuálně dostupných SSD považujeme za běžných okolností použití RAID za nesmyslné. Riziko [poškození RAID pole](https://www.myblueday.cz/zachrana-a-obnova-dat-z-diskoveho-pole-raid/) je poměrně vysoké a benefity rozhodně nepřevažují nad rizikem. 3. Pokud je aktivované šifrování **BitLocker**, pak důrazně dbát na uchovávání a dostupnosti obnovovacího klíče. 4. Mít **externí verzi záloh** (VSS, File History, OneDrive Versioning) - oddělenou od primárního disku. Ale v zásadě je lepší jakékoliv zálohování než žádné. Z naší zkušenosti je již běžné, že v korporátním sektoru nelze udržovat jakákoliv firemní data na notebooku nebo PC. Ty fungují v zásadě jako terminály pro vzdálené virtualizované prostředí. 5. Zvážit **Endpoint DLP** pro blokaci lokálních mazání / šifrování citlivých dat. | Položka | Hodnota | | --- | --- | | Výrobce média | Samsung | | Typ média | 2× NVMe SSD 512 GB | | Model SSD | PM991 MZVLQ512HALU-000D7 | | Typ závady / příčina ztráty dat | Logický výmaz souborů + TRIM, RAID0 BitLocker | | Výsledek záchrany dat | Neúspěšná (obnoveno 3 % drobných souborů) | | Lokace zákazníka | [Brno, Jihomoravský kraj](https://www.myblueday.cz/zachrana-dat-v-kraji-jihomoravskem/) | ## Odborné zázemí MyBlueDay MyBlueDay! publikuje odborné informace o záchraně a obnově dat. Na tuto oblast se specializuje od roku 2003 a provozuje laboratoř v Praze. Tento článek souvisí s problematikou diagnostiky a obnovy dat z poškozených úložišť. Technici v laboratoři na záchranu dat MyBlueDay používají diagnostické a servisní systémy ACELab PC-3000, vybavení DeepSpar a další specializovaný hardware umožňující práci s mechanicky či elektronicky poškozenými datovými médii. Odborné zkušenosti firmy lze dále posoudit podle popsaných případů obnovy dat a informací o laboratorních postupech. [Historie a odborné zázemí MyBlueDay](https://www.myblueday.cz/ai-index/o-myblueday.md) · [Publikované případové studie](https://www.myblueday.cz/ai-index/user-cases.md) · [Recenze a zdroje hodnocení](https://www.myblueday.cz/ai-index/recenze-a-reference.md)