Odpověď hned: Tlačítko Repair v Synology DSM a Rebuild RAID Group v QNAP QTS je bezpečné jen tehdy, když platí tři věci současně: máte zálohu, ze které někdo nedávno skutečně obnovoval; víte, který konkrétní disk vypadl a proč; a ostatní disky nemají v logu chyby ani rostoucí počty vadných sektorů. Jakmile jedna z těch podmínek neplatí, rebuild není oprava — je to nejdelší souvislý zápis, jaký pole za svůj život zažije, a probíhá přesně nad daty, o která jde.
Čára nevede mezi značkami, ale mezi „ještě drží” a „už spadlo”
Do vyhledávače lidé opisují hlášku doslova, protože rozhraní NASu mluví anglicky i v české firmě: storage pool degraded, storage pool crashed, volume crashed, system partition failed na straně Synology; RAID group degraded, volume read-only, volume not active, storage pool inactive na straně QNAPu. Vypadá to jako dvě různé sady problémů. Ve skutečnosti je to jedna čára a obě značky ji kreslí na stejném místě.
Synology ji definuje sám: Degraded znamená, že jeden nebo více disků je vadných, ale pole je dál dostupné a k žádné ztrátě dat nedošlo — Repair ho může vrátit do zdravého stavu. Crashed znamená, že pole už uživatel neopraví, obvykle selhalo příliš disků a integrita dat není zaručena.
U QNAPu se ta samá čára jmenuje jinak. Read-Only není mírnější varianta degradace — je to stav, ve kterém QTS sám omezil zápisy, protože ve storage poolu něco nesedí, a některé RAID group už mohou být Not Active.
Praktický překlad: degraded je varování, crashed a read-only jsou incident. A mezi nimi leží jediné kliknutí — Repair na poli, kde druhý disk už tiše chybuje.
Co přesně která hláška znamená a jaký je u ní bezpečnější další krok, rozebírají dvě samostatné stránky: hlášky Storage Pool Degraded, Volume Crashed a System Partition Failed v DSM a stavy RAID Group Degraded, Read-Only a Volume not active v QTS. Tenhle text řeší to, co je oběma společné: jak si tři rozhodující věci ověřit dřív, než na cokoli kliknete.
Tři otázky, které rozhodují — a kde na ně v DSM a QTS najdete odpověď
Než uděláte cokoli jiného, uložte si snímky obrazovky: Storage Manager nebo Storage & Snapshots, seznam disků s modely a sloty, přesné znění hlášky a záznamy z logu. Bez nich se pak dohadujete, jak stav vypadal před zásahem.
1. Je záloha ověřená, nebo jen zelená? Zelený stav úlohy říká, že úloha doběhla — ne že z ní jde obnovit. Kontrola integrity Hyper Backupu ověřuje, že úloha může pokračovat a že zálohu jde obnovit; žádná data se při ní nepřenášejí. To není test obnovy. Otázka, která platí, zní: kdy z té zálohy naposledy někdo skutečně vytáhl soubor nebo postavil stroj?
2. Víte, který disk vypadl a proč? V DSM to čtete ve Storage Manageru u konkrétního disku (Health Info: stav Warning nebo Critical, počty vadných, realokovaných a čekajících sektorů) a v Log Center, v QTS ve Storage & Snapshots, ve stavu IHM a v systémových logách. Hledáte I/O chyby, resety sběrnice a opakované odpojení téhož slotu. Pozor na past: S.M.A.R.T. je zelený, dokud disk sám nic nevzdá — degradace se pozná spíš podle rostoucích realokací a latence než podle celkového verdiktu.
3. Jsou ostatní disky opravdu čisté? Tohle je ta nejdůležitější otázka a zároveň ta, kterou lidé přeskakují, protože pozornost přitáhne disk, který vypadl. Jenže rebuild se dotkne všech ostatních: přečte z nich souvisle obrovské množství dat a zapíše na nový. U čtyřdiskového RAID 5 se 4TB disky jde při dopočítání o zhruba 12 TB přečtených dat, u 8TB disků o 24 TB — a výrobci spotřebitelských disků uvádějí jako spodní hranici jeden nečitelný sektor na 10^14 přečtených bitů, tedy asi na 12,5 TB. To číslo je konzervativní specifikace, ne předpověď ztráty dat; nesporný závěr z něj je ale jediný: rebuild je statisticky nejrizikovější operace, jakou pole zažije.
Všechny tři kontroly jsou přitom čtení. Nic z toho nic nezapisuje — proto se na ně vyplatí strávit půl hodiny.
Co které tlačítko doopravdy zapíše
Rozhraní NASu nabízí opravné funkce v okamžiku havárie samo od sebe. Nabídka v GUI ale není doporučení pro vaši situaci — je to standardní funkce pro standardní údržbu.
| Akce v rozhraní | Co při ní na disky doopravdy jde | Kdy je v pořádku |
|---|---|---|
| Repair / Rebuild RAID Group | Souvislé čtení ze všech přeživších disků a zápis na nový; přepisuje se parita, kterou by obnova potřebovala | Jen když platí všechny tři podmínky výše |
| Recover RAID (QuTS hero) | Pokus vrátit do pole disky, které byly dočasně odpojené | Jen u disku vytaženého a hned vráceného do stejné šachty — ne u disku, který odpadl kvůli závadě |
| Create / Initialize / nový svazek | Vyrobí prázdné pole a zničí superbloky mdadm, LVM metadata i struktury souborového systému | Nikdy, když jde o data |
Check File System, fsck, btrfs check --repair, zpool scrub | Zápis do metadat souborového systému. Nástroj si poškozenou paritu vyloží jako vadu FS a smaže platné položky | Ne na rozpadlém poli |
| Přehození disků mezi šachtami | U většiny platforem spustí automatický pokus o rebuild nebo zápis metadat | Nikdy bez předchozího označení pořadí |
| Přepnutí QTS ↔ QuTS hero | QNAP to píše rovnou: „Switching to QuTS hero will erase all data on your NAS.” Platí to oběma směry | Jen s hotovou a ověřenou zálohou |
| Připojení disků z NAS do Windows | Windows ext4, Btrfs ani XFS nepřipojí a nabídne „inicializovat disk” — což přepíše tabulku oddílů a RAID metadata | Nikdy |
U Btrfs stojí za zvláštní zmínku, proč je oprava „na místě” tak zrádná: přepíše generační kořeny copy-on-write stromů, tedy přesně ty struktury, na kterých pozdější obnova stojí. Metadata se z poškozeného svazku mají číst nástrojem btrfs-restore, ne opravovat montováním.
A ještě jedna věc, kterou laboratoře uvádějí jako nejčastější a nejničivější chybu vůbec: vynucený rebuild bez jistoty, který disk je vlastně vadný. Ne exotický zásah, ne příkazová řádka — obyčejné kliknutí na tlačítko, které tam rozhraní nabízí.
Kdy přestat klikat: pokud nevíte jistě, který disk je vadný, z pole vypadl druhý disk nebo se oprava zastavila, žádné z tlačítek v tabulce nepoužívejte a NAS vypněte. My disky naklonujeme, skutečný stav pole a svazku zjistíme nad kopiemi a teprve potom vám řekneme, co jde zachránit a za kolik. Víc na stránce záchrana dat z RAID a NAS, případně pošlete nezávaznou poptávku.
Pět situací, kdy „degraded” neznamená vadný disk
Model „vypadl disk, tak ho vyměním” sedí na jeden konkrétní případ. Tady je pět, kde nesedí.
- Zdravý disk vypadl kvůli timeoutu. Desktopový SATA disk nemá časově omezené zotavení z chyby a na slabém sektoru se zacyklí na desítky sekund až dvě minuty. Řadič, který čeká 7 až 30 sekund, si to vyloží jako poruchu a disk vyhodí; disky do NASu mají TLER, ERC nebo CCTL a vzdají se zhruba po sedmi sekundách. Zrádné je, že takový disk pak samostatným testem projde bez chyby.
- V poli je SMR disk. Při rebuildu do něj jde dlouhý souvislý zápis. Jakmile se zaplní jeho vyrovnávací oblast, začne přepisovat celé pásy metodou read-modify-write v reálném čase a propustnost spadne na jednotky MB/s. Řadič překročí timeout a disk vyřadí — opakované pokusy stav jen zhoršují.
- Odešla NVMe cache SSD. Cache drží nepotvrzené zápisy mířící na pole; není to odhoditelná kopie. Když zemře, může spadnout celý Btrfs svazek, přestože jsou všechny mechanické disky zdravé.
- Byl výpadek proudu. Napájení zmizí mezi zápisem dat a aktualizací paritního bloku a pole zůstane nekonzistentní. Zákeřné je, že NAS pak naběhne a vypadá normálně, zatímco poškozený zůstal katalog záloh, databáze nebo obraz virtuálního stroje.
- Nesouhlasí event countery v superblocích mdadm. Pole se odmítne složit z disků, které považuje za zastaralé, přestože na nich data jsou.
mdadm --assemble --forcebez znalosti event countu, offsetů a pořadí disků je hazard, ne oprava.
Společný jmenovatel: v žádné z těch pěti situací není řešením rebuild. A ve všech pěti ho rozhraní ochotně nabídne.
Dva doložené případy: nejnebezpečnější je plánovaná údržba
Synology DS2015xs, RAID 6, šest 6TB disků. Pole běželo v sestavě pěti disků WD60EFRX (CMR) a jednoho WD60EFAX (SMR), který se do něj dostal jako náhrada za vadný CMR disk. Nový disk začal chybovat, výkon spadl na nepoužitelnou úroveň, NAS nešlo korektně vypnout ani restartovat a nakonec se nezapnul vůbec. Laboratoř, která případ řešila, ho shrnula větou, kterou stojí za to přečíst dvakrát: „NAS truly did not report any failures or outages.” Záznamy o chybách v logu byly. Upozornění pro uživatele žádné.
Netgear ReadyNAS, X-RAID nad Btrfs. Scénář „zvětšujeme kapacitu za provozu”: tři 3TB disky se postupně měnily za 6TB, vždy s dopočítáním pole mezi výměnami. Nově vložený 6TB disk začal uprostřed dopočítávání hlásit ATA chyby a z pole vypadl i druhý disk — ten, který následným samostatným testem prošel bez chyby. Nedokončený rebuild poškodil metadata i souborový systém.
Z obojího plyne to samé: nejnebezpečnějším okamžikem života NASu není havárie, ale plánovaná údržba — výměna disku, rozšíření kapacity, migrace. A hlídač, na kterého firma spoléhá, nemusí zahlásit vůbec nic; stojí za to ověřit banalitu, jestli notifikace z DSM nebo QTS chodí na adresu, kterou někdo čte.
Kdy přestat klikat okamžitě a bez diskuze
- Stav je crashed, inactive nebo read-only.
- Chyby hlásí víc než jeden disk.
- Disk cvaká, opakovaně mizí nebo mu rostou čekající a realokované sektory.
- Repair nebo rebuild už jednou proběhl a nedoběhl — nebo doběhl a stav se nezlepšil.
- Někdo už zkusil reset, reinstalaci systému, výměnu více disků nebo přeházení slotů.
- Data existují jen tady.
V těchhle případech není další kliknutí pokus o opravu, ale zápis do jediné kopie. Vypnutá data jsou stabilní. Když se nedaří dostat data ven ani po vypnutí a připojení disků jinam, popisuje možnosti a jejich rizika text o tom, jak vytáhnout data z NAS, když NAS umře.
Co si připravit, než někomu zavoláte
- Model NASu a verzi systému (DSM, QTS, QuTS hero).
- Počet disků, jejich přesné modely a kapacity a pořadí šachet.
- Typ pole (RAID 1/5/6/10, SHR-1, SHR-2, X-RAID) a souborový systém (ext4, Btrfs, ZFS).
- Kdy naposledy všechno fungovalo a co se dělo těsně předtím — výměna disku, výpadek proudu, aktualizace, migrace.
- Co už se zkoušelo. Hlavně jestli běžel rebuild, initialize, kontrola souborového systému nebo připojení disků do Windows. Není to otázka na viníka, ale na to, co je ještě na discích.
- Jestli existuje jakákoli záloha a kdy z ní naposledy někdo obnovoval.
Časté dotazy
DSM nabízí Repair. Neznamená to, že je to bezpečné?
Ne. Repair je standardní funkce pro standardní situaci — degradované pole, u kterého je jasné, který disk vypadl, a ostatní disky jsou zdravé. Rozhraní nezná stav vašich záloh ani to, co se s polem dělo minulý týden. Nabídka tlačítka není vyhodnocení rizika.
Pole je degraded, ale sdílené složky jsou dostupné. Můžu si data zkopírovat?
Když disky nezní mechanicky špatně a v logu nejsou chyby na dalších discích, dává smysl vytáhnout nejdůležitější složky, ne spustit kompletní zálohu na mnoho hodin — celoplošné čtení je u nestabilního pole zátěž, která umí urychlit to, čemu se snažíte vyhnout. Zálohovací úlohy, indexaci, kamerové záznamy a naplánované SMART testy nejdřív zastavte.
Disk po výměně otestoval jako zdravý. Můžu ho vrátit zpátky?
Fyzicky ano, ale odpověď na otázku „proč tedy vypadl” tím nemáte. Disk, který z pole odešel kvůli timeoutu nebo kvůli chování SMR firmwaru, projde samostatným testem bez chyby a v poli se bude chovat stejně jako předtím.
Pomůže mi obnovovací program, který mám na Windows?
U vícediskového pole ne. Programy tohoto typu skenují jeden disk po druhém a pole neumí složit — soubor rozprostřený přes stripy z nich nevznikne.
Máte pole ve stavu degraded, crashed nebo read-only a nechcete kliknout špatně? Pošlete nám snímek obrazovky z DSM nebo QTS a napište, co už proběhlo — řekneme, jestli jde ještě o běžný servisní zásah, nebo je bezpečnější NAS vypnout a pracovat z kopií disků. Jak probíhá záchrana dat z RAID a NAS, včetně toho, co se děje s originálními disky, popisuje stránka služby.
Zdroje
- Synology: Repair a Storage Pool (definice Degraded a Crashed) — kb.synology.com
- Synology: What can I do if one of my volumes crashed? — kb.synology.com
- QNAP QTS 5.2: Storage pool status (Read-Only, Not Active, Inactive) — docs.qnap.com
- QNAP QTS 5.1: Recovering a RAID Group with a Degraded status — docs.qnap.com
- QNAP: Can I switch my NAS OS? (přepnutí QTS ↔ QuTS hero maže data) — qnap.com
- Rossmann Repair Group: What Happens During a NAS Crash (Btrfs, NVMe cache,
btrfs-restore) — rossmanngroup.com - Rossmann Repair Group: Why Rebuilding a Degraded RAID Destroys Data — rossmanngroup.com
- SmallNetBuilder: The Seven Biggest Mistakes When Attempting Data Recovery — smallnetbuilder.com
- Wikipedia: Error recovery control (TLER, ERC, CCTL) — en.wikipedia.org
- EXALAB: Obnova dat z RAID po selhání HDD v NAS (případ Synology DS2015xs) — exalab.cz
- EXALAB: Obnova dat z NAS Netgear, když RAID 5 selže (případ X-RAID a Btrfs) — exalab.cz