Van (volt :-/ ) egy 4 disk-es ZFS RaidZ2 pool-om Ubuntu 22.04 LTS alatt, ami átmeneti disk elérési hibák (táp anomália) miatt kompromittálódott, nem importálható. Mit lehet vele kezdeni?
A gép (HP Microserver G8) kapott egy ideiglenes új tápot, a disk-ek így hibátlanul mennek, I/O hibák, fizikai bad sector-ok nincsenek.
- 'zpool import' felderíti, ráadásul hibátlan, online-nak mutatja a pool-t
- 'zpool import pool' azonnal elszáll disk I/O hibával, de nem közli, melyik disk-el van baja
- 'zpool import -fF pool' 8-10 órányi tekerés után száll el disk I/O hibával, de szintén nem közli, melyik disk-el van baja
A RaidZ2-nek elvileg a 4-ből 2 disk-ről is fel kellene állnia, de ha csak 1-et is kiveszek, azonnal disk hiányra panaszkodik és szintén nem importálható.
Milyen további lehetőségek, tool-ok vannak, hogy legalább részlegesen visszanyerhető legyen a pool-on tárolt adat. (Játszós home NAS ~3TB-nyi kacattal, amit ugyan el tudok engedni, ha reménytelen, de azért volt közte ez-az, amit szívesen visszanyernék - na meg, ugye a kihívás. Backup nyilván nincs :-) )
Régen elég komolyan belemásztam a ZFS témába, de ~5 éve kiszálltam ebből a vonalból, ezért sajnos nem csak hogy ennyi lemaradásom van, de még az akkori tudásom is erősen megkopott, így elkél a részletes segítség.
Hozzászólások
zpool import -Ffm, végsőként pedig zpool import -FfmX ?
Áhh, ezeket már mind végigpróbáltam (lehet, hogy a többszöri -F sem segít az állapoton :/ ), mindegyik ugyanúgy disk I/O hibával fogad reggelre :(
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
-m és -X-szel is?
zpool import -v
zdb -l
?
Köszi, utóbbiból lehet, hogy ki tudok hámozni még némi többlet-infót.
Viszont - érdekes módon - a linuxos zfstools-ból v.miért a -X (még?) hiányzik. Lehet, h keresnem kell egy frissebbet.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Hajj, sebeket tépsz fel... :D
Az a baj, hogy a ZFS olyan, mint a négykerékmeghajtás: arra jó, hogy a világ végén ragadj be, amerre más senki nem jár.
Nekem olyan rémlik, hogy a corrupted zfs.cache is tud szopást okozni, illetve ha megváltozik a device id, akkor lehet valahogy importálni közvetlenül megadva a dev nevét is.
https://iotguru.cloud
Mondjuk, van egy cache SSD is a képben, ami amúgy múltkor meghalt, de anélkül elindult a pool. Kapott másik cache SSD-t, azzal is ment már és az is stabilan ott van most neki - de megfordult a fejemben, hogy azt egyszerűen kivegyem, hátha, de ezt még nem próbáltam.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- 'zpool import pool' azonnal elszáll disk I/O hibával, de nem közli, melyik disk-el van baja
Es közben a dmesg-ben nem latszik semmi???
Nem, linux system szinten nincsenek disk hibák. (mikor gyenge volt a táp, akkor voltak write error-ok, amik miatt sajna elszállt, de most, új táppal semmi)
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Nincs benne SMR diszk?
Ennek utána kellett olvasnom, de google szerint nincs (2-3 TB WD Green/Red)
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
A WD EFAX-ok csináltak ilyesmit.
https://blog.claryel.hu
> google szerint nincs (2-3 TB WD Green/Red)
Ahogy Vasla_ írta, a WD EFAX (Red) gyanús, és elsőre ezt nem közölte a cég, bár később elismerte. Ha mégis SMR van, az okozhat ilyen problémát. Elvileg a ZFS tükrözés jó vele, de a ZRAID már problémás. Nem szekvenciálisan replikál. Az SMR diszk gyorsan kis CMR-területre írja az adatot, majd magától rendezgeti át SMR-sávokra, ami lassú. Ez abból is látszódhat, hogy írások után egy darabig aktív az eszköz, amikor a buszon már nem kap adatot. A replikáció viszont olyan tartós írási terhelést ró rá, amit nem bír követni, ilyenkor jöhet sector not found, vagy talán egyéb IO-hiba. A sok órás próbálkozás után hibázás bennem pont ezt a gyanút ébreszti.
2TB-os SMR diszkekre RAIDZ1-et már tettem nagyobb rekordmérettel, ez alajpán: https://www.truenas.com/community/threads/update-wd-red-smr-drive-compa… - azért ilyen helyzetre különösen kell a mentés. Te látod, mennyire fontos adat van rajta, lehet, hogy jó lenne most másolaton kísérletezni, ha nagyon fontos, akkor két másolat is jó lenne, bár az szerencsés, hogy hardverhiba nem látszik.
A ZFS beépített integritás-öngyógyítás funkcióját valami blogon láttam már, hogy ritka ramaty állapotot is életben tartott.
Hát, az is lehet, hogy csak türelem kell hozzá.
A cache SSD-t kivenném, és talán a zpool cache-t is kikapcsolnám.
Ha már így szóbajött, akkor scrub-al tényleg ki lehet nyírni ezeket a diskeket? 550TB az éves workload limit egy WD Red Pro-n (bármelyik), ha hetente megy a scrub egy mondjuk 16TB-s disken az már jóval efölött van.
https://www.zfshandbook.com/docs/advanced-zfs/data-integrity-and-self-h… - Nekem úgy tűnik, hogy csak olvas (végigellenőriz mindent), és ha valahol javítani kell, csak ott javít. Van ettől eltérő hivatkozásod?
Amúgy az SMR írási korlátról kösz az infót, erre még nem figyeltem.
Vanni van eltérő infóm, de remélem rossz: "New WD Red Pro "NAS" drives are rated for little more than 12 drive reads per year. So yes, monthly scrubs will eat up basically all their life." https://www.reddit.com/r/zfs/comments/whjomw/comment/ij67r5w/
Jó fogás sajnos. A linkelt Servethehome oldalon írja, hogy az SSD-kre ez írási terhelés, ezzel szemben:
In contrast, the WD ratings are actually total data transferred and WD combines writes and reads in that figure.
Szóval mégsem jó ötlet smrból várat építeni.
Az összes WD Pro CMR, pl ha megnézed a datasheet-et innen.
A WD Plus az SMR - ebben majdnem biztos vagyok, aztán lehet ott volt a keveredés hogy 6TB -ig SMR, utána CMR.
Az 550TB/y terhelés ugyanúgy érvényes a WD Gold és az Ultrastar-ra, de Seagate Exos is ugyanúgy 550TB/y, és ez a három már enterprise kategória - bármit is jelentsen az manapság.
Mondjuk nem értem hogyan lehet ilyen terhelési adatok mellett Hadoop vagy Ceph clustert rátolni ezekre a diszkekre.
Az összes Red Plus is CMR! Adatlap itt.
(A sima Red-eknél volt SMR-CMR kavarodás.)
Az meg különösen kifejezetten minősített patkány dolog a kedvenc WD cégtől, h. Pro, Plus, Proplus, Pro+, PlusPro, + és egymáshoz nagyonhasonló ill. könnyenkeverhető nevekkel zavarja össze a vásárlóit.
Minden bizonnyal rossz, illetve inkább hibás értelmezés.
HC550 datasheetjéből: "Projected values. Final MTBF and AFR
specifications will be based on a sample
population and are estimated by statistical
measurements and acceleration algorithms
under typical operating conditions,
workload 220TB/year and temperature
40C. Derating of MTBF and AFR will occur
above these parameters, up to 550TB writes
per year and 60°C ambient (65°C device
temp). MTBF and AFR ratings do not predict
an individual drive’s reliability and do not
constitute a warranty."
Ez alapján ez a workload dolog write vonatkozású, mig a datascrub az read.
HC550, értem. A WD Red EFAX SMR datasheet viszont ezt írja:
> ⁶ Workload Rate is defined as the amount of user data transferred to or from the hard drive. Workload Rate is annualized (TB transferred X (8760 / recorded power-on hours)).
Amíg nem lép egy potens amerikai hivatal a WD faszára h. tartsák magukat ipari szabvány metrikákhoz, addig ez lesz h. egyes típusoknál ugyanazt a mérési értéket így, más típusoknál meg teljesen máshogy fogják gondolni. Ha meg nem töltesz el egy fél életet az amúgy nem-is-publikus datasheet-jeinek nagyítóval, meg anyanyelvi szakjogásszal átvizsgálatával, akkor te szívod meg.
A nagy datacenter vinyóik fogyasztási adatait ÍRÁSKOR úgy határozták meg, h. írás+olvasás műveletet átlagoltak ki. Így persze h. alá tudtak kerülni a Seagate Exos-ok magasabb írási fogyasztásának (ha megtalálom a cikket belinkelem, valamelyik 3rd party Seagate exos review-nél említette meg csak úgy mellékesen a tesztelő). Holott nem meglepő módon, ha az írási teszt fogyasztásánál írási telj. felvételt mértek volna ők is, milyen meglepő ugyanannyit v. kicsit magasabbat hozott volna ki a műszer, mint Seagate-éknél. Görény patkány cég a WD. Pont mint az Intel CPU fronton, meg az Nvidia GPU fronton.
A scrub alapjában véve olvasás, checksum ellenőrzés. Ha hibát talál, akkor megpróbálja a paritásból/tükörből helyre állítani. Az 550TB/év terhelhetőség pedig írásra vonatkozik.
WD oldaláról. Az oldal alján ez a megjegyzés található:
Workload Rate is defined as the amount of user data transferred to or from the hard drive. Workload Rate is annualized (TB transferred ✕ (8760 / recorded power-on hours)). Workload Rate will vary depending on your hardware and software components and configurations.
Hát, még egyel több indok, hogy miért nem használunk sehol WD meghajtókat...
Nehogymár az olvasást is beleszámoljuk az amúgy sem magas éves rátáikba... Egy HDD-nél ugyan mi fárad el olvasás közben, ami miatt számolni kell a mennyiségét (a normál idle pörgéshez képest). Ha meg aktív az energiatakarékosság hogy ne pörögjön üresben, akkor a fejparkolást fogyasztja el a diszk... Ráadásul mindezt nem desktop-ra, hanem NAS-ba meg szerverbe szánt diszkeknél.
Mintha a WD-nél az lenne a fő tervezési szempont, hogy 1, max. 2 év után mindenképp meg lehessen tagatni a garis cserét valamilyen számláló alapján. Lehet itt is eljött a kötelező cseréltetés ideje, mint az autóknál, hogy lefutják a kilométert és vegyél újat. Itt átmegy X adat és vegyél újat. Nyilván eladni akarnak, és nem örülnek a 10 éve hibátlanul működő (így le nem cserélt) egységeknek. Nem mintha a világ termelt adatmennyisége miatt nem vennének meg tőlük most is minden diszket amit le tudnak gyártani...
Leghitelesebb forrásból, ők írják magukról:
https://blog.claryel.hu
Hát akkor most az adatlapjuknak vagy a blogjuknak higgyünk-e... persze maradhat összhang, mert 1.) a szekvenciális mindenképp kulcsszó, csak ez nem mindig teljesül, RAIDZ szinkronizálásnál pl. alig.
2.) Meg lehet, hogy végigtrimmelt (és talán amúgy is üres) diszkre írást teszteltek, az nagyon nem ugyanaz, mint egy már használt és nem trimmelt.
Seagate ugyanez, kerek perec ki is jelentik ha túlléped akkor nincs gari.
Toshiba NAS ketegória úgyszintén, függelék 5. pont a lap alján: " Workload is defined as the amount of data written, read or verified by commands from host system."
Ez lényegében a HDD mint technológia kivezetése és az ügyfelek nvme-re terelése, de jelenleg nincs megfizethető alternatíva sem kapacitásban, sem élettartalomban.
Biztosan mindenki szeretne otthonra "Enterprise Class NVMe" SSD-t , de annak már egyébb vonatkozásai is vannak.
Akkor ez lehet az oka, h. megjelent hdd-ken is a smart counterek total read / write? Mert ssd-k elterjedéséig korábban soha nem tudtál ilyet megnézni. Akkor most ez is a tervezett elavultatás része lett?
Emlekeim szerint volt ilyen SCSI lemezeknel. Ehhez kotni barmifele garanciat nyilvan gorenyseg.
Szerintem nem NVMe felé terelés, hanem arra felé terelés, hogy ne a működőképesség végéig, hanem a megfelelő számláló értékek eléréséig legyen használatban egy HDD, és vegyenek helyette újat, ha a számláló értéke eléri a limitet, független attól, hogy a meghajtó jól működik-e vagy sem.
Tervezett avulásnak nem mondanám, mert ugye nem feltétlen áll meg a meghajtó akkoriban amikor a számláló szerint vége a dalnak.
Bocs, EFAX-ra nem kerestem rá, de az enyém EFRX (ez még valami régi RED, akkor még sem Pro, sem Plus nem volt). Illetve ~5 éve ment ez is stabilan, tehát nem gondolnék ilyen konstrukciór-/típusproblémára.
Az utolsó tippet köszi, arra megyek tovább.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
EFRX jó, amikor megváltoztatták EFAX -ra, azzal kezdődött az SRM "botrány".
https://blog.claryel.hu
esetleg nézd meg a lemez saját naplóját , talán smartctl -X /dev/xxx , van e ott valami.
https://blog.claryel.hu
az otthoni szerveremben az egyik zpoolban van 2 WD40EFAX-68JH4N1 (4TB). aktív használatban van, az egyiknek 21k, a másiknak 23k a Power_On_Hours-sze (ezek csak zpoolban voltak).
még nem volt bajom velük... 🙄
szerk: sajnos a smart nem ír Total_LBAs_Written-t.
szerk: a harmadik diszknek olyan 20TB... az is olyan 23k hours körül jár, szóval valószínű, hogy a per disk write az valahol 20TB körül mozog, a per disk read pedig kb. 126TB
Ha még kérdéses, hogy hogy lehet megnézni:
Ha a DISC-MAX 0, akkor biztos nem működik a TRIM (tehát CMR, vagy nem támogatott). USB-s SMR tárakon jellemzően nem támogatott a TRIM, de SATA esetében azért ez elég megbízhatóan működik.
Másik:
(szerk: parancs javítva, fáradt voltam.)
---------------
Gondolkozom, hogy trimmelés segítene-e. Kockázatát is látom, és nem próbáltam még. És nem tudom, hogy a poolod jelen állapotában engedi-e.
Ha megpróbálnád, csak --wait paraméterrel, remélem, úgy nem árasztja el a diszk command queue-ját (valahol írták, hogy anélkül biztos), illetve lehet, hogy a --rate is segítene.
zdb -re nézzél rá ,hátha ...
https://blog.claryel.hu
(Akik katasztófaturizmus miatt vannak itt azokat hagyd figyelmen kívül.)
Menj el a grml.org oldalra.
Ott van egy livecd, azt töltsd le és bootold be (talán usbról a legegyszerűbb).
Adj neki hálózatot, installálj zfsutils és zfs-dkms csomagot, ez géptől függően eltart egy ideig (a te gépednél 10-20 perc talán)
modprobe zfs
zpool import $poolname
Ezzel kiderül, hogy az OS-nek van baja vagy tényleg a tömb.
Azért az tök vicces, hogy a HUP-osok arra verik a nyálukat, hogy a ZFS-nél ilyen nem fordulhat elő, erre tessék, nemcsak előfordul, de megoldhatatlan és visszafordíthatatlan adatvesztést eredményez.
Bezzeg ha külön RAID réteget használtál volna, most simán vissza tudnád állítani még a fájlrendszer ismerete nélkül is.
egy lószart tudná visszaállítani...
most jön bzt és elmagyarázza nekünk, hogy a RAID a tuti, a zfs meg szar... mert mer írni a diszkre és elvárja, hogy amit kiír, azt vissza is tudja olvasni...
a SMR drive-ot cseszheted bármivel... normál RAIDhoz sem ajánlják... zfs esetén meg legalább fogsz tudni róla, hogy szar az adat a diszken
ha olcsó, szar a diszk, akkor cseszheted bármivel...
Velem már megtörtént, hogy egy dm raid0-ra rakott xfs fájlrendszert mentettem meg, ami alatt hibás lett az egyik SCSI disk.
Rescue disk bebootolása után szépen összeraktam a raid-et, rádobtam egy dd_rescue-t, utána xfs_repair. Néhány fájl károsodott, amiket alkalmazás szinten egy adatbázis rebuild-del lehetett helyre hozni. Minimális volt az adatvesztés és a rendszer tovább szolgált. Akkor készítettem egy mentést is, hogy bármikor újra lehessen húzni a rendszert. Az install disk-eket ugyanis valaki "véletlenül" elvitte Görögországba. Azóta is egy jó sztori az egész háttere és környező események. Kár, hogy ingyen csináltam, mert ha csak a tizedét kértem volna, mit egy sikertelen szervízelési kísérletért számláztak, akkor is nagyon jól jártam volna.
Persze lehet, hogy zfs-sel is hasonlóan simán ment volna a történet...
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Kár, hogy ingyen csináltam
Erre mindenkinek el szoktam küldeni egy kapcsolódó rövid videót:
https://youtu.be/mj5IV23g-fE
Én is hoztam már vissza dm raid mirrort és raid5-öt is a halálból a fájlrendszer matatása nélkül (egyébként ext4 volt).
Zfs előnye számomra a snapshot lehetősége, a többi pozitívum csak a körítés. Amúgy én még nem láttam olyat, ami ne tudna összedőlni. Akár enterprise szinten is. Csak ott max van kire mutogatni.
ezt vitatnám... sokkal fontosabb szerintem a data checksuming, a self-healing... nem utolsó a compression (mert meg van csinálva rendesen) és az encryption sem... és az "ease of use" sem...
Neked. :)
ha pl. a kontroller rossz adatot ad az egyik diszkről (bit rot miatt) ... és a raid pont arról a diszkről olvas a mirrorból... akkor az appod rossz adatot fog kapni... mi több, egy scrub alatt átkerülhet ez a hiba a másik diszkre is... ergo, elcseszted (hacsak nem használtál raid6-ot)
most erre jön megint bzt és megmondja, hogy ott van a dm-integrity és miért nem használtad azt... mert rohadtul nem hatékony (amellett, hogy szar felsetupolni) és ezért nem is használja senki...
szóval: a snapshotok-e fontosak vagy az, hogy az adatok konzisztensek legyenek? ezt nyilván, magadnak te döntöd el
s csak megsúgom, hogy a hardware raid sem véd a bitrot ellen...
> s csak megsúgom, hogy a hardware raid sem véd a bitrot ellen...
Ezt a részletet viszont vitatom, mert van olyan hw raid ami véd a bitrot ellen.
Van vendor aki nem 512 méretre, hanem 523(?) formázza a diskeket és a 512 az adat, a többi a checksum.
Mondanom se kell a legtöbb raid vezérlőben nem ez van.
A ZFS-ben az a szép, hogy nem kell hozzá speciális/drága hardware, persze hw bugokat leszámítva jól jön az...
bocsánat a pontatlanságért... nyilván, van olyan hw raid, ami véd. meg a dedikált storage-ok is védenek, like netapp.
normál diszkeket meg elég nehéz úgy formázni, gondolom... szóval, azt nem a mediamarktban veszed 🤭
Ezt találtam a témában:
https://eki.moe/posts/using-520-byte-sector-disks/
https://forums.servethehome.com/index.php?threads/how-to-reformat-hdd-s…
ki is próbáltam 2 consumer diszkkel (ami itthon volt... az egyik valami HGST Travelstar 7K1000, a másik Seagate Momentus), mindkettőre valami ilyesmit írt ki:
Ez elképesztően jó, nem tudtam, hogy van ilyen. Integritásellenőrzésnél probléma, hogy az adat és ellenőrzőösszeg kiírása nem atomosan történik, ezzel így megoldható. De van szoftver, ami ezt kihasználja?
Ilyen nem-szabvány szektorméretű diszket "boltban" nem tudsz venni, és tudtommal nincs is külön hozzáférhető szoftver ami ezt használná.
Pl. Netapp használ(t, most nem tudom ilyen-e) 528 byte szektorméretet a saját eszközeiben, saját szoftverével. Onnan kiszedve HDD-t nem is ismeri fel sima kommersz szerver HBA/RAID, át kell formázni 512 byte-os szektorméretre.
van ilyen a scsi-ban: DIF/DIX? PI?, és a linux is tudja, elvileg...
/sys/block/XXX/integrity/...
Én onnan tudom, hogy a gyakorlatban nem tudja egy mezei szerver, hogy kaptam már refurbished diszket, ami véletlenül nem vot átformázva 512 byte-osra, és sem a HBA, sem a futó Linux nem látta a meghajtókat semmi módon. Nyilván kicserélte a szállító átformázottra, nem nekem kellett órákat járatni emiatt a gépet, de semmi sem ismerte fel mint használható meghajtó azok közül, amikbe akkor épp bele tudtam szerelni.
Arra tippelek, a Linux támogatás olyan céllal született, hogy ha valakinek val célhardvere (vagy csinálna), akkor a háttér már meglegyen a használatára. Esetleg olyan gyártó (embere) küldte be ezeket a fejlesztéseket, aki Linux kernelre építi a szoftverét az ilyen képességű célhardvere esetén.
Általában SAS diszkeket lehet beállítani h. több bájtot használjanak CRC-re a szektorméret kicsit megnövelésével. A mezei HBA-k nem tudják az ilyen megnövelt szektorméretet lekezelni. Gyári utility-vel, vagy linux-os sg_format tool-al lehet ezeket visszaállítani (de nem minden esetben) szokványos szektorméretre.
Hát ezen hangosan felröhögtem!!! Ezt a self-healing bullshitet mondd csak @junior013 kollégának!
Amikor a valóság szembejön a trollal, ugye.
a balfasz@hup trollkodik... hardverhiba, táp problémák miatt szétment zpool... mi köze ennek a data checksumminghoz?
Nem kötözködésnek szánom, hanem tényleg érdekel, miért jó a snapshot? Én sokkal több értelmét látom egy fájlverziónak, mint a teljes fs verziónak (pl. FILES11). De amióta van scm és pláne git, azóta már ennek szükségességét sem érzem. A szoftveres megoldások nagy előnye, hogy kiválaszthatom, mely mappákat akarom "snapshot"-olni, ezeket egymástól függetlenül tudom verziózni, ráadásul egy scm bármilyen fájlrendszerrel működik, sőt, még rendszerek között is átmozgatható a history-ja.
Nem érdemes a Git-tel összehasonlítani. Verziókövetés, zfs meg tárolás.
ZFS snapshot (snapshot nem csak zfs-nél van) kb nulla másodperc alatt elkészül, akár negyedóránként csinálsz egyet automatikusan.
Véd a zsaraolóvirusok ellen, (nyilván ha nincs teljes root hozzáférés mindenhez). Snapshot-ok datasetekhez tartoznak, lehet szeparálni.
Helytakarékos, csak a megváltozott blokkokat írja lemezre. Készitesz óránként , a 25. -et mindig törlöd, ugyanigy hetit, havit. nem mentés, nem is git.
https://blog.claryel.hu
hadd el, bzt git-be rakná az egész root filerendszert... s egy mysql db-t is... s csodálkozna, hogy az innodb file-ok korruptak, mert nem volt atomikus a művelet, ugye...
Pedig nem ördögtől való dolog, mert biza' sok-sok évvel ezelőtt volt fsvs, ami pont komplett fájlrendszernek a cvs-be rakására szolgált, és ezt nfsroot-os rendszerek frissítésénél például masszívan használtuk egy nem kicsi szolgáltatás kiszolgálófarmja alatt. Természetesen a DB-k, illetve a DB-jellegű tartalmak nem kerültek bele, ahogy az egyes node-okon futó alkalmazások is különálló entitásként voltak elrakva, úgyhogy működhet az fs verziózása, csak ugye a megfelelő metaadatok mentését/visszapakolását is meg kell oldania, a fájlok tartalmán felül.
kb. 681k file van most a root filerendszeremen (ebből 490k a /usr-ben)... na, ezt tedd be git-be... írtózatosan hatékony lesz, sebesség, tárhely, mindenféle szempontból...
nyilván, abban az időben ez volt a megoldás... de most változtak az igények is
én mindig snapshotolok upgrade előtt, pl.
de van 5 percenkénti snapshotom is, ez pl. nagyon véd a véletlen törlések ellen
Ott egy minimál OS volt fsvs-be rakva, annyi amennyi ahhoz kellett, hogy az nfsroot-os gép elinduljon, magára húzza a konfigurációt (MAC alapján fix IP-t kapott), cím/hostnév alapján az általános konfigot/a funkcionális hostgroup-ra érvényes beállításokat, végül aza dott hostra (ha volt) érvényes egyedi beállításokat), illetve felcsatolta a szolgáltatásokhoz tartozó (haproxy, redis, memcached, mysql, stb.) önállóan futóképes környezetet biztosító megosztásokat, és elindította a szolgáltatásokat.
A felállás valahogy úgy nézett ki, hogy:
-nfs-szerveren egy "live" példány kicsekkolva
-cvs/fsvs alatt egy példány
-frissítéshez az erre használt gépre checkout
-frissítős gépen chroot bele
-frissítős gépen a chroot-olt környezetben frissítés
-chroot-ból ki
-frissítős gépről cvs/fsvs-be vissza
-nfs-szerveren checkout
-nfsroot-os fizikai gépek (~100 darab) újraindítása egymás után.
Elmeletileg sokan hasznaltak ilyet rendszert, de a valosagban en sosem igazan ertettem, miert eri meg a veszodest. De hat te gyakorlatban hasznaltal ilyet, akkor biztos tudod, Miert jobb, mint egy hagyomanyosan local diszkre telepitett OS-sel vacakolni?
100+ fizikai gép, adott gép funkcióját egy konfig átírásával (adott gép melyik groupban van) és egy reboot-tal meg lehetett változtatni, illetve a frissítés is elég gyorsan ment - nem 100+ helyen kellett mindent frissen tartani, hanem egy helyen, ahonnan a legfrissebbet a tesztek alá kihúzva a tesztelés is sima ügy volt bármilyen funkcionalitást vizsgálva, stb.
A funkciókat meg képzeld úgy el,mint manapság egy konténert - csak nem image lett letöltve a gépre, hanem nfs-en fel lett húzva egy adott könyvtár, amiben "önhordó" kivitelben ott volt minden, ami például a haproxy, a redis, memcached vagy épp az Java-s alkalmazásszerver futásához az OS-en kívül kellett.
Nade cserebe mindent is csak egyszerre tudtal frissiteni es ehhez egy tenyleg nagyon merem konfiguracio kellett, nem? Vagy ez egy csak compute farm volt, mondjuk 100 db tomcat, h ki tudja szolgalni a requesteket, egyebkent zero logika?
Hogy mi volt az appszerver már nem emlékszem, de volt mellé redis, memcahed, haproxy, mysql... Nem csak compute farm volt, nagyon nem - komplett portál sok szolgáltatással...
Ez mind szép és jó, csak nem válasz a kérdésemre, hogy miért jó.
Ugyanis ha verziózni akarsz, arra sokkal jobb a FILES11 meg a git, mert fájlonként teszi (snapshotokból összeollózni egy adott mappa tegnap este 8-kori tartalmát nem kis meló), ha meg biztonsági mentés kell (pl zsarolóvírusok ellen), arra meg úgyis külön backup való (ami fizikailag másik, elszeparált eszközön tárolja az adatot, és nem azon, amit menteni akarsz).
Szóval továbbra sem derült ki számomra, minek a snapshot, milyen gyakorlati haszna van. Azt értem, hogy működik, nem az a kérdésem.
miért jó a snapshot (és itt nem csak ZFS oldaláról nézve):
- gyors, nem könyvtár illetve fájl szinten, hanem volume oldalon dolgozik. Így egy több TB kötet is csak 1 másodperc. Ha kell egy mappa előző napi verziója, akkor előveszed az előző napi snapshot-t, és egyszerűen kimásolód belőle adott könyvtárat. Nem kell semmit összeollózni.
- helytakarékos, mert nem készül a fájlokból új másolat.
- szükség van rá, mert snaphot nélkül a fogott (használat alatt lévő) fájlókat nem egyszerű lementeni.
- nem biztonsági mentés, de arra jó, hogy ha a felhasználó vissza akar állítani magának valamit, akkor saját maga meg tudja tenni, az admin segítsége nélkül.
Ez nem válasz a "mire jó?" kérdésre, a git és a fájlverziózás is piszok gyors. Használtál valaha FILES11-et? Gyorsabb, mint a ZFS.
Ugyancsak, ez a gitre és a fájlverziózásra is igaz, ez nem érv a teljes volume snapshot mellett.
Gittel nem, de fájlverziózásnál igen. Ez megint egy jó pont, de nem kizárolólagosan csak a snapshot előnye, más is tudja.
Ismételten, ez éppúgy érvényes a gitre és a fájlverziózásra is, ez nem érv a teljes volume snapshot mellett.
ok, használj Git-t illetve FILES11-t fájlszerver üzemeltetésnél.
Mi többiek meg maradunk az aktuális op. rendszernél és a hozzá tartozó snapshot opciónál.
balfaszokkal ne vitatkozz, mert
kővétrollá változolő tud atomikus snapshotot csinálni a 70-es évekbeli szutykával és gittel is. sőt, dockerhez is van biztos FILES11 meg git drivere
ne mondjam, hogy fs updatenél csinált snapshotba be tud bootolni meg hasonlók...
tisztán látszik, hogy fingja nincs az egészről, sosem használt COW filerendszert, de okoskodni azt tud... nem fogja fel, hogy van olyan szcenárió, amikor két byte változtatás miatt nem akarjuk a kétgigás file-ot 3 példányban tárolni ugyanazon a diszken... stb. stb.
szerk: csak azt mondom, hogy tőle ilyet ne várj, hogy "bocs, meggyőztetek, most már látom: tényleg kúl dolog a fs snapshot"... ő akkor is FILES11-gyel tárolná a gépén a pornót, ha már diszkek helyett már valami kvantumbites tárolók lennének... 🤭
Én azért megnézném, ahogy megtanítod a titkárnőnek, hogy a Word doksikat hogyan tudja git-tel verziózni és visszakeresni ahelyett, hogy csak simán mentené a hálózati megosztásra.
Ellenben a szerveren készült snapshot-ot látja a Windows kliensén az adott fájl régebbi verzióiként, és simán ki tudja magának is venni, ha akarja. De ezt sem tudja, ehhet is informatikus kell, pedig egységsugarú user-nek sokkal egyszerűbb, mint a git-et használni.
Ne programozóként gondolkodj, mikor üzemeltetési kérdésekről megy a diskurzus, mert ezek jellemzően nem programozók rendszereinek az üzemeltetéséről szólnak, hanem földi halandók által használt rendszerek üzemeltetéséről.
Én meg azt nézném meg, ahogy a zpool kapcsolóit tanítod meg a titkárnőnek. Az, hogy hálózati meghajtó hagyjuk, mert nem helyi snapshot, és akármi is futhat a szerveren, ez nem érv.
Éppúgy érvényes másra is. Github commit history például megvan? De van fájlrendszerként megjelenítő FUSE driver is git commitokra. Ez nem a snapshot kizárólagos előnye.
Nem programozóként kérdeztem, hanem üzemeltetőként, hogy minek energiát, pénzt, erőforrást feccölni egy olyan megoldásba, ami esetlegesen sokkal egyszerűbben, olcsóbban is megoldható. Eddig még nem kaptam választ arra, hogy mi az, amit csak a snapshot tud, semmi más. Ellenben a snapshot készítés bődületes mennyiségű memóriát zabál, HDD-n esélytelen, minimum SSD kell alá (vagy legalábbis minimum egy SSD cache, ahogy a nagy storage-ok csinálják).
ZFS -nek sok memória kell, legalább 8GB, a snapshot csak opció. A Zfs COW fájlrendszer, nem felülir, hanem megtartja a módósult blokkot és újat ir. Ezzel kikerüli a naplózó fájlrendszerek lassú szinkron irású naplözását.
Ha valami leakadás van, ott régi blokkban az eredeti . Journál fájlrendszereknél alapértelmezetten elveszhet adat, legfeljebb a fájlrendszert nem kell javítani. A snapshot meg a COW járuléka, mindegy hogy HDD vagy ssd. Az ssd cache nem ezért kell. A zil log egy gyors szinkron írást tudó kicsi enterprise PLP-s ssd-t kíván. Szinkron iráskor nem a lassú hhd -re vár az irás befejezéséig, hanem naplóz a gyors ssd-re. Ha ez lezajlott mehet a hdd-re írás mostmár aszinkron módon. Hiba esetén újrainditáskor a zil log alapján befejezi az írást. Hasonló mint a hw raid kártyák nem felejtő akkus ram-ja csinálja.
De nem kötelező a snapshot, vannak hátrányai, pl több hely kell, hiszen nincs törlés, csak a asnapshot törlésekor.
Sok szempontból összemérhető egy drága hw raid kártyával a zfs, csak a kicsiknek is elérhető.
https://blog.claryel.hu
ezt honnan veszitek? pont annyit eszik, amennyit megadsz neki...
ott írja az openzfs doksiban:
elmegy az 1GB rammal is, persze, without dedup and compression, as it is stated
a home assistant szerveremben 4GB ram van, 2x500GB SSDvel, jelenleg 297 snapshot. Az ARC-nak 256MB memóriát adtam, az uptime most 137 nap. probléma?
Én málna pc-vel használom raspi 4 4Gb Ram-mal, 2 éve már megy folyamatosan, de a doksiban ott ven ez is:8 GB+ memória a legjobb teljesítmény érdekében.
Ez meg a málna nas:
https://blog.claryel.hu/zfs-nas-malna-4gb-os-malna-pc-n/
https://blog.claryel.hu
Nem kell a titkárnőnek zpool parancsot tanulnia. ZFS nem is desktop-ra kell. Eredetileg sem oda szánták, most sem ott használjuk, hanem szerveren. A titkárnő pedig ne tartson semmi fontos adatot a desktop gépén, hanem mindent a szerveren tartson.
Ok.
Kérem a Windows FUSE driver letöltési linket, amivel a Git commit-okat Windows-on a user látja a "Régebbi verziók" ablakban.
Kérem a Samba és egyéb konfig állományokat, amik segítségével a Git-tel verziózol automatikusan egy megosztást, és az előző verziók látszanak a Windows kliens "Régebbi verziók" ablakában, és a Windows a natív beépített módján hozzáfér.
Hát, ebből egyértelműen látja, aki ismeri a ZFS-t, hogy Te nem ismered a ZFS-t. Hogyan jön össze, hogy sok memóriát zabál a HDD-n esélytelen és az SSD kell alá?
A ZFS-t a Sun fejlesztette ki akkor, amikor az SSD még elméletben sem létezett. Köszönik, remekül snapshot-oltak Ultra320-as SCSI HDD-ken, párszáz MHz-es gépeken, ahol még MB-ban mérték az operatív memóriát. Memóriát a snapshot semennyit sem fogyaszt, mert az a diszken keletkezik. A snapshot készítésnek nincs memória vonzata. Memória az olvasási gyorstárnak meg a deduplikációnak kell (ZFS esetén). A snapshot nem igényel IO teljesítményt sem, így mindegy, milyen meghajtón készül. A snapshot ugyanis egy logikai művelet, mégpedig annyi, hogy a snapshot által védett blokkokat nem írja felül a rendszer a jövőben a snapshot élettartama alatt. Egy bejegyzés mindössze (erősen egyszerűsítve). Ezért is készül el gyakolratilag azonnal, nulla erőforrás igénnyel. Ezért kell Copy-On-Write fájlrendszert használnia annak, aki jó-gyors snapshot-ot akar. (Amit pl. a VMware csinál snapshot néven, az nem ez, hanem egy szar, nem is emlegeti itt senki.)
Akkor most ezen ismeretek birtokában olvasd végig a topikot és gondold át, hol válaszoltál rosszat valami más technológiára gondolva a snapshot helyett.
Egyébként érdekelne üzemeltetésileg, hogy egy standard Proxmox telepítésen (ami szóló gépre ZFS-t javasol leginkább VM tárolásra a felxibilitása és képességei miatt) hogyan oldanád meg Git-tel egy VM bizonyos állapotának megőrzését (pl. frissítés előtt), vagy hogyan csinánál Git-tel konzisztens (vagy bármilyen) mentést a futó VM-ről snapshot helyett.
A Git meg az fs snapshot két tök másra való technológia, nem egymás konkurensei, nem lehet egyiket a másikkal kiváltani, nem is azonos szintjén működnek egy rendszeren, és nem is azonos célra találták ki.
Gizike kitörli az aznapi excel táláit. Óránkénti snapshotból visszarakod. Mentésból, ha csak nem mentesz óránként nem tudod, estiben még nincs , ma estiben meg már nem lesz.
https://blog.claryel.hu
És újfent, ezt a git és a fájlverziózás is tudja, nem a snapshot kizárólagos előnye.
Viszont a snapshot például üzemeltetői oldalról megvalósítható és managelhető, ellenben a git-tel.
Ritka az informatikában olyan probléma amit csak és kizárólag egy megoldás tud nyújtani; általában mérlegelni kell hogy mit érdemes használni adott feladatra a felhasználóbarátság/olcsóság/managelhetőség háromszögön belül.
Akkor a gitre sincs szükség , pocsékolás, ott a régi jó files11, meg a fájlverziózás. Ezek régebbiek mint a git. :-)
Más a kényelmi szintjük, a funkcionalitásuk sem 1:1 ben megfeleltethető. Kinek mi.
https://blog.claryel.hu
A Git hogyan kezeli egy nagy méretű bináris fájl változásait? (Pl. egy xlsx ugye egy tömörített szövegállomány, ami a Git felől nézve bináris).
Elmenti az új verziót kompletten (nem ez történik, de ez a végeredmény). Ahány verzió, annyiszor ~teljes helyfoglalás (és soká tart a Git művelet).
A (ZFS/btrfs) snapshot hogyan kezeli egy nagy méretű bináris fájl változásait? (Pl. egy xlsx ugye egy tömörített szövegállomány, ami az fs felől nézve tök mindegy milyen, mert a működése nem füg az állomány típusától).
Megtartja (nem írja felül) azon blokkokat (egy blokk 4k-1M feladathoz konfigurálható) amik változnak a snapshot készítése után. A helyfoglalás annyi, amennyi blokkot meg kell tartani a későbbi változások miatt (töredéke az N számú komplett másolatnak). Időbe nem telik, mert az eredeti blokk megtartása nem telik időbe, hisz már ott van, csak nem kell letörölni/felszabadítani.
cd /
cd .zfs/
cd 8orai_snapshot
# beléptél az éles gyökérből a 8 órai gyökérkönyvtárba
cp ./etc/* /etc
vagy mc , egyik oldalon a a 8 órai állapot (.zfs/8orai_snapshotod, barangolhatsz., ott a teljes könyvtárstruktúra fájlostúl, pontosan úgy , ahogy 8 őrakor volt)
https://blog.claryel.hu
Arról nem is beszélve, hogy az akár percenként - a futó rendszer megakasztása nélkül - készült snapshot-ot a háttérben szinkronizálhatod akár az offsite backup serverre, így gyakorlatilag max. pár percnyi adatvesztéssel DR rendszered lehet.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
A helyben encryptáló dolgok csúnyán megszopatják ezt a stratégiát, szóval okosan.
Gábriel Ákos
Ha megőrzöd visszamenőleg kellően sokáig (napi mentésnél legalább a mentésig) a snapshot-okat, akkor max. plusz munka kikeresni, mikortól rossz a file tartalma? Vagy nem?
Na persze az sokat mond, hogy hirtelen sokkal nagyobbak a snapshot-ok, mint addig.
A snapshot blokk szintű, szóval ha az OS felől nem látszik (a felhasználó számára nyilvánvalóan) a file változása, a snapshot-ba akkor is jegyződik, és az előzőekben elérhető az eredeti tartalom.
Feltéve hogy az offsite mentést nem tudják kompromittálni ezzel a kiegészítéssel teljesen oké.
Gábriel Ákos
Természetesen a kompromittálhatóságot biztosítani kell úgy a snapshot-os hoszton mint a mentéseken. Ez alap.
Egy S3 tároló is addig felülírhatatlan, amíg nem jutok be magára az S3 hoszt-ra és nem törlöm a rajta lévő adatokat közvetlenül, az S3 API teljes kihagyásával...
Ja igen, ezt kihagytam: pont erre is jó maga a snapshot, hogy ha monitorozod a méretét, hamar kibukhat az is, ha sz@r került a palacsintába.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
Ismételten, ez megint nem a snapshot kizárólagos előnye, más is tudja ezt.
Nem olvastam a szálat, most találtam vissza. File szerveren van, zsaroló vírusok ellen, negyed óránként van snapshot, két hétre visszamenőleg.
Másik gépben próbáltad a diszkeket? Illetve ha lehetőség van rá, én másik diszkre lemásolnám dd-vel az adatokat, és a másolatokkal küzdenék, hogy kizárjam a diszkek és a gép hibáját.