Odpověď hned: Ext4 standardně nepočítá kontrolní součty obsahu datových bloků. Když úložiště vrátí čitelná, ale nesprávná data, ext4 nemá s čím je porovnat — soubor se otevře, zkopíruje i zazálohuje, jen už v něm nejsou původní data. Btrfs a ZFS kontrolní součty dat mají a při scrubu poškození odhalí; opravit ho ale dokážou jen tam, kde existuje druhá správná kopia — tedy při redundantním poli. Ani jeden z nich nenahrazuje samostatnou zálohu.
Ext4 není špatný souborový systém. Je rychlý, vyzrálý a po výpadku napájení se srovná spolehlivě. Pro firemní NAS má ale jednu konkrétní slabinu, která se pozná až ve chvíli, kdy je pozdě: neumí říct, že se obsah souboru změnil. Tenhle text je o tom, jak tichá chyba vzniká, proč ji ext4 nevidí a co přesně z toho plyne pro nákup a nastavení NAS.
Co znamená tiché poškození dat
Mezi magnetickým povrchem plotny a aplikací, která soubor otevírá, stojí řada mezičlánků: firmware disku, jeho cache, SATA nebo SAS kabeláž, řadič NAS, RAID vrstva, RAM a nakonec souborový systém. Chyba může vzniknout kdekoli v tom řetězci.
Část poruch je hlučná a viditelná. Disk ohlásí nečitelný sektor, vypadne z pole, ve SMART naskočí Reallocated nebo Pending sektory. S tím se dá pracovat — systém ví, že něco selhalo.
Horší je situace, kdy celý řetězec považuje chybný blok za naprosto platný. Nikde se nerozsvítí kontrolka. Prakticky to vypadá takhle:
- archiv ZIP nebo 7z hlásí chybu CRC a část souborů z něj nejde rozbalit,
- fotografie má uprostřed posunutý barevný pruh,
- starší PDF se otevře s hláškou o poškozené struktuře,
- disk virtuálního stroje přestane startovat,
- databáze při čtení stránky zjistí nesoulad vlastní kontrolní sumy,
- zálohovací program bez verifikace přepíše dosud dobrou kopii poškozenou verzí.
Poslední bod je ten nejzákeřnější. Rotace záloh je v tu chvíli aktivně proti vám — tichá chyba se zálohuje stejně poslušně jako správná data a po pár cyklech není kam sáhnout.
Pojem „bit rot” se pro tohle používá běžně, ale je zavádějící. Naznačuje postupné stárnutí média, zatímco příčinou bývá stejně často vadná RAM, chyba firmwaru, problém s napájením nebo nekorektní zápis, který proběhl už před měsíci. Rozsáhlé měření na produkčních polích tenhle jev popsalo dávno — nejcitovanější je studie CERN a práce NetApp/University of Wisconsin nad statistikami z milionů disků. Konkrétní čísla se ale liší podle typu hardwaru a nedají se přenášet na malý firemní NAS jako „pravděpodobnost, že o data přijdete”.
Podstatné je něco jiného: SMART na tenhle typ chyby neodpoví. SMART popisuje stav zařízení a události, které disk sám zaznamenal — ne správnost obsahu vaší smlouvy. Jak číst SMART a co z něj skutečně jde vyčíst, rozebíráme v článku jak poznat, že HDD umírá.
Proč journal ext4 nestačí
Journal ext4 řeší úplně jinou úlohu, než si od něj lidé slibují. Hlídá, aby po přerušeném zápisu nezůstaly napůl provedené změny metadat — aby v adresáři nevisel záznam o souboru, jehož bloky nikdy nikdo nealokoval. To je konzistence struktury, ne správnost obsahu.
Moderní ext4 umí kontrolní součty metadat i journalu (funkce metadata_csum, ve výchozím nastavení mkfs u dnešních distribucí zapnutá). Znamená to, že poškozený inode nebo rozbitý adresářový blok systém rozpozná. Neznamená to end-to-end kontrolní součet uživatelských dat — ten ext4 neudržuje. Když vám úložiště pro určitý blok vrátí jiný, ale stále čitelný obsah, ext4 nemá referenci, proti které by ho ověřil. Nemá tedy jak zjistit, že je něco špatně, a mlčí.
Ani fsck tuhle mezeru nezaplní. Kontroluje strukturu: adresáře, alokační bitmapy, inody, počty odkazů. Nezajímá ho, jestli má v souboru stát částka 120 000 Kč, ani jestli se uvnitř převrátil jeden bit.
Navíc ho nelze spouštět jen tak. Kontrola vyžaduje odpojený svazek:
umount /dev/vas_svazek
e2fsck -f /dev/vas_svazekTo je odstávka a nutnost trefit správné zařízení. Na NAS s linuxovým RAIDem, LVM nebo proprietární vrstvou výrobce tenhle příkaz nespouštějte bez znalosti konkrétní architektury — vrstvení zařízení tam není takové, jak vypadá ve webovém rozhraní.
Co navíc dělají Btrfs a ZFS
Btrfs ukládá kontrolní součty dat i metadat do samostatných stromů, oddělených od bloků, které popisují. ZFS staví kontrolní součet každého bloku do jeho rodičovského ukazatele, takže při čtení ověřuje celý řetězec od kořene stromu až k datům. Detail implementace se liší, důsledek je stejný: pokud vypočtený součet nesouhlasí s uloženou hodnotou, systém ví, že načtenému bloku nemůže věřit, a chybu ohlásí místo toho, aby ji podal aplikaci.
Tady je potřeba oddělit dvě věci, které se v marketingových materiálech splývají. Detekce funguje i na jediném disku. Oprava ne. Systém potřebuje odkud vzít správnou kopii — druhé zrcadlo, jiného člena pole, paritu v RAIDZ. Na jednodiskovém svazku vám Btrfs poškozený soubor přesně pojmenuje a odmítne ho vydat, ale původní obsah z ničeho nevyrobí. Což je pořád lepší než ext4, který vám ho vydá poškozený a s tváří, že je vše v pořádku.
| Vlastnost | ext4 | Btrfs | ZFS |
|---|---|---|---|
| Kontrolní součty metadat | Ano (metadata_csum) | Ano | Ano |
| Kontrolní součty obsahu souborů | Standardně ne | Ano | Ano |
| Online scrub dat za provozu | Ne v tomto rozsahu | Ano | Ano |
| Samooprava dat z redundantní kopie | Ne na úrovni FS | Ano, je-li redundance | Ano, je-li redundance |
| Vestavěné snapshoty | Ne | Ano | Ano |
| Kde ho potkáte v hotových NAS | QNAP QTS a další | Synology DSM, Linux | QuTS hero, TrueNAS |
Scrub: kontrola, která musí skutečně běžet
Kontrolní součty samy o sobě nic nehlídají. Ověří se jen ten blok, který někdo přečte. Soubor, ke kterému se tři roky nikdo nedostal, může být poškozený a systém o tom neví — dokud ho někdo nepřečte celý. Přesně to dělá scrub: projde uložená data, přepočítá součty a porovná je. Když najde nesoulad a existuje správná redundantní kopie, vadný blok přepíše správným obsahem a zaznamená to.
Na Linuxu s Btrfs:
btrfs scrub start -Bd /data
btrfs scrub status /data
btrfs device stats /dataU ZFS:
zpool status -v tank
zpool scrub tank
zpool status tank/data i tank jsou pouze příklady — na produkčním úložišti si nejdřív ověřte skutečný mountpoint a název poolu. V Synology DSM je totéž schované ve Storage Manageru pod Data Scrubbing a dá se naplánovat.
Jako výchozí bod bývá rozumný scrub jednou měsíčně. Konkrétní plán ale závisí na kapacitě, rychlosti disků a provozní zátěži. Počítejte s tím, že u naplněného pole běží hodiny až dny a celou dobu zatěžuje všechny disky souvislým čtením.
A jedno důrazné varování: scrub nespouštějte ve chvíli, kdy je pole v režimu Degraded, Volume Crashed nebo Read-Only. Souvislé čtení všech disků je přesně ta zátěž, pod kterou oslabené pole dorazíte — stejný mechanismus, kvůli kterému rebuild často zabije RAID pole. Postup pro už poškozený Synology se stavem Storage Pool Degraded a QNAP s RAID Group Degraded rozebíráme zvlášť.
Jak se liší Synology, QNAP a TrueNAS
Synology. Btrfs podporují zejména firemně zaměřené řady s označením Plus — třeba DS224+ nebo DS923+. Dostupnost si ale vždy ověřte ve specifikaci konkrétního modelu a verze DSM, není to vlastnost celé značky. Důležitý technický detail: Synology nekombinuje disky nativním Btrfs RAIDem. Btrfs u něj leží nad linuxovým softwarovým RAIDem (md) a LVM. Aby to dohromady dávalo smysl, doplnilo Synology cestu, kterou si Btrfs při neshodě kontrolního součtu vyžádá druhou kopii z RAID vrstvy pod sebou. Funguje to jen při zapnutých kontrolních součtech na dané sdílené složce a při redundantním poli — obojí je potřeba zkontrolovat, ne předpokládat.
QNAP. Rodina TS-464 a spousta dalších QTS modelů běží na ext4. Ochranu obsahu souborů tam prostě nemáte. ZFS nabízí QNAP v samostatném systému QuTS hero, například u řady TVS-h674. Nestačí tedy koupit „QNAP se čtyřmi šachtami” — rozhoduje model, nainstalovaný operační systém a způsob, jakým se pool založí. Migrace mezi QTS a QuTS hero není přepínač; znamená přeložení dat.
TrueNAS SCALE. Staví na OpenZFS a dává největší kontrolu nad návrhem zrcadel, RAIDZ, snapshotů a replikace. Za to platíte nutností tomu rozumět. Pro malou firmu dává smysl tam, kde existuje dodavatel, který řešení navrhne, zdokumentuje a bude sledovat jeho stav — ne jako krabice, kterou někdo jednou nakliká a zavře.
Kolik ta ochrana stojí
Kontrolní součty jsou zadarmo — jsou v souborovém systému. Platíte za to, co je potřeba k opravě: redundantní kapacitu, dost šachet, RAM, záložní zdroj a druhou lokalitu pro zálohu.
U dvoudiskového zrcadla dostanete zhruba polovinu hrubé kapacity. RAIDZ1 nebo jednoparitní pole vás stojí kapacitu jednoho disku, RAIDZ2 nebo dvouparitní pole kapacitu dvou. Pro firemní dokumenty bývá čtyřšachtový NAS rozumnější volbou než nejlevnější dvoušachtový model — umožní odolnější konfiguraci i pozdější rozšíření a rozdíl v ceně samotné skříně je proti hodnotě dat malý. Disky, externí zálohovací úložiště a práci s migrací počítejte zvlášť.
U ZFS je vhodná ECC paměť, zejména pro důležitá firemní data. Neplatí ta internetová legenda, že ZFS bez ECC data ničí — ale platí prostá logika: kontrolní součet se počítá v RAM, takže chyba v RAM se do poolu zapíše jako „správná”. ECC to riziko snižuje. A pokud nemáte konkrétní důvod a spočítané paměťové nároky, nechte vypnutou ZFS deduplikaci; její paměťová režie je nejčastější příčina toho, že se malý pool stane nepoužitelně pomalým.
Jaké disky a konfigurace dávají smysl
Vybírejte disky určené pro nepřetržitý provoz v poli — WD Red Plus nebo Red Pro, Seagate IronWolf a IronWolf Pro, Toshiba N300. U každého konkrétního modelového označení si ověřte technologii záznamu; v nižších kapacitách se v minulosti objevily SMR disky, které se v RAIDu při rebuildu chovají problematicky. Rozdíl mezi CMR a SMR i porovnání jednotlivých řad máme v článcích CMR vs. SMR a WD Red vs. Seagate IronWolf vs. Toshiba N300.
WD Purple do NAS na dokumenty nepatří, i když je stejně velký a levnější. Je stavěný pro kamerové systémy a jeho firmware je optimalizovaný na souvislý zápis videa, kde se drobná ztráta snímku toleruje. Pro databáze a virtuální stroje to není náhrada.
Co u návrhu kontrolujeme:
- jestli systém vůbec používá datové kontrolní součty,
- jestli je ochrana zapnutá i pro konkrétní sdílené složky, ne jen teoreticky na svazku,
- jaká redundance umožní samoopravu, ne jen přežití výpadku disku,
- jestli se scrub skutečně plánuje a dobíhá,
- kam chodí výstrahy a jestli je někdo čte,
- jestli je NAS na UPS a umí se korektně vypnout,
- jestli existuje oddělená záloha a proběhl test obnovy.
U nativního Btrfs se pro důležitá data volí RAID1 nebo RAID10. Profily Btrfs RAID5/6 mají dlouhodobě známý problém s write hole a v upstream dokumentaci jsou označené jako nedoporučené pro produkci — jako automatická volba pro firemní NAS to neobstojí.
RAID, snapshot a záloha řeší jiné poruchy
Tohle je místo, kde se nejčastěji chybuje v úvaze, ne v konfiguraci:
- RAID udrží provoz při poruše určitého počtu disků.
- Kontrolní součty odhalí, že se obsah změnil.
- Snapshot umožní vrátit se ke starší verzi.
- Záloha zachrání data, když zmizí nebo se kompromituje celý NAS.
Žádná z těch vrstev nenahrazuje ostatní. Snapshot na stejném NAS není záloha — zmizí s poolem, se zařízením i s napadeným účtem správce. Ani Btrfs a ZFS neochrání před ransomwarem, pokud útočník získá práva mazat snapshoty a repliky; jak takový průběh vypadá, popisujeme v článku o ransomwaru na NAS. Vedle lokálních snapshotů proto potřebujete oddělenou kopii: druhý NAS, objektové úložiště s vhodnou retencí nebo offline médium — a principy zálohování 3-2-1 platí i pro firmu s NASem. Obnova se testuje, ne předpokládá.
Jak poznat kvalitně navržený NAS
Dodavatel by vám neměl předat jen krabici s blikajícím RAIDem. Součástí předání má být:
- popis disků, poolu, svazků a sdílených složek,
- kde přesně jsou zapnuté kontrolní součty,
- harmonogram scrubu, SMART testů a záloh,
- výstrahy nastavené na konkrétní odpovědnou osobu,
- protokol z testu obnovy několika souborů,
- dokumentace přístupů a možnost předání jinému správci,
- plán postupu při vadném disku a při degradovaném poli.
ITHOPE dokáže před nákupem posoudit objem dat, požadovanou dobu obnovy, kompatibilitu disků a potřebnou úroveň redundance. Výsledkem má být zdokumentované řešení, u kterého víte, co chrání, co nechrání a kolik bude stát jeho provoz.
QUICK ANSWER
Pro NAS s důležitými firemními daty má Btrfs proti ext4 jednu zásadní výhodu: kontrolní součty obsahu souborů a scrub, který odhalí tiché poškození dřív, než se stihne rozšířit do záloh. ZFS poskytuje stejnou ochranu a výrazně silnější správu úložiště, ale chce výkonnější hardware a zkušenější správu. Detekce funguje i na jednom disku, oprava jen při redundanci. Ani jeden systém nenahradí samostatnou zálohu.
FAQ
Pozná ext4 poškozený soubor?
Jen tehdy, když se chyba projeví jako nečitelný blok, nebo když si ji všimne sama aplikace vlastním kontrolním mechanismem — třeba archivátor přes CRC nebo databáze přes kontrolní sumu stránky. Ext4 standardně obsah datových bloků proti uloženému kontrolnímu součtu neověřuje.
Opraví Btrfs poškozená data na jednom disku?
Odhalí je a odmítne vydat, ale bez druhé správné kopie nemá z čeho obnovovat. Pro samoopravu dat potřebujete redundantní uložení — zrcadlo nebo paritní pole.
Je ZFS vždy lepší než Btrfs?
Ne. ZFS má propracovanější řízení poolů, kontrolu integrity i replikaci, ale klade vyšší nároky na návrh, RAM a správu. Pro menší firmu bývá praktičtější podporovaný Synology s Btrfs, pokud má správně nastavený scrub, výstrahy a zálohování.
Jak často spouštět scrub NAS?
Jednou měsíčně je rozumný výchozí bod. Termín upravte podle velikosti úložiště, provozní zátěže a doporučení výrobce. Při degradovaném poli scrub nespouštějte bez předchozí diagnostiky.
Chrání Btrfs nebo ZFS před ransomwarem?
Kontrolní součty ne — zašifrovaný soubor je z pohledu souborového systému korektně zapsaný soubor. Snapshot může pomoci s návratem před útok, ale jen pokud ho útočník nemůže smazat. Potřebujete oddělené přístupy, vhodnou retenci a zálohu mimo hlavní NAS.