Fórumok
Proxmox, zfs bootlemezzel , zfs mirror. Ezeken 3 partició, első kettő a bios, uefi boot partició, a harmadik a zfs. Meghibásodik az első kettő az egyik lemezen, zfs erről nem tud, megy vígan minden. Kövezkező bootoláskor viszont - de addig nem - degraded állaptba kerul a zfs pool.
De mi van akkor , ha nincs újrainditás csak félévente, 3 havonta, és közben a másik lemezen is elszáll az első két partíció. Ez már csak az újrainditáskor derül ki, hibás a két lmez miközben a zfs-nek semmi baja. Hogy lehet ezt észlelni, vagy ez van ? Vagy ez csak főpróba nálam majréból ?
Hozzászólások
Szia!
Egyrészt a rendszert külön diszkre kell rakni (raid1 mdadm), azon EXT2 -boot, EXT4 -rootfs.
Másrészt nem használok EFI/UEFI -t és GRUB -t sem, helyette Legacy/BIOS és Syslinux/EXTLINUX (gptmbr).
Többi "tároló" diszken mehet a ZFS.
Tudom nem volt válasz a kérdésedre, de hátha. :)
Best practice, de nem feltétlen kell külön lemez. Az itthoni játszós proxmoxon van 4 lemez, az első 2 partíció RAID1 (/, swap) a harmadik a zfs egyik lemeze.
A legacy-ra nagy +1. Egyszerű és megy.
Indítónak: ilyenkor előveszi az ember a mentést és felhúzza újra az egészet.
Hát, van ez, amit tanácsolsz, meg van az amit a Proxmox készítői tanácsolnak. A kettő jelen esetben nem fedi egymást.
A Proxmox gyári ajánlása, hogy ha Root on ZFS a felállás, akkor UEFI-t használjon a rendszer, és ilyen esetben a Proxmox telepítő sem a grub-ot hanem a systemd-boot-ot használja.
Persze a Proxmox, mint a legtöbb Linux alapú rendszer majdnem tetszőlegesen telepíthető és alakítható, de én azt gondolom, hogy egy type 1 hypervisor-nak szánt rendszer készítői ennyi év gyakorlattal tuidják miről beszélnek, nem feletétlenül az egyszerű utat javasolják.
ha az problema, hogy nem mennek a virtualis gepek, akkor ujrainditas elott migralni kell a virtualis gepeket egy masik gepre.
tudom ez sem valasz :)
neked aztan fura humorod van...
Nem tudod, hogy nem fog bebootolni a gép.
https://blog.claryel.hu
azert jo megelozeskeppen elotte migralni.
meg ha ujraindul is, akkor is rovidebb a kieses.
persze ha nem problema hogy nem mennek a virtualis gepek, akkor ki lehet hagyni.
neked aztan fura humorod van...
Zpool scrub
Gábriel Ákos
A scrub lefut, amig újra nem indítod a szervert. Ha a zfs partíciőban nincs hiba , nem veszel észre semmit. Akár törölherted az összes partíciót, ZFS scrub lefut, amíg újra nem inditasz. Csak az ujraindításkor ellenöriz. Akkor degraded. Szerintem előfordulhat , ha mind a kettő boot partició meghibásodik nem tudsz róla. A "proxmox-boot-tool status" talán mutat valamit, de nem próbáltam.
https://blog.claryel.hu
Nem segít, de mi elég sok Proxmox-ot használunk, és leszoktunk alatta ZFS használatáról.
Érdemben nem sokat ad proxmox működéséhez ZFS, LVM alatt is mindent megtudsz vele csinálni amit ZFS-el, cserébe kevésbé erőforrás zabáló, és az ilyenekre sem érzékeny.
Személy szerint én nagyon szeretem ZFS-t, és használjuk is rendesen, de PVE alá kb. pont felesleges.
Nagyobb VM szám esetén, ahol generálódik rendes IO mennyiség is, u.a. hardveren ZFS alatt vannak performancia problémák, LVM alatt nincsenek.
Ez nem ZFS hibája, hanem vagy VM-eknek adsz memóriát vagy ZFS-nek, az nem járható megoldás hogy pl. 128Gb RAM mellett, ZFS kap 64-et hogy normálisan működjön.
Én egy ellenvéleményt fogalmaznék meg, mert én pont, hogy rászoktam a ZFS-re. Sokkal többször szívtam LVM-el mint ZFS-el. Nagy IO terhelés alatt nekem többször rogyott meg LVM-es gép, volt amin a gyártó RAID kártyát cserélt másik típusra, mert nem tudta megoldani a problémát. A snaphot is vacakolt már LVM alatt, ZFS-el nekem soha. A live migration is szívatott meg LVM-el, ZFS soha.
Számtalan lemezhibát jelzett előre a ZFS, nem volt gondom vele, míg HW RAID-el viszont volt többször is átéltem disaster-t, mert összedőlt a tömb.
A memória igény az tagadhatatlan, de nálam ez nem probléma, mert nem terhelem túl a host gépeket és a memória a szerver költségét nem borítja meg. Én úgy tapasztalom, hogy átlagosan 32GB már elégséges a ZFS-nek. Nálam simán járható út a ZFS extra memória igénye. Nálam ami nem járható, a host alulméretezése konstans nagy io terheléssel.
A guest gépeken sokat teszteltem a kettőt, de nem tapasztaltam eltérést, szignifikáns volt az eredmény, az LVM nem tudja "lenyomni" a ZFS-t.
Jelenleg hat cégnél, kb 30+ ZFS-es proxmox host-ot felügyelek.
Abszolút egyetértek. A ZFS memóriafoglalása egy ideje már teljesen jól korlátok közé szorítható ha valaki ezt szeretné de általában nem kell.
Ez az "elpusztul a boot" elég hipotetikus esetnek tűnik, elmúlt 10 évben egyszer sem tapasztaltam.
Amikor én csesztem el akkor is percek alatt vissza tudtam állni mentésből.
A RAID továbbra sem - ZFS alatt sem - backup, csak availability.
Gábriel Ákos
Tud fura lenni, mikor a ZFS hirtelen megeszi a memória felét :) de nem kell vele foglalkozni, "visszaadja" ha szükség van rá, ezen kívül akit zavar, fizikailag is lel lehet korlátozni a ZFS-t egy egyszerű paraméterrel.
Ezt még mindig van aki nem érti :D
Én is írtam hogy szeretem ZFS-t, sőt vannak olyan szerepkörök amire nem is tudok mást elképzelni.
De ahogy te is írod "átlagosan 32GB már elégséges a ZFS-nek", ami mindig viszonyítás kérdése hogy mihez képest sok vagy kevés.
Mi is elég sok helyen használunk Proxmox-t, PBS miatt szerintem kb. verhetetlen jelenleg a virtualizációs platformok között, de azért vannak helyek ahogy 64Gb RAM van egy host-ban, aminél sajnos nem lehet a felét beáldozni, ha meg limitálod pl. 8Gb-ra akkor meg jönnek a performancia problémák.
Performancia, hibatürés szempontjából nem látok érdemi különbséget ZFS és LVM között, lehet hogy szerencsénk van de az elmúlt ~10 évben sem LVM-et, sem ZFS-t nem láttam összeborulni. Mindkettő kifejezetten jól viseli még a ridegtartás is (rendszeres power off-ok pl.).
ZFS-t sajnos nem lehet Proxmox alatt pl. share-ed storage-el használni, ami nekünk kell még egy csomó helyen, persze LVM-en meg nincsen storage esetén snapshot szóval .... :D
iscsi-val miért ne lehetne?
Gábriel Ákos
Ez igaz, akkor javítom arra, hogy ahol én használom és ahogy használom általában elég :)
A Proxmox-PBS páros szerintem is nagyon ütős, ha ilyen tudást akarsz licencelt dolgokból összerakni a csillagos ég a végeredmény :D
Hát azzal bukjuk a ZFS lényegét, bár elvileg van "ZFS over iSCSI" de én arra még nem vetemedtem. Ha használja valaki szívesen venném a tapasztalatait.
A PBS-el van már arra lehetőség, hogy ne a szerver irányából, hanem a backup szerverek felől végezzem a mentést?
Tehát a szerverről (annak megtörése esetéb) ne lehessen elérni a backup-okat?
nincs. a proxmox aktiv kozremukodese szukseges a menteshez: az encryptalas is pve oldalon tortenik. a "fast incremental backup"-hoz (pl: 6.1 GiB dirty of 256.0 GiB total) is aktiv qemu kozremukodes kell. stb. ha vedeni akarod a hacker/trojan ellen az adatokat, akkor synceld egy masodik (helyi vagy tavoli) pbs-re. az pull modban fut.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ez egy megközelítési probléma ami sokszor vita tárgya, hogy a pull, vagy push mentés a biztonságosabb, mert ha megtörik a mentő szerver, pull esetén arról elérni a host gépeket is. Push esetén is sokféle képen lehet védeni az adatokat.
Szerintem erre nincs jó válasz és nincs szent igaz út.
A Proxmox ezt egy elegáns huszárvágással oldotta meg, a host-ról push, viszont egy másik PBS-ről lehet pull leszedni a mentést. Így a rendszer mindkettőt tudja és host oldalról egyszerűbb használni. A most "divatos" 3-2-1 mentési elv szerint amúgy sem elég egy mentés fizikailag.
https://pbs.proxmox.com/docs/managing-remotes.html
Én a több helyre történő pull mentést preferálom.
A mentési stratégia kidolgozása sokkal nehezebb mint elsőre tűnik, amit mi sem bizonyít jobban, hogy nagy cégek, komoly erőforrásokkal is képesek elrontani, és komoly problémába kerülni egy szofisztikált támadás esetén.
Ez első lépés meghatározni, hogy mi is a mentés célja és milyen a környezet, mert az alapján érdemes módszer választani. Amiről jelen esetben szó van, a PBS, ami egy könnyen kezelhető, napi használatú eszköz. Ebben az esetben ha ragaszkodnánk a pull mentéshez, lábonlőnénk magunk, mert lehetne készíteni egy saját rendszert, ami biztosan rosszabb és problémásabb mint a PBS, ráadásul a PBS képes pull-ra egy másik PBS-ről, tehát közvetve lehet pull mentés.
A napi feladatotokra a pull macerásabb a nehézkes visszaállítás miatt, arra push jobb. A disaster mentésre viszont a pull a jobb, ezért én mindkettőt szoktam alkalmazni, sőt van olyan tényleg kritikus környezetem ahol három féle(!) mentési rendszer dolgozik egymástól függetlenül. Windows-os gépen van Windows Backup a napi vacakolásra (ami iSCSI-n a storage-n snapshot-olva nem is olyan rossz), van PBS+PBS2 pull a geust gép mentésére és van egy restic ami kizárólag offsite adatmentést végez.
Szóval nekem nincs kedvencem, az adott környezettől és feladattól függ, mi a legoptimálisabb megoldás.
Én nagyon szeretem a stratégiákat, különösen a "stratégiai dokumentumokat" egy POC mentén megvizsgálni.
A puding próbája mindig az evés, lássuk x y dolgot "kibír-e" a konstrukció. Nem elvi szinten, gyakorlatilag, tényleg.
Én különösebb stratégia nélkül a következő megoldást implementáltam:
- pbs-re mentés alkalmazásnak megfelelő gyakorisággal és retention policyvel. Ez a PBS helyben van de NASra ment, vm szinten.
- restic mentés felhőbe az előzőtől teljesen függetlenül
- restic mentés a NAS egyéb részeiről, magát a PBS volume-ot nem mentem. Megtehetném, az se lenne elviselhetetlen költség.
- távoli tervben van egy remote PBS "csak" össze kéne rakni
Mindkét restore módszert próbáltam már, hol szándékosan hol mert tényleg kellett :)
A restic mentés azért életszerű a sok vm-re meg konténerre mert megoldottam ansible-ből a terítését.
Gábriel Ákos
Én már rég, teljesen rákattantam a restic-re :D Nagyon nagy kedvenc.
Már windows gépeket is azzal mentek, van egy python scriptem és csak egy konfig fájlt kell alátennem. A windows-os beüzemelése néhány perc, a linux-on meg inkább másodperc :D
Még sosem szívatott meg, és van valami perverz abban, amikor a windows-os mentésből az elbazsevált fájlt a linux-os gépemen állítom vissza és teszem újra a windows-ra :D Mount-olva a mentést egy find és pillanatok alatt megvan amit keresnek. Nagy csilgány, rohadt drága mentővarázsló rendszereket aláz a tudása.
Ez azért nem _annyira_ fontos szerintem a Proxmox ökoszisztéma esetén, mert a PBS-en elég jó a jogosultsági rendszer.
A PVE kap egy PBS user-t a mentések végrehajtásához, ami menteni és max. státuszt nézni tud, azt is csak egyetlen datastore-ra korlátozva, akár egyetlen namespace-ban. Így a tároló állapota látszik a PVE felületen, és a mentések működnek zavartalanul. A PVE mást nem tud így csinálni a PBS-en, így nem tud sem belépni az a user a PBS-re (GUI-n vagy SSH-n át), sem módosítani, törölni nem tud meglévő mentést. Olyan szintig korlátozható, hogy még visszaállítani se tudjon az a user, csak menteni, és ha visszaállítási igény merül fel, akkor azt egy másik user-rel végezze az adminisztrátor.
A PBS így elég jól meg van védve egy feltört PVE felől érkező próbálkozásokkal szemben.
A második PBS pedig pull módban húzza magára az első PBS-ről a mentéseket, és ott is megvan a jogkör szűkítés, hogy a második PBS csak ezt végezheti (olvasás, replikálás, szintén datastore és/vagy namespace limitálással), mást nem. Tehát a megtört második PBS-ről sem lehet az első PBS-en lévő mentést tönkretenni.
A retention policy-t meg az első PBS tartja be, Ő kezeli helyben az elévült mentések törlését, a hely felszabadítását (nem a PVE, annak joga sincs ilyen műveletekre).
Az első PBS megtörése esetén tönkre lehet tenni a mentéseket, de sem a PVE-hez sem a második PBS-hez nem lehet onnan hozzáférni, szóval sem a hypervisor, sem a mentések nem esnek áldozatul.
Persze mindehhez kell, hogy ne azonos hálózaton legyenek, azonos user-rel és jelszóval...
Ez így nem teljesen igaz. Egyfajta aszinkron shared lehet a ZFS, a beépített replikáció miatt. Nekünk van olyan üzemeltetett ügyfél rendszer, ahol nem volt elvárás a nagyon nagy rendelkezésre állás, de szántak rá pénzt, hogy azért egyetlen szerverénél magasabb legyen a megbízhatóság. Így két host van, ZFS-sel, fele-fele VM-mel, és egymásra replikálnak 15 percenként. Amennyiben az egyik host váratlanul megállna, akkor a másikon a kieső VM-eket el lehet indítani max. 15 percnyi adatvesztéssel (jobb, mint a backup-nál használt 1 napos), ha kiderül, hogy a megállt host nem indítható el semmiképp.
Sőt, live migration is működik szépen, a shared storage-okon megszokott üzemkiesés nélkül, így a "váratlan" karbantartások is megoldható leállás nélkül. Mondjuk ez csak 8 órás munkaidőben használt rendszer, nem 7/24, így könnyen tervezhető a leállásos karbantartás.
Persze mentés és mentés mentése van mindkettőről, mert ez a replikáció nem mentés ugyebár.
Ha az LVM mindent tudna, amit a ZFS és még gyorsabb is lenne, akkor kb. senki nem használna ZFS-t. Namost ennek az ellenkezője jellemző manapság.
ZFS-en tökéletes a hibakezelés, hibajelzés, megfelelő hardver és szoftver konfiggal a teljesítménye is ugyan olyan jó. Snapshot szenzációs, btrfs-en kívül semmi más nem tud ilyen jó és ilyen gyors snapshot-ot, ahogy a replikációt szintén. Ráadásul egyszerű használni, nem kell több külön réteggel egyesével bűvészkedni (MD, LVM, Geli, stb. egymáson...).
Az, hogy memória kell neki, nem nagyon dolog a mai memória árak mellett. Használt szervernél gombok a memória, új szerver meg olyan drága, hogy a drága memória sem ront érdemben a végösszegen. Ha adsz neki 64 GB-ot (a ZFS-nek), akkor az mindenre is elég (hacsak nem sok TB van abban a VM host-ban). Az meg pénzben semmi, hogy 128 GB helyett 192 GB legyen egy szerverben.
Na persze ez nem vitázás, hanem vélemény. Olyan rendszert használjatok ami nektek bevélt, mert azt lesz a legkönnyebb üzemeltetni.
Úgy néz ki, az EFI nem része a RAID-nek, a proxmox-boot-tool a mirrorokra, tömbökre átmásolja az EFI particiót, illtva az EFI változásokat. Viszont előfordulhat az a furcsa helyzet amit leirtam.
Ritka eset, de kellemetlen, nem veszed észre, már csak egy efi particiód maradt.
https://blog.claryel.hu
ennek egyszeru az oka: a regi (0.9, 1.0) mdadm metadata a device vegen volt, ha csak siman raneztel egy backend devicere, akkor egybol lattad a "felette" levo particiot. igy barmi (lilo, grub1) ha nem irt ra, akkor sima tudta olvasni, nem is foglalkozott vele hogy ott raid van. az uj metadata mar a device elejen van, ugy ha valaki olvasni akar rola akkor tudnia kell hogy milyen raid van ott, azt hogy kell olvasni. az uj grub tudja az mdraid particiot olvasni, az efi nem. ezert kell ket fuggetlen particio, ami kozott masolassal syncelik az adatot. (amugy se gyakran valtozik, tehat nem kene gondnak lennie).
Ha valaki megis olyan perverz hogy az efi adatokat is raidben akarja rakni, akkor szerintem regi metadata-s mdadm-al meg lehet tenni.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nem a másoláson van a hangsúly hanem h időnként csekkolni kéne.
Gábriel Ákos
Nem pontosan értem a felvázolt szituációt. Az EFI nem lehet ZFS, annak mi köze a pool-hoz? Ha gond van vele, de a lemez maga elindul és gép be tud boot-olni másik lemezről, akkor a pool menni fog.
Ha nem boot-ol a gép, mert lehal az összes efi partíció, akkor meg fogod a lemezeket, berakod egy másik gépbe amin van ZFS és onnan leszeded az adatokat.
De persze erre nem lesz szükség, mert gondolom a mentés meg van oldva :)
Nah, megnéztem. Wow, valamikor az elmúlt sok év alatt csak változott a proxmox, ezek a partíciók már tényleg nincsenek bedugva egy md alá.
Ergo ebből a szempontból igazad bír lenni, meg bír dögleni ez a két partíció észrevétlenül.
Ha md alatt lenne akkor ugye lenne időnként check.
Lehet hogy most is van, nem tudom, meg kéne nézni.
Ha LVM-es módon rakom fel a proxmoxot akkor ott ezek md alatt vannak? Ha nem akkor ugyanúgy fennáll a probléma (vagy nem, ha van valami beépített check).
Gábriel Ákos
Szerintem olyan nem fordul elő a gyakorlatban, hogy két diszk első két partíciója elmúlik, miközben a ZFS felügyelte alatt álló 3. partíció meg hibátlan végig mindkét diszken. Amikor elkezd bármit hibázgatni a meghajtó, akkor az 99+ %, hogy a ZFS-es részt is érinteni fogja, amit az nagyjából azonnal észre is vesz.
Ráadásul a boot és EFI pont nem csinál semmit üzem közben, ha bármi adattroló rész meg is fárad, az a ZFS felügyelte root-on fog elfáradni, nem a diszk első GB-ján.
Olyan szerintem nincs, hogy a ZFS csak újraindításkor veszi észre, hogy a pool degraded. Ahogy kellően sok hiba előfordul egy VDEV-en, akkor azt kiköpi, és a pool degraded lesz azonnal.
A felvázolt (szerintem soha be nem következő) problémát viszont valószínű SMART monitorozással el lehet kerülni. Mert ha használhatatlanra romlanak egy diszk egyes részei, annak meg kell jelennie a SMART adatokban, amit viszont lehet monitorozni és riasztani ezek alapján.
A felvázolt eset másik oldala meg az, hogy egyébként ugyan mi baj származhat mindebből? Ha újraindítottad a szervert, akkor az mindenképp üzemkiesés, ami vagy átterheléssel, vagy terhelési időn kívüli karbantartással van megoldva. Ha kiderül, hogy a root (amit ZFS-en van) hibátlan, de mindkét diszk boot része odavan, akkor cserélsz egy diszket, teszel rá új boot-ot, ZFS replace, majd másik diszk csere, boot rendbehoz, ZFS replace és mehet a gép tovább. Mindössze az állásideje lesz több, mint eredetileg egy újraindításnál lett volna (de ugye tervezett karbantartás van, ennyire csak nincs kiszámolva...). Na persze ha távol van a gép, az szívás, szóval jobb a monitorozás, és hiba/prefail esetén diszk csere tervezetten.
Ok, nem fog összeülni az ENSZ biztonsági tanácsa emiatt, de az megtörténhet , hogy az egyik lemezen valami miatt eltűnt a particiós tábla (mint ahogy velem ez megtörtént), csak véletlenül vettem észre.
Szóval nem veszed észre, mert nem.
Megy a gép így hosszú hónapokig, közben beszarik a másik ssd elektronikája. Nemindul. Közben van egy hibátlan pool-od.
https://blog.claryel.hu
Értem, hogy lehet ilyen edge case. De azt hogy nem veszed észre, hogy beszarik a másik SSD elektronikája? Ha beszarik, akkor a rajta lévő ZFS degraded lesz.
Vagy úgy szarik be, hogy csak az első gigabyte-ot nem tudja olvasni, minden más része tökéletesen üzemel?
Megfordítom: van egy HW RAID vezérlőd, rajta két SSD tükörben. Bármiért megsérül a partíciós tábla (mint a fenti példában, nem HW hiba, hanem mondjuk SW elrontja, HW RAID lemásolja a rosszat is). Akkor azt hogyan veszed észre? Pont ugyan úgy nem fog indulni a rendszer.
Továbbra is fenntartom, hogy monitorozással ezek nagy része kiszűrhető (ha eszedbe jut, és beteszed monitorozásba - nekem nem figyel csak SMART-ot és ZFS-t, partíciós tábla eltűnésnél így jártam).
Pl. Zabbix-al simán tudsz hash változást nézni, akár a boot szektor, partíciós tábla is lehet ennek alanya kis munkával. Akkor azt megtudod, hogy valami elrontotta-e ezeket. SMART-tal értesülsz a diszk hibákról. ZFS-sel a root pool hibáiról.
Erre jutottam én is, smart, stb, talán még érdemes lementeni a particiós táblát.
Illetve van ez , nem tudom hibánál mit csinálna:
https://blog.claryel.hu
nem bantasbol, de amit felvazoltal a topic nyitoban (miszerint mindket boot diszked kuka) az ellen sem zfs sem raid sem a proxmox-boot-tool nem segit. ha nincs meg sehol az adat, a mentest kell elovenni. :)
reboot elott szepen megnezed mit mondott legutobb a proxmox-boot-tool, vagy force-olod, hogy dolgozzek es ellenorzod esetleg efibootmgr-rel mi a stajsz boot bejegyzesek teren.
Megnézem ezentúl, de pont ezt akarnám kikerülni. HW raid kártya az egész lemezt felügyeli, azt se tudja milyen rendszer van a lemezen, blokkról blokk-ra "bután" figyel, MDRaid-nél is igy volt, ha máskor nem ellenörzéskor a teljes lemez képbe került- mint irták előttem. Most nálam van egy 1 GB-os rész, ami kiesik a képből. Nem gond, de nem szép, én leginkább távoli gépekről beszélek, ahol egy ilyen gond fokozottan kellemes.
https://blog.claryel.hu
nem ertem mirol beszelsz, ez nem egy raid. 2 EFI particio.
megegyszer, ha mindket lemezed kuka (topiknyito scenario), akkor azon semmi nem segit. hwraid sem.
ha latni akarod mi van az EFI particion, mert nem vagy biztos magadban, reboot elott megnezed, ennyi. mivel egy relevans update triggereli a proxmox-boot-tool futasat, mar az apt update soran ki fog bukni ha valami nem OK.
de ha a boot-ot egy hwraid1-en kukazod le, arrol (ahogy irod is) a raid vezerlo lofuttyt sem tud, csak szinkronban tartja a biteket, ergo akkor is ugyanott vagy: ugyanugy le kell ellenorizd egy reboot elott.
Felesleges lementeni a particiós táblát vagy a boot partíciót. Ha a boot partició száll csak el, akkor usb-ről vagy akárhonnan bebootolva chroot után proxmox-boot-tool -al helyre tudod rakni az EFI bootot, saját lemezre, másik lemezre vagy akár egy pendrive-ra is. https://pve.proxmox.com/wiki/ZFS:_Switch_Legacy-Boot_to_Proxmox_Boot_To…
vps4you.hu kupon VPS szolgáltatásra: HUP2023
Azzal raktam helyre, csak az "ép" lemez alapján particionáltam a másik lemezt (sgdisk /dev/sda -R /dev/sdb ), megcsinálta újból a zfs particiót is, igy a ZFS scrub nem jelzett hibát , ott megvolt minden, nem kellett semmit másolnia a másik lemezről.
https://blog.claryel.hu
miert jelzett volna hibat a zfs scrub ha az adat mindvegig megvolt/ott volt? :)
sgdisk -R-rel csak ovatosan, ha nem randomizalsz part uuid-kat, beszophatod, lasd: https://hosting-tutorials.co.uk/tutorials/linux/replacing-a-zfs-root-di…
utána volt -G. Ez ad új id-t.
https://blog.claryel.hu
RAID nem mentés, ez már elhangzott. Ha attól tartasz hogy a 2 boot/rendszer lemez elhalálozik miközben a két adat lemez közül legalább az egyik életben marad, akkor a mentésre kell támaszkodni. Különösebb utánajárás nélkül véleményem szerint ha /etc/pve-ről van mentésed, akkor új rendszer lemezekre felhúzhatsz egy szűz proxmoxot, hozzáadod az adat lemezt ugyanazon a néven a hoszthoz, hoszt hálózatot beállítod ugyanúgy (bridge, etc), vissza rakod a vm konfigokat a helyükre, és indíthatóak a VM-ek. 6-7 éve csináltam ilyet proxmox 4-el, gond nélkül ment. Persze ugyanez eljátszható vm konfigok nélkül is, csak akkor ugye neked kell összelegózni hogy melyik diszken mi volt és ahhogy mennyi erőforrást állíts be a vm-re.
FYI: https://pve.proxmox.com/wiki/Proxmox_Cluster_File_System_(pmxcfs)#_reco…
vps4you.hu kupon VPS szolgáltatásra: HUP2023