Close-up of multiple black internal hard drives stacked on a white surface showcasing circuit boards.

ZFS oporavak podataka: što učiniti kad pool zakaže

Kad ZFS pool prijavi stanje FAULTED, ne može se uvesti ili počne javljati trajne greške, podaci najčešće nisu izgubljeni, ali svaki sljedeći korak odlučuje hoće li tako i ostati. ZFS ima ugrađenu redundanciju, kontrolne zbrojeve i snimke (snapshotove), no te zaštite rade samo dok je dovoljno diskova ispravno i dok metapodaci nisu oštećeni. Ovaj vodič objašnjava što koje stanje poola znači, što ZFS može vratiti sam, koje greške najčešće pretvore popravljiv kvar u trajan gubitak i kada je vrijeme da se diskovi predaju laboratoriju za spašavanje podataka.

Datarecovery
Zaštitite podatke iz ZFS poola
Datarecovery je stručni laboratorij za oporavak podataka s NAS sustava i drugih uređaja, uključujući slučajeve kvara diskova i oštećenja podataka.

Posjetite laboratorij

Ukratko

  • Stanje DEGRADED znači da pool još radi zahvaljujući redundanciji, a FAULTED da su metapodaci oštećeni ili da nema dovoljno replika za rad.
  • Snimke vraćaju obrisane datoteke i prethodne verzije, ali ne štite od kvara diska ili uništenja cijelog sustava.
  • Ne zamjenjujte diskove naslijepo, ne pokrećite resilver na diskovima koji fizički otkazuju i ne koristite opcije uvoza koje odbacuju podatke prije nego što napravite kopije.
  • Ako je otkazalo više diskova nego što razina redundancije podnosi, ako disk klikće ili ga sustav ne prepoznaje, ili ako ZFS prijavljuje oštećene metapodatke, zaustavite rad i obratite se laboratoriju.
  • Kod nas vrijedi pravilo „no Data, no Money”: ako podatke ne spasimo, ne plaćate spašavanje.

Sadržaj

Što sve obuhvaća oporavak podataka sa ZFS-a

ZFS nije samo datotečni sustav. On istodobno upravlja diskovima (kao upravitelj volumena) i podacima na njima, pa se diskovi grupiraju u virtualne uređaje (vdev), a oni u pool. Zbog toga se ZFS ne ponaša kao obična particija na jednom disku: podaci jedne datoteke raspoređeni su po više diskova, a struktura poola zapisana je u oznakama (labelima) i metapodacima na svakom od njih. Wikipedia o ZFS-u opisuje upravo to objedinjavanje uloge datotečnog sustava i upravitelja volumena kao njegovu glavnu posebnost.

ZFS se danas najčešće nalazi na NAS uređajima, poslužiteljima za virtualizaciju i sigurnosne kopije te na FreeBSD i Linux poslužiteljima u tvrtkama. Oporavak podataka sa ZFS-a zato obuhvaća nekoliko vrsta problema:

  • Logički gubitak: slučajno obrisane datoteke ili datasetovi, pogrešno pokrenut rollback, uništene snimke.
  • Pool koji se ne može uvesti: nakon nestanka struje, premještanja diskova u drugo računalo ili nadogradnje sustava.
  • Fizički kvar diskova: oštećene glave za čitanje, površina podatkovnih ploča, elektronika ili firmware jednog ili više diskova u poolu.
  • Kvar okoline: neispravni kabeli, HBA kontroler ili radna memorija koji uzrokuju greške na inače ispravnim diskovima.
  • Kvar nakon intervencije: kada pokušaj popravka, zamjena pogrešnog diska ili prekinut resilver pogorša početno stanje.

Svaka od ovih situacija traži drukčiji pristup, a prvi je zadatak utvrditi o kojoj se radi. Kod RAID-Z polja to je posebno važno jer su podaci jedne datoteke razdijeljeni po diskovima s paritetom, slično klasičnom RAID-u. Više o tome kako se općenito pristupa višediskovnim poljima pročitajte u našem tekstu o RAID spašavanju podataka.

Zašto ZFS zakaže unatoč redundanciji

Zašto ZFS zakaže unatoč redundanciji — overview diagram

ZFS je projektiran da preživi kvar diska, ali samo do granice koju zadaje konfiguracija. Zrcaljenje (mirror) preživljava kvar jednog diska u paru, RAID-Z1 jednog diska u vdevu, RAID-Z2 dvaju, a RAID-Z3 triju. Kad otkaže više diskova nego što vdev podnosi, pool više ne može sastaviti podatke.

Najčešći uzroci kada se pool ne može uvesti ili montirati su:

  1. Previše otkazanih diskova za razinu redundancije. Tipičan scenarij: jedan disk otkaže, pool radi u stanju DEGRADED, a drugi disk iz iste serije otkaže tijekom resilvera, koji intenzivno opterećuje sve preostale diskove.
  2. Oštećene oznake ili uberblok. To su zapisi po kojima ZFS prepoznaje koji disk pripada kojem poolu i gdje je posljednje ispravno stanje podataka. Nestanak struje usred zapisivanja čest je okidač.
  3. Neslaganje verzija značajki. Pool kreiran ili nadograđen na novijoj verziji OpenZFS-a možda se neće uvesti na sustavu sa starijom verzijom.
  4. Nedostajući zapisni uređaj (SLOG) ili drugi pomoćni uređaj koji je bio dio poola.
  5. Problemi izvan diskova. Prema OpenZFS dokumentaciji za otklanjanje problema, greške kontrolnih zbrojeva (CKSUM) na disku koji nema I/O grešaka češće upućuju na kabele, HBA kontroler ili memoriju nego na sam disk.

Posljednja točka je česta zamka. Administrator vidi greške na disku, zamijeni ga, pokrene resilver, a greške se nastave pojavljivati jer uzrok nikada nije bio disk. U međuvremenu je jedan ispravan disk izvađen iz poola i redundancija je smanjena bez razloga. Praćenje SMART atributa pomaže razlikovati stvarno istrošen disk od problema u okolini; kako to funkcionira, objašnjavamo u vodiču o SMART nadzoru diska.

Što znače stanja ZFS poola

Naredba zpool status prikazuje stanje poola i svakog diska. To je dijagnostički prikaz koji ništa ne mijenja, a njegovo ispravno čitanje prvi je korak prije svake odluke.

StanjeŠto značiRizik za podatkePreporučeni smjer
ONLINESvi uređaji rade normalnoNizakRedovito pokretati scrub i pratiti SMART
DEGRADEDJedan ili više uređaja ne radi, ali redundancija je dovoljna za radPovećan: još jedan kvar može srušiti vdevNajprije napraviti svježu sigurnosnu kopiju, zatim pažljivo zamijeniti disk
FAULTEDMetapodaci su oštećeni ili nema dovoljno replika za radVisokNe pokušavati popravke na originalnim diskovima
UNAVAILUređaj se ne može otvoriti ili ga sustav ne vidiVisok ako je takvih uređaja višeProvjeriti napajanje i kabele, ne inicijalizirati diskove
Trajne greške (errors: Permanent errors)Određene datoteke ne mogu se popraviti iz redundancijePodaci tih datoteka izgubljeni su na pooluVratiti iz sigurnosne kopije ili snimke

Razliku između stanja DEGRADED i FAULTED opisuje OpenZFS dokumentacija, a značenje trajnih grešaka objašnjava službena poruka ZFS-8000-8A: datoteke navedene u izlazu zpool status -v ne mogu se popraviti i treba ih vratiti iz sigurnosne kopije.

Prvi koraci: što učiniti, a što izbjegavati

Najviše podataka na ZFS poolovima ne izgubi se samim kvarom, nego užurbanim pokušajima popravka u prvim satima. Redoslijed koji štiti podatke izgleda ovako:

  1. Zaustavite zapisivanje. Isključite aplikacije, virtualne strojeve i sinkronizacije koje pišu na pool. Svaki novi zapis može prebrisati starija stanja koja bi se inače mogla vratiti.
  2. Zabilježite stanje. Spremite izlaz zpool status -v i zpool import (bez argumenata), poruke iz sistemskog dnevnika i redoslijed diskova u kućištu. Fotografirajte oznake na diskovima i njihove pozicije.
  3. Ne čistite brojače kao rješenje. OpenZFS izričito navodi da zpool clear samo resetira brojače grešaka i ništa ne popravlja. Prvo treba otkloniti uzrok.
  4. Ne zamjenjujte disk naslijepo. Utvrdite koji je disk stvarno neispravan i postoji li problem s kabelom ili kontrolerom. Zamjena ispravnog diska smanjuje redundanciju.
  5. Ne koristite destruktivne opcije uvoza. Dokumentacija OpenZFS-a upozorava da neke opcije uvoza i vraćanja na ranije stanje uništavaju podatke. Uvoz samo za čitanje (readonly=on) omogućuje pregled bez mijenjanja, ali ni on ne pomaže ako disk fizički otkazuje.
  6. Ne pokrećite resilver ili scrub na diskovima koji klikću, usporavaju ili nestaju iz sustava. Oba procesa čitaju cijeli disk i mogu dokrajčiti oštećenu mehaniku.
  7. Ne inicijalizirajte, ne formatirajte i ne dodajte diskove u novi pool. Time se prebrišu upravo oznake i metapodaci potrebni za rekonstrukciju.

Ako niste sigurni u bilo koji od ovih koraka, bolje je stati nakon drugog. Sve navedeno je općenito i za fizički oštećene diskove vrijedi još strože; detaljnije o tome u tekstu što ne raditi nakon pada diska.

Što ZFS može vratiti sam, a gdje su granice

ZFS ima više mehanizama zaštite, ali svaki pokriva samo određenu vrstu problema.

MehanizamŠto može vratitiŠto ne može
Kontrolni zbrojeviOtkrivaju oštećen blok pri čitanju i, uz redundanciju, čitaju ispravnu kopijuBez redundancije samo otkrivaju grešku, ne popravljaju je
ScrubProvjerava sve podatke i popravlja štetu gdje redundancija to dopuštaNe vraća podatke kojih nema ni na jednoj ispravnoj kopiji
ResilverObnavlja podatke na zamjenskom disku iz preostale redundancijeNe uspijeva ako preostali diskovi imaju nečitljive sektore ili otkažu tijekom procesa
Snimke (snapshotovi)Obrisane datoteke i prethodne verzijeKvar diskova ili uništenje cijelog poola, jer su na istim diskovima
zfs send / zfs receiveKopija datasetova na drugom sustavu kao zaseban izvor oporavkaNišta što nije bilo replicirano prije kvara

Prema OpenZFS dokumentaciji o scrubu i resilveru, scrub prolazi kroz sve podatke, provjerava kontrolne zbrojeve i intenzivno opterećuje diskove, a mjesečni ritam navodi se kao uobičajena početna učestalost za potrošačke diskove. Redoviti scrub otkriva tiho propadanje sektora prije nego što zatreba resilver, što je jedan od najvažnijih preventivnih koraka.

Granicu snimki jasno postavlja i FreeBSD priručnik o osnovama sigurnosnih kopija: snimke su korisne za vraćanje obrisanih datoteka i prethodnih verzija, ali za zaštitu od kvara diska treba ih kombinirati s odvojenom sigurnosnom kopijom, po mogućnosti izvan lokacije. Replikacija naredbama zfs send i zfs receive prenosi cijelu hijerarhiju datasetova sa snimkama na drugi sustav i jedan je od načina da se to postigne.

Slučajno obrisane datoteke i datasetovi

Ako je obrisana datoteka, a dataset ima snimku iz vremena prije brisanja, oporavak je često jednostavan. OpenZFS dokumentacija o snimkama objašnjava da je snimka kopija samo za čitanje u određenom trenutku, a njezinu sadržaju može se pristupiti kroz skriveni direktorij .zfs/snapshot, pa se pojedinačna datoteka vraća običnim kopiranjem.

Opasnost je u naredbi zfs rollback. Prema službenoj stranici priručnika, rollback odbacuje sve podatke promijenjene nakon odabrane snimke, a opcije -r i -R mogu uništiti novije snimke i klonove. Rollback cijelog dataseta zbog jedne datoteke znači gubitak svega što je nastalo u međuvremenu. Zato je sigurniji redoslijed onaj koji preporučuje i FreeBSD vodič za vraćanje iz snimki: datoteku najprije kopirati u zaseban direktorij, provjeriti je i tek zatim vratiti u produkcijski dataset.

Teže je kada snimke ne postoje ili je obrisan cijeli dataset zajedno s njima. ZFS radi po načelu kopiranja pri zapisu (copy-on-write), pa stari blokovi nisu odmah prebrisani, ali ih sustav više ne prati i s vremenom ih zauzmu novi zapisi. U toj situaciji vrijedi isto pravilo kao kod fizičkog kvara: odmah zaustaviti zapisivanje na pool i ne pokušavati ništa na originalnim diskovima.

Slučajno obrisane datoteke i datasetovi — overview diagram

Novosti iz svijeta ZFS-a koje utječu na rizik

ZFS se i dalje razvija, a neke novosti izravno mijenjaju sliku rizika. U siječnju 2025. izašao je OpenZFS 2.3 s podrškom za proširenje RAID-Z polja, koja omogućuje dodavanje novih diskova u postojeći RAID-Z vdev bez prekida rada. Za korisnike je to praktično, ali tijekom proširenja sustav premješta podatke po svim diskovima. Ako tijekom tog procesa nestane struje ili otkaže disk, pool se nalazi u stanju koje je složenije od klasičnog kvara.

Drugi trend je kapacitet. Kapaciteti diskova u NAS uređajima stalno rastu, a veći disk znači dulji resilver i dulje razdoblje u kojem pool radi bez pune zaštite. Kod RAID-Z1 polja s velikim diskovima kvar drugog diska tijekom višednevnog resilvera nije teorijski rizik. O tome što donose diskovi najvećih kapaciteta pišemo u tekstu HDD od 30 TB ili veći. Za poslovne podatke na takvim diskovima RAID-Z2 ili zrcaljenje i odvojena sigurnosna kopija razumniji su izbor od RAID-Z1.

Kada prestati i obratiti se laboratoriju

Samostalni koraci imaju smisla kada je jasno da su diskovi ispravni, a problem logičke prirode i pokriven snimkom ili sigurnosnom kopijom. U svim ostalim slučajevima svaki dodatni pokušaj nosi rizik. Preporučujemo da zaustavite rad i obratite se laboratoriju ako:

  • je otkazalo više diskova nego što vdev podnosi (dva u RAID-Z1, tri u RAID-Z2);
  • disk klikće, ne zavrti se, nestaje iz sustava ili ga BIOS i kontroler ne prepoznaju;
  • zpool status -v prijavljuje oštećene metapodatke ili trajne greške, a sigurnosne kopije nema;
  • se pool ne može uvesti ni nakon provjere kabela, napajanja i verzije sustava;
  • je resilver prekinut, zapeo ili se stalno ponovno pokreće;
  • je pool prethodno bio izmijenjen pokušajima popravka, dodavanjem diskova ili rollbackom;
  • se radi o podacima koje nije moguće ponovno stvoriti: poslovne baze, računovodstvo, projektna dokumentacija, virtualni poslužitelji.

Prema OpenZFS dokumentaciji, podaci s nepopravljivim greškama izgubljeni su s gledišta samog poola, a greške u metapodacima ozbiljnije su od grešaka u pojedinim datotekama. To ne znači da su podaci nestali s diskova, nego da ih ZFS više ne može sam sastaviti. U laboratoriju se zato ne radi na originalnim diskovima: najprije se izrade kopije svakog diska, fizički oštećeni diskovi se po potrebi popravljaju u čistoj komori kako bi se uopće mogli pročitati, a rekonstrukcija poola provodi se na kopijama. Na taj način originali ostaju netaknuti i nijedan pokušaj ne smanjuje šanse za sljedeći.

Ako razmišljate o samostalnom spašavanju, pročitajte i naš tekst uradi sam spašavanje podataka, da ili ne, a za dijagnostiku diskova prije odluke koristan je naš kontrolni popis za dijagnostiku diskova.

Kako vam možemo pomoći

Datarecovery (InfoLAB) od 1993. spašava podatke s hard diskova, SSD-ova, RAID polja i NAS uređaja, a oporavak podataka s datotečnih sustava kao što su ZFS i Btrfs dio je naših usluga. Jedini smo laboratorij za spašavanje podataka u regiji s certifikatom ISO 9001:2015, radimo u čistim komorama klase CLASS 100/10, a vrijedi pravilo „no Data, no Money”: ako podatke ne uspijemo spasiti, spašavanje ne plaćate. Za hitne slučajeve dostupna je hitna intervencija.

Ako Vaš ZFS pool ne radi, ne pokušavajte dalje popravke. Isključite sustav, označite redoslijed diskova i obratite nam se za spašavanje podataka s RAID i NAS sustava. Dijagnostikom utvrđujemo stanje svakog diska i poola prije bilo kakvog zahvata. Za tvrtke koje žele urediti strategiju zaštite, preporučujemo i tekst o sigurnosti podataka u poslovnom okruženju.

Česta pitanja

Može li se ZFS pool spasiti ako su otkazala dva diska u RAID-Z1?

Sam ZFS takav vdev ne može sastaviti jer nedostaje više podataka nego što paritet može nadoknaditi. Ako je barem jedan od otkazanih diskova moguće fizički popraviti i pročitati, u laboratoriju se pool može rekonstruirati iz kopija diskova. Zato je ključno da se na diskovima više ništa ne pokušava.

Hoće li scrub popraviti trajne greške?

Ne. Scrub popravlja samo ono za što postoji ispravna redundantna kopija. Datoteke koje zpool status -v navodi kao trajne greške treba vratiti iz sigurnosne kopije ili snimke, a ako ih nema, obratite se laboratoriju prije daljnjih koraka.

Jesu li snimke dovoljna sigurnosna kopija?

Nisu. Snimke se nalaze na istim diskovima kao i podaci, pa nestaju zajedno s poolom. Štite od brisanja i neželjenih izmjena, a za kvar diskova potrebna je odvojena kopija na drugom sustavu, idealno na drugoj lokaciji.

Koliko traje oporavak podataka sa ZFS poola?

Ovisi o broju i stanju diskova, kapacitetu i tome jesu li diskovi fizički oštećeni. Izrada kopija velikih diskova sama po sebi traje satima po disku, a fizički popravak u čistoj komori produljuje postupak. Točnu procjenu dobivate nakon dijagnostike.

Izvori

Preporučeno

Objave