Dotaz: Proxmox ext4 nebo sw RAID1 s ZFS?

[Janík]

Chystám plán na ostré nasazeni Proxmox do provozu, kde sice na datech zaleží,ale pokud při havarii disku nebo serveru nebudou data x hodin přístupná dá se to přežít (system pro svou činnost tak jako tak potřebuje přístup k internetu a když nam ted překopli kabel nešlo to 2 dny)

Proxmox jako takový a základní VM budou na SSD, původně jsem planoval HW RAID1 s dvěma SSD, ale HW RAID řadič, který mám se ukazal při testech jako spíše problematický a tak jsem tuto myšlenku opustil (prosim neřešme proč, berme jako fakt, konzultoval jsme to přímo s proxmox)

Nyní řeším jak dál.

Varianta a) necht to jet na jednom SSD s ext 4 s tím, že když náhodou klekne SSD přehodím kabely na druhý SSD , obnovim data ze záloh a jede dám.

Varianta b) udělat v proxmox nad oběma disky sw RAID1 což proxmox umi jen s ZFS a provozovat to takto.

Varianta c) nechat zaple oba disky ,ale jet to jako variantu a) s tim, že čas od času vytvořím kopii toho běžícího disku na ten "záložní", to nemám moc rozmyšleno zatím o tom uvažuji jen jako o možnosti.

Fakt nevim jak se rozhodnout, vim že je to dost blbý dotaz a sám si říkám co se muže podělat to de poděla a RAID je RAID i když softwarový na druhou strnu moc nevim jak vlastně ten sw RAID1 s ZFS funguje ja jak moc věcí co se mužou podělat do systému vloží jen svou exixtencí sw RAID a ZFS a jak to změní pravděpodobnosti poruchy v porovnní s odejde SSD nebo odejde ext4 na něm?

Ano vzal jsme dva disky a cvičně si na nich vytvořil instalaci proxmox s RAID1 zfs a funguje to, jediné čeho jsem si všiml byly trochu vyšší pamětové nároky na samotný proxmox, nic drasirckxho disky jsou jen 500GB, data budou na velkych HDD a tam jsem kvuli pamětovým narokům misto ZFS dal BtrFS. jestě mohu zkusit odpojt jeden disk co to udělá ale tim tak nějak s testy skončím. Přiznámn se jak ZFS tak sw RAID jako takovy jsou pro mě spiš černé škatulky než že bych do nich viděl a mohl posoudit pro a proti

Uvítám každou radu a zkušenost , či doporučení co zvolit.

---

---

Odpovědi

[Sten]

Neznám přímo Proxmox, ale ZFS on Linux od verze 0.7 funguje spolehlivě včetně SW RAIDu. Pokud je tam starší ZoL, tak tam jsou některé okrajové případy, kdy to může padnout (např. ARC může sežrat celou paměť a vyvolat kernel panic), měly by být velmi vzácné, ale jsou.

[Karel]

V aktuální verzi Proxmox je ZFS 0.7.8-1

[dustin]

A má smysl dávat ZFS na root filesystém virtual hostitele? IMO ne, použil bych klasiku mdraid 1. Ovšem pokud to ten proxmox (neznám) neumí nějak nainstalovat...

[Sten]

Má, jelikož tam lze alokovat Qcow2 (případně zvol, ale ten má některé nepříjemné vlastnosti), které se v guestu bude tvářit jako jeden disk, ale stále to bude COW s RAIDem.

[dustin]

Předpokládal jsem, že tazatel řeší kořenový systémový filesystém pro hostitele na dvou SSD, zatímco virtuály budou mít vlastní pole (tam bych zfs samozřejmě dal).

[Peter Golis]

ZFS na SSD vyzerá ako krásny sen, ale TRIM v ZFS na Linuxe zatiaľ nie je oficiálne podporený. Bez TRIM je život na SSD ťažký. Bug, teda enhancemet request by mal byť dostupný v zdrojákoch. Ale otázkou je kedy sa dostane do nejakej verzie a aj kedy to odtial preberie v tomto prípade Proxmox.

Opravte ma niekto ak sa mýlim.

[Janík]

Tak to jste mě dostal, to že by ZFS dnes nepodporovalo TRIM mě ani nenadlo, rerspektive v nějakém slide jsem viděl, že od 0.7 Ano, nicmeně v tom vašem odkazu to vypadá až na 0,8 a kdo ví jestli. Pokud to je tak tak si mohu škrtnout i řešení SW RAID

[Peter Golis]

ZFS on Linux skutočne nemal TRIM až do tohoto roku, a distribúcie ho nebudú mať ešte dosť dlho. Ale ten postarší ZFS od fy. Nexenta čo bol myslím za peniaze to mal. Takže veľa šťastia aj s výkonom kvôli wear levellingu a iným čínskym slovíčkam ktoré opisujú to, čo je obchodníkom španielska dedina. A občas aj technikom.

[Peter Golis]

Teraz pozerám, že ten TRIM dali až do plánov pre 0.9. Asi by stálo za to poobzerať sa po inom FS ktorý zvláda deduplikáciu, kompresiu, checksumming na dáta aj s korekciou chýb a hlavne aj TRIM.

[Andrej]

Jestli jde o "dilema" Ext4 versus ZFS, pak je ZFS jasná volba. Ext4 je celkovou koncepcí souborový systém z minulého tisíciletí. Jedině souborové systémy s vestavěným RAIDem zajišťují skutečný RAID, nikoliv pouze iluzi redundance, která selže v okamžiku, kdy kterýkoliv z disků vrátí špatná data. ZFS má navíc copy-on-write, cp --reflink, atomické snapshoty (momentálně dokonce lepší než Btrfs, protože subvolumes a snapshoty žijí ve vlastní hierarchické struktuře, zcela oddělené od mount pointů a souborového systému, která určuje rozsah atomicity při snapshotování), deduplikaci, možnost vytvářet nízkoúrovňová média (zvol) pro jiné filesystémy / disky virtuálních strojů (s checksumy a redundancí a dynamickou alokací, ale bez vlastního souborového systému) atd. atp.

Jestli je volba FS zcela otevřená, Btrfs je pořád nejlepší varianta, nejen díky skromnějším paměťovým nárokům, ale taky díky licenci a integraci do Linuxu. U ZFS mám často problém s tím, že se některá verze SPL nebo ZFS nepřeloží. Takže pak člověk nemůže snadno držet krok s aktualizacemi kernelu a musí si dávat pozor, aby příslušné dkms moduly byly vždycky úspěšně přeložené a k dispozici, což se po čase stane otravným, mírně řečeno. U Btrfs žádný takový problém není.

[ewew]

Znovu propaguješ súborový systém "hoď to na kopu, system sa v tom nejako vyzná". :D

[Andrej]

Ano, mám ten zlozvyk propagovat pokročilé souborové systémy odpovídající dnešní době a velikosti dnešních disků. A nestydím se za to. :-P Pořád lepší než propagovat nápady typu "rozděl si zbytečně disk a až se někam něco nevejde, breč".

[k3dAR]

je tu jeste varinta "pouzij LVM, az se nekam neco nevejde, zvetsis za chodu" a na tom ext4, sice je tu moznost silent data corruption, kterou ale nikdo nikdy nevidel narozdil od nekolikaradove vetsi pravdepodobnosti problemu s btrfs kterej potkal minimalne kazdej druhej jeho uzivatel

[Andrej]

No, tohle už jsem řešili asi desetkrát. Já chápu, že máš rád fosilní nebo muzejní souborové systémy, ale je nesmyslné vnucovat tuhle zálibu někomu, kdo se ptá na radu, co nasadit na systémech s jiným než muzejním použitím. Železnici bys asi taky nedoporučil parní lokomotivu, vzdor veškerému respektu k nadšencům, kteří dnes udržují parní lokomotivy v provozuschopném stavu.

pouzij LVM, az se nekam neco nevejde, zvetsis za chodu

Toto měl asi být vtip, předpokládám. Stačí jen porovnat, jak náročné je zmenšení jednoho LVM oddílu s filesystémem uvnitř (nebo hned několika), zvětšení oddílu, který potřebuje víc prostoru, a případně řešení následné fragmentace … ve s rovnání s ničím. Protože přesně to vyžaduje nerozdělený disk, když chceme využít místo — nic.

silent data corruption, kterou ale nikdo nikdy nevidel

Šíříš nebezpečné bludy. Silent data corruption je zásadní problém. V podstatě každý, kdo v posledním desetiletí používal počítač, ho už někdy viděl. Někdo si uvědomil, že jde o silent data corruption, někdo ne.

narozdil od nekolikaradove vetsi pravdepodobnosti problemu s btrfs kterej potkal minimalne kazdej druhej jeho uzivatel

Další nesmyslné bludy. Prosím odkaz na konkrétní statistiku, která ukazuje, že každý druhý uživatel Btrfs zaznamenal problém. Ze kterého zdroje vycházíš? Nebo je to zase tvoje fantazie, podobně jako sračkoidní browser Palemoon, který jsi tady kdysi vehementně propagoval, výsledkům benchmarků navzdory, jsa neochvějně přesvědčen, že zabírá méně RAM?

Btrfs používám od roku 2009 (na všech strojích od roku 2010) a žádný problém nikde nevidím. Pravda, to je pouhá anekdota od jednoho člověka, ale protože ty tvrdíš cosi o každém druhém uživateli, měl bys být schopen to doložit.

Během doby, kdy jsem spokojeně používal Btrfs, jsem se musel smát, kolik lidí přišlo na Ext4 o data nebo o celý souborový systém. Incident z roku 2015 samozřejmě nebyl jedíný. Takže asi tak.

[k3dAR]

je parni lokomotiva take mainstream jako ext4? s tema fosiliema ses jen trapnej...

behem doby, kdy jsem spokojene pouzival btrfs, bych se musel smat (pokud bych byl skodolibej a/nebo namyslenej jako ty), kolik lidi prislo na Btrfs o data...
btw: v tvem "duchu"... BTRFS is obsolete, i velky Redhat s nim skoncil

[k3dAR]

edit: prislo na Btrfs o data

[vandrovnik]

Kolik disků tam tazatel bude mít? Já jen že když jsem tu kdysi zmínil, že jsem měl btrfs raid1 na dvou discích, bylo mi naznačeno, že jsem asi padlej na hlavu, že to je málo, protože co si pak má chudák moderní btrfs počít při výpadku disku...

[SpaceExplo]

Navrhnul bych trochu jine reseni:
- OS Proxmoxu (za predpokladu, ze se konfigurace Proxmoxu nemeni prilis casto) bych nainstaloval na nejaky "maly" SSD (klidne 60GB, stacit bude) a delal u nej pravidelne zalohu (treba pres snapshoty LVM) nekam ven
- z tech dvou SSD bych udelal mdraid 1 a pouzil je pro primarni (OS) disky vsech VMs

Kdyz umre SSD toho Proxmoxu - obnovis na neco jinyho ze zalohy (nebo, pokud budou ty zalohy neco jako bit-kopie, tak vymenis)
Kdyz umre jedno to SSD v tom mdraid, vyhodis vadny SSD z RAID1, vymenis fyzicky za jiny a pridas novej do RAID1 (navody jsou vsuuuude po netu a je to snad na 3 nebo 4 prikazy + cekani, nez se to zesynchronizuje)

[Janík]

Bohužel podle proxmox není mdraid v Proxmoxu podporován.

[dustin]

Co na tom potřebuješ za podporu? Raid1 také není podporován v instalátoru staršího ubuntu a není problém na něj ubuntu nainstalovat, mám to takto na řadě strojů.

Buď to uděláš rovnou při instalaci: z usb live vyrobíš partišny s raidem dopředu a při instalaci to pauzneš, nahraješ mdraid kernelí moduly, nahodíš pole a instalaci vybereš rovnou na to mdraid1 pole.

Nebo root přehodíš na mirror až v prázdném čerstvě nainstalovaném systému, což je jednodušší - např. https://www.howtoforge.com/software-raid1-grub-boot-debian-etch .

[SpaceExplo]

Oficilane podporovan byt sice nemusi, ale funguje bez problemu. Me tu bezi Proxmox nad luks-diskama a jednim mdm raid 1 na data pro VM skoro dva roky a bez problemu to zvladlo i upgrade z 4.x (tedy Debian 8) na 5.x (Debian 9)

Nezapomen, ze Proxmox je "pouze" nadstavba (dost dobra) nad Debianem. Takze ja si tu nejdriv nainstaloval Debian "minimal installation" presne tak jak jsem chtel (luks, lvm, raid) a pak jsem do toho "jen" doinstalovaval Proxmox.

[Janík]

To je také pravda, pokud to funguje není problém, myslel jsem, že s tím je nějaký problém s kompatibilitou čí co já vím, proto to "nepodporuji". Doinstloval jsem mdadm a uvidime. Na desce mám volný M2 slot a po ruce TRANSCEND MTS800 SSD M.2 2280 32GB, ale nevim zda nebude 32GB do budoucna málo, v každém případě to zkusim.

[SpaceExplo]

Na OS + Proxmox bude 32GB az az - ja tu mam 8x VM + 2x LXC a root hosta mi zabira 2,9GB
Plus teda 4GB ve /var/lib/vz, kde ma Proxmox ulozeny iso a templaty pro kontejnery.

Co se podpory tyce - jsem presvedcen, ze duvod proc to neni oficialne podporovano je, ze na to nemaji v jejich web GUI a instalatoru polozky pro "user-configurable". Ale dole pod tim je porad "normalni" Debian (jasne, maji vlastni kernel, ale nezda se, ze by z nej pro neco vyhazovali podporu), takze cokoli, co zkousne Debian, by melo slapat s tim, ze nakonec (luks, raid atd) jsou to stejne jenom device, ktery se tomu Proxmoxu nejak "ukazou".
Ja tu mam mdraid 1, nad nim luks, nad nim VG a LV a tu nakonec predhozenou VM jako device.

[pavele]

K čemu platit Proxmox?

CentOS nebo Debian + KVM.

Všechny ty další nadstavby jen zesložiťují hostitelský OS a jeho případnou obnovu.

[SpaceExplo]

Proxmox chce nasadit Janik - viz prvni veta v jeho dotazu.
Promox ma, alespon pro me osobne, velmi dobre zpracovanej web interface.
Za Proxmox neni nutne platit, zcela legalne jej lze provozovat i bez "subscription".

[dustin]

Souhlas, určitě je to kvůli gui klikátku. Dělat se v gui s podporou všech možných kombinací by byla pěkná pakárna, taky bych se s tím nechtěl psát a radši to prohlásil za "nepodporované".

[romanch]

Používám na cca 20 serverech toto řešení :

Proxmox (debian) na SD kartě, kde je root v LV. Tohle LV se LVMcachuje na část NVMe SSD, druhá část SSD slouží jako ZFS cache pro X HDD, které jsou v ZFS raiz1 (raidz2) ZFS je uložiště pro virtuály.

Občas udělám LVM snapshot a zazálohuju Proxmox (debian).

[Max]

Osobně tomu nerozumím. HP u svých DL380 dodává na board microsd slot, ale proč bych si měl ESXi, nebo jakýkoli jiný hypervisor instalovat na microsd kartu? Nevidím v tom žádnou výhodu, hypervisor je pomalejší, jeho život svěřuji blbý microsd kartě atd. Pokud mám pár serverů, raději do každého dám dva malý disky v RAID1 za pár korun, než abych riskoval pád hypervisoru, nebo nenabootování po nějakém výpadku.
Zdar Max

[dan]

pri esxi by som sa moc nebal toho usb kluca ale proxmox co com cital ich forum tak dost zapisuje na disk a aj lacne ssd moze rychlo znicit, hlavne ked je ako ha cluster

[citanus006]

ta sd karta dava smysl, ve "stredne-vetsich" nasazenich, kde je sanka a centralni management, ale jeste tam treba neni boot ze site. Admin tam naleje hotovy image strci to masiny a pak uz se o zbytek postrara automatizace.

Jinak to jde udelat uplne bez disku, proc je tam vubec cpat zejo, kdyz skoro vsichni vendori umi boot se site nebo san: )

[Janik]

Tak jsem samotný Proxmox nainstaloval na 32GB M.2 SSD, z 2xSSD udělal RAID1 md0, na které přišly VM, HDD je dalsi LVM s BtrFS. Az na par drobnosti to celkem bylo bez problému. Pak jsem dostal blby nápad upgradovat proxmox z 5.2-1 na 5.2-9 a z nějakoho důvodu ve webovém rozhrani přestal chodit noVNC v IE11 pod Win7, nepomohlo ani vyčištění cache Ctr+F5, . Pod Firefox i Chrome to funguje a java verze chodi i pod IE11.

[SpaceExplo]

"blby nápad upgradovat proxmox z 5.2-1 na 5.2-9" tohle neni blby napad, to je zcela v poradku
"IE11 pod Win7" tohle ale je blby napad protoze IE je na vuci webovym standardum, obcas, tak trochu imunni

Takze bych si tim nelamal hlavu, pokud to jede pod Firefoxem, tak je vsechno v poradku

[Karel]

Když je řeč o instalaci Proxmox na malé SSD. Proxmox standartně vytvoří jednak samotnou instalaci systému,ale ma stejném mediu i lokalní LVM thin a lokalni LVM.Jde nějak nastavit, aby při instalaci lokalni LVM nevytvářel a prostor zůstal at již instlaci nebo zvětšení local LVM thin?

No a když už rozebíráme proxmox. Při vytváření VM si lze vybrat jak typ simulovaného řadiče disku IDE, SCSi,SATA, VirtIO , to same u LAN Intel 1000, Realtek RTL8139, VirtIO a nějaky VMware. Jsou nějaké pravidla či důvody proč je lepšíé simulovat sítovku Intel než Realtek nebo disk SCSI než SATA?

A poslední dotaz , nainstlaoval jsme do prormox podporu pro UPS, tedy apcupsd. Fungovat to funguje, ale neinstloval jsem apcupsd-cgi, protože mi nepřišlo jako dobrý nápad cpát do proxmox apache. Apache mám v jedné z VM a tak se chci zeptat, je dobry nápad , respektive je vůbec realizovatelní přidat dane VM USB devic ( tu UPS) a stav UPS přes apcupsd-cgi sledovat tam. není to nic důležiteho jen nápad a nechci si komplikovat.

[MP]

Myslim, ze defaultni instalaci nejde obejit (maximalne zkusit nastavit na 0).

Emulace sitovky - vliv na performance a pri pripadne migraci na jiny host. Zkus si pouzit Intel1000 na 10G siti...

Emulace disku - vliv na ovladace v guestu a performance, drzel bych se doporucenych scsi - sata se hodi spis pro pripadne opravy windows apod, navic sata na m2/nvme discich = nonsense.

USB passthrough, funkcnost s apcupsd nutno otestovat. Kdyztak ten apache muze bezet i jako kontejner.

[romanch]

Já Instalaci proxmoxu dělám z čistého Debianu - tj. v něm si všechno udělám jak chci (LV, Swapy, root, boot apod) , pak přidám PROXMOX.

NA VM Používám VIRTIO (jak NET tak HDD) .. JAK pro Windows VM tak pro Linux VM. USBpassthrough nám funguje např. pro GSM modem.

APCUPSd bych dal jen démony na hostitele a pak management na nějaký server

[Karel]

Ja VIRTIO zkoušel , pry by díky spolupráci s reálným HW měly být rychlejší,ale min v případě LAN mi to s hw sitovkou s PCI-e RTL8111H nefungovalo, už nevim co bylo v VM, nějaký linux jadro Debian a v ovladači VIRTIO LAN sem si na VM nepingl, v full virtuialized intel 1000 vše OK. OD te doby se jim tak nějak vyhýbám.

[Nereknu]

Pro me osobně - jaký problém je s tím řadičem? celkem me to zajima

[Nereknu]

A idealne napsat, co to je za radic

[kotel]

Jedině varianta B) Vše ostatní je kompromis. Ale většinou když klekne 1 SSD, klekne rovnou i druhej, protože jim došly buňky. Zrovna mi odešly 4 ssd naráz (dva měly 8 let a zbylý dva 5 let+-), ale před vypnutím serveru jsem z nich ještě dostal data. Teď už se disky vůbec nehlásí.

[Petr]

Proč NE Proxmox

a) Už umí Proxmox inteligentně zálohovat ?
NE

b) Už umí Proxmox inkrementální zálohy ?
NE

c) Už umí Proxmox, resp. podporuje CBT pro zálohování
NE

d) Už umí Proxmox zálohovat bez nutnosti (byť krátkodobého) odstavení VM ?
NE

e) Už umí Proxmox file-level recovery (z pohledu zálohované VM)?
NE

f) Podporuje nějaká třetí společnost výše uvedené ?
NE

Závěr
Pro lacinou virtualizaci KVM/QEMU, ke které hledám klikátko z důvodu, že nechci používat virt-install nebo se učit zacházet s LXC, tak tady je Proxmox OK.
Nasazovat to do produkce, ...tak to ani náhodou....

Otázka:
Budu mít virtuální disk o kapacitě 2TB (na file-serveru je to pořád málo) a Pepa s Frantou si vzpomenou, že chtějí obnovit jeden jediný soubor, který má 200KB, ale je zásadní pro konfiguraci CNC stroje (například). Co všechno budu muset udělat abych soubor obnovil ? Kolik času to zabere ? Kolik dalšího volného místa pro to budu v případě Proxmox potřebovat ? atd. atd. atd. ....a to jsou jenom hodně krátké a stručné příklady z praxe.

Takže GoodLuck při výběru vhodného řešení, kterých bohužel moc není (VMware / Hyper-V). Každopádně, oba dva největší hráči na poli virtualizace mají své bezplatné verze, které fungují a funkcionalitu lze kdykoli (ano, za peníze) rozšířit. Zálohování jedině Veeamem. Klidně tím, který je v základu free.

[romanch]

S dovolením, celý Tvůj příspěvek shrnu do jedné věty :

pro KVM/Qemu (Proxmox) neexistuje VEEAM

Ano neexistuje ! Ano VEEAM je úžasný Software ! A pakliže se bez něj neobejdete, tak musíte použít VMware.

A taky musíte za 5 serverový cluster zacálovat "baj voko" cca 5x2x1000USD za VMware a 2000-3000USD za VEAM. (jestli jsem se spletl, tak se omlouvám, hledat přesně to nebudu)

V případě, že použijete KVM/Qemu a třeba výše uvedené ZFS, tak za 5 serverový cluster zaplatíte 0 USD (teda měli by jste si alespoň koupit subscription :)

R.

"Práci čest soudruzi IT" (tak nás zdravil ředitel :)

[romanch]

Velmi krátkozraké shrnutí. Online záloha není problém (pokud nemyslíme konzistentní), inkrement lze řešit nástrojem třetích stran (vprotect apod.). CBT jako takové nemá, ale je zde možnost využít dirty bitmap.
Každopádně to nic nemění na tom, že u spousty nasazení nic z toho není třeba.
Záloha je v dnešní době "nice to have". Většinou chce člověk HA v případě jakékoli situace. Tzn., že pokud něco padne, musí to naběhnout okamžitě v plném výkonu jinde s posledními daty, né že se mi začne obnovovat záloha pomocí třeba VM instant recovery apod.
Dále nejde mít rozumně čerstvá data v rozumný čas. Takže kdo skutečně potřebuje HA, tak to jede na aplikační úrovni a né na úrovni VM + navíc má v HA i OS jako takový. Když se mi něco posere ve VM, bude mi k prdu mít ve vzdálené lokalitě to samé se stejnými daty (což je příklad replikace VM).
Jinými slovy, myslím si, že čím je firma větší a čím je víc kladen důraz na HA, tím méně důležité jsou podobné fce na úrovni hypervisoru.

Jinak mám ESXi, máme Veeam Enterprise Plus, který spolupracuje s NetAppem, ale že by dělal konzistentní zálohy bez výpadku VM se říci nedá. Některé VM se při vytváření konzistentního snapshotu znedostupní i na minutu. Je to dáno rychlostí storage a velikostí VM (+ram).
Zdar Max
PS: od kdy je hyper-v zdarma? Jsem myslel, že k běhu potřebuje Windows (nejlépe server, který je dnes navíc licencován per core)

[Petr]

Každej tady povídá o zálohování Proxmox, o snapshotech LVM, BTRFS nebo ZFS ale zatím tady nikdo neukázal reálný příklad zálohy a obnovy. Strýček Google taky mlčí a když náhodou, tak najde něco ve slova smyslu "Mělo by to fungovat". Jinak vProtect neumí a nikdy neuměl inkrementální zálohy ani file-level recovery pro Proxmox. Zálohování a obnovy jsou pro mě klíčovým faktorem. Takže ano, stále zbývá pouze VMware, který určuje směr :) ...případně Hyper-V, ale tady jsou problémem ty Windows :D

[Jendа]

Každej tady povídá o zálohování Proxmox, o snapshotech LVM, BTRFS nebo ZFS ale zatím tady nikdo neukázal reálný příklad zálohy a obnovy. [...] Takže ano, stále zbývá pouze VMware, který určuje směr :)

Já teda Proxmox nepoužívám, ale moje řešení by mělo fungovat na libovolném virtualizačním řešení které umí snapshoty. Udělám snapshot (v mém případě LVM), namountuju ho, rsyncnu na btrfs na jiném stroji a udělám btrfs snapshot. Uvedená obnova souboru ve verzi před měsícem pak funguje tak že zkopíruju /mnt/backup/snapshots/snap2019-08-01/hostname/home/pepa/cnc.conf a je obnoveno.

[Petr]

To je to o čem mluvím ...."ale moje řešení by mělo fungovat"

[/dev/urandom]

Ono sa to zálohovanie - deti moje osprostené - robí trošku ináč. V prvom rade je nutné rozhodnúť ktoré data je vôbec potrebné zálohovať intenzívne a ktoré zriedka a ktoré vôbec (zálohujete /tmp adresár denne?). VM guesty podľa mňa patria k datám ktoré stačí zálohovať napr. denne. Zdieľaný adresár DOCS či PROJECTS v ktorom majú ľudia Office/LibreOffice agendu a neustále ju menia je treba zálohovať každú hodinu, popr. aj častejšie. Takže rad denne spravím cez /etc/cron.daily/snapshot_vm ktorý mi z BTRFS snapshotuje @/mnt/vm kde mám uložené virtuálne stroje (windowsácke vmstroje majú zakúpený Acronis a vyexportuvaju sa denne do vzdialeného storage servera). Ale cez SAMBU zdieľané DOCS a PROJECTS (na ktorých súčasne pracuje asi 50-100 ľudí) FULL karuselovo zálohujem každú hodinu (24 x cca 25GB sa každu hodinu prepisuje) cez TAR + parallel ZSTD + každý deň (30-31 x cca 25GB) + každý mesiac (12 x 25GB) + každý rok (1 x objem dát za daný rok (momentálne viem ísť dozadu cca 6 rokov)). Takže ak niekto za mnou príde že potrebuje z minulého týždňa stav projektu XXX a z minulého mesiaca zmluvu tu a tu - vždy ju v zálohách nájdem. Dokonca aj z minulých rokov už bola žiadosť o obnovu a normálne to prebehlo. Takže priorita zálohovania je základ. Ďalej dáta SQL databáz a SMS brány (cca 4-7GB) taktiež zálohujem karuselovo (24x hodiny, 7x dni, 4 x tyzdne, 12 x mesiace). No nič, som sa rozpísal, hádam som niekoho inšpiroval.

[Jendа]

Ale já to provozuji a funguje (dva servery, jeden samotné Qemu + KVM, druhý Qemu + KVM + libvirt). by mělo fungovat tam je napsané kvůli tomu že na libovolném virtualizačním řešení které umí snapshoty.

[Max]

Jinými slovy, ty nehledáš řešení, jen chceš plivat. A celé se to snažíš obhajovat tím, že tě nikdo nevezme za ručičku a neukáže ti step2step howto na youtube a ještě asi v češtině, že? S takovým přístupem je pro tebe opravdu nejlepší to, co sám chceš, protože nic dalšího ti nikdy nebude dost dobrý.
Jinak opravdu netuším, čemu nerozumíš za snapshotech na úrovni storage a jejich obnově. To je stejné snad pro všechny virtualizační řešení. Podobně je to s LVM.
Zdar Max

[L!80r]

Prostě nevěří ničemu co se nedá naklikat a nestojí to stovky tisíc

[/dev/win]

...a hlavne to FUNGUJE

[Peter Golis]

Niekedy je potrebné použiť predražené enterprise riešenie. Hlavne ak korporácia chce zľavu z poistky u zaisťovňe. Ale tá poistka je obvykle oveľa drahšia ako technológie a riešenia ktoré sú použité na zníženie tej poistký.

Nuž, ale to je obvykle mimo sféry ktorá sa v tejto diskusii opisovala skoro rok.

[j]

Ehm lol .. tak specielne vmware zalohovat neumi vubec. Veeam pochopitelne taky.

A proc? Mno protoze ta "zaloha" ma klidne desitky GB pri realite desitek MB zmen. Za tohle muze vmware, protoze velikost bloku je 1MB. Veeam pak specielne doslova znici M$ SQL. To pokud se nekdo pokusi delat konzistentni zalohy. Beznou veci sou pak errorlogy pres vse co se kde zalohuje na tema "neocekavane odpojeni disku". Dalsi krasna vec je, ze si na virtualu napises neco do notes, a veeam ti to prepise.

Ale uplne neuzasnejsi vec na zalohovani veeamem je ta, ze abys vubec byl schopen cokoli odzalohovat, musi tvuj zalohovaci HW mit nejmin stejnej vykon jako provozni. Jinak budes na merge jediny zalohy cekat tyden. A pres hromadu plku na webu, deduplikaci to vubec neumi, spoleha se to na widlodeduplikaci na fs kam se zalohuje, coz je krasny specielne proto, ze widle deduplikovat neumi taky - respektive je to nejlepsi zpusob jak rychle a efektivne prijit o data, protoze widle misto do FS ukladaji do databaze, ktera se 100% jistotou driv nebo pozdejs chcipne.

Chces vedet jak se zalohuje pomoci btrfs? Uplne primitivne ... udela se snap, pak dalsi a jeste dalsi ... ty snapy klidne muzes ve widlich videt ve vlastnostech souboru/folderu, takze pokud potrebujes starsi verzi souboru, muze si ji kazdej jeden user vytahnout sam. Na zalohovaci HW se pak prenasi ... desitky MB. Prave ty snapy. Vzhledem k jejich velikosti neni problem mit historii i nekolik let klidne po hodine.

[Heron]

Asi tak. Psal jsem o tom už před 7 lety (ten čas letí).

Veeam prostě nefunguje. Jediné, na co jsou nižší edice veeamu dobré, je prodat vám vyšší edici. Nebo novou verzi. Krom věcí v odkazovaném článku (který se zabývá trochu něčím jiným) je to třeba nefunkční CBT. Veeam měl v minulosti chybu, kdy při použití CBT někdy byla záloha nekonzistentní. Řešení jste měli v zásadě dvě. Buď dělat neustálé fullky (tj pořídit si xPB zálohovací prostor), nebo přejít na novou verzi. Veeam tehdy prohlásil, že ve stávající verzi to opravovat prostě nebude, přestože její životnost nevypršela a vy jste měli podporu předplacenou na rok dopředu. Totéž funguje s vmware. Chcete, aby vám to fungovalo? Pořiďte si vyšší verzi a zaplaťte si další featury.

Přechod a setrvání na vmware a veeamu považuju za jednu z největších chyb, které naše vedení kdy udělalo. Kdyby se vzala jen polovina nebo i třetina peněz, co se zbytečně utratila za licence (nejen základní, ale i podpůrné jako třeba licence na widle, na kterým musí běžet veeam a jeho proxy) a vrazila se do HW a postavilo se to na kvm, lvm, zálohovací řešení potom na btrfs nebo zfs (nebo obojím pro dvě zálohy), bylo by to mnohem funkčnější.

[MP]

A kdo to postavi? A kdo to bude spravovat? A kdo to bude spravovat pote? Kdo udela dokumentaci?

Postavit nejaky typ zalohovaciho systemu umi kazdy. Ale aby to fungovalo v rozsahlejsim prostredi a aby to umeli ovladat admini, to je vec druha.

[Heron]

A kdo to postavi? A kdo to bude spravovat? A kdo to bude spravovat pote? Kdo udela dokumentaci?

No ... admini?

Ale aby to fungovalo v rozsahlejsim prostredi a aby to umeli ovladat admini, to je vec druha.

Ti admini, kteří si to postaví to snad budou umět ovládat. Během stavby si napíšou dokumentaci a budou postupně zaškolovat nové kolegy. Prostě normální běh věcí. Nějak moc nechápu, kam ta otázka mířila.

[Käyttäjä 11133]

No ... admini?

Oddeleni architektury, engineeringu a operations ti nic nerika?

[Heron]

Ve firme o velikosti do 50 lidi ne A i tohle je na me prilis velke. 16 bylo tak akorat.

[Käyttäjä 11133]

Ne kazda firma ma do 50 lidi, firmy do 50 lidi si vetsinou objednavaji jine firmy na dorucovani IT sluzeb, pokud se nejedna o firmy, jez se specializuji na IT.

[Heron]

Nepovídej.

A jak to souvisí s tématem? Jako že ne IT firma si objedná vmware cluster a bude tam dělat co přesně, když to není IT firma? Asi těžko si bude spravovat vlastní vmka a pokud ano, tak tam budou mít admina schopného si celé to řešení spravovat sám. A jak se to liší od případu, kdy tam místo vmware bude kvm? Buď to budou umět nebo to umět nebudou.

Ano, někteří se snaží o mezistupeň, kdy mají vlastí řešení od někoho, do toho si dloubou sami protože chtějí ušetřit na adminovi a když to pokazí, tak potom volají někoho jako mě ať jim to laskavě opraví. A potom se strašně diví, když jim přijde faktura.

[Käyttäjä 11133]

Jako že ne IT firma si objedná vmware cluster a bude tam dělat co přesně, když to není IT firma?

Ne-IT firma si na to objedna dodavatele, uzavre s nim nejkakou servisni smlouvu a ten dodavatel pravdepodobne bude chtit tu servisni smlouvu podeprit servisnimi smlouvami se svymi sub-dodavateli.

[Käyttäjä 11133]

Rika se tomu princip IT governance.

[Heron]

Tohle je nějaká soutěž o titul Mr. Obvious?

[j]

I kdyz si firma plati extreni IT support, tak ten IT support ma kupodivu prevazne ve smlouve, ze musi zajistit zalohovani a kdo jinej to asi tak bude delat, nez ti ... externi admini. Takova firma pak rozhodne nebude moc ochotna vynalozit statisice, spis miliony, na HW a SW jen kvuli zalohovani.

Jo, uz sem potkal par firem, kde na prvni schuzce chteli naprosto 100% garance provozu 24/7 a reakcni doby "do minuty". Tak sem jim sdelil nejakou pekne vypecenou 8mi mistnou sumu a preslo je to. Nakonec z toho (pres ty penize) prakticky vzdy vyleze, ze vlastne den, nebo dva vypadku nejsou zas takovej problem.

A pro zajimavost, uz sem par zalohovacich systemu za miliony (jen SW) mel tu pochybnou cest videt v provozu. Vzdycky to melo nejakou vazne peknou ficuru, ale vzdycky to melo nejakou naprosto zasadne pruserovou nefunkcnost. Ono trebas kdyz chce nekdo obnovit backup, a ten zalohovac mu da 10MB/s (to kdyz ma zrovna kliku) pri cteni, tak to vazne moc kull neni. V tomhle pripade jen licence na SW 1M2 (+ pochopitelne 20% rocne).

Proto tvrdim, ze nejlepsi zalohovani je blbej script, o kterym admin vi co a proc presne dela.

Ostatne, to co dela veeam (zavola si snap pres API) se da scriptem udelat taky. A narozdil od veeamu to i bude fungovat. A dokonce se kvuli tomu nepotrebuju pripojovat na RPC toho virtualu, coz je jedna z veci, ktery veeam chce. Kupodivu zavolat vss si umej vmtools tak nejak samy i bez toho, kdyz uz delam ten "konzistentni" snap.

[Max]

Na obranu veeamu lze říci, že má ještě přímou podporu různých storage a třeba v případě NetAppu umožňuje toto :

• vytvořit konzistentní storage snapshot (=před vytvořením zavolá vmware, aby byly VM v konzistentním stavu) na primárním storage
• zavolá sync se záložním storage
• provede konzistentní zálohu VM ze záložního storage

Problém je, že je to naprosto nepoužitelné, aspoň tedy v našem prostředí.

Dále umí Instant Recovery (spustí VM přímo ze zálohy a postupně jí přesunuje na hlavní storage), ale normálně také není problém spustit VM z namapovaného backup storage a spustit storage motion na primár. Prostě nic, co by u vlastního prostředí také nešlo.

Ale co je asi hodně použitelné je automatické testování a reportování ohledně záloh. Je možné nastavit, aby si zálohu obnovil do testovacího prostředí, spustil VM a provedl nad ní sadu vlastních testů, zda systém naběhl, služby běží, web odpovídá atd. a následně zaslal report adminovi. Tj. automatické testování funkčnosti záloh.

Další dobrá fce je web face s ACL, kdy si třeba vývojáři mohou sami obnovovat zálohy pro své VM, na které mají právo, nebo pokud je firma hodně velká, může se řídit přístup jednotlivých částí IT k jednotlivým systémům / VM.

A nakonec file level recovery, který lze aplikovat i na maily v Exchange atd. Reál je takový, že to vypadá jako dobrá fce, ale pokud firmě záleží na emailech, má nějaký emailový archivační systém, takže obnova ze zálohy je zbytečná. Podobně jako u obnovy jednotlivých souborů. Fce je to pěkná, ale reálně stejně myslím obnoví celou VM a vykopíruje z ní soubory, takže nic, co by člověk nemohl udělat ručně sám.

Shrnuto a podtrženo, Veeam má spoustu pěkných fcí, které jsou ale v reálu buď nepoužitelné, nebo zbytečné (nikdy je nikdo nevyužije).
Zdar Max

[Käyttäjä 11133]

A nakonec file level recovery, který lze aplikovat i na maily v Exchange atd. Reál je takový, že to vypadá jako dobrá fce, ale pokud firmě záleží na emailech, má nějaký emailový archivační systém, takže obnova ze zálohy je zbytečná.

NetApp SnapManager for Exchange tohle taky umi.

[Käyttäjä 11133]

o, uz sem potkal par firem, kde na prvni schuzce chteli naprosto 100% garance provozu 24/7 a reakcni doby "do minuty". Tak sem jim sdelil nejakou pekne vypecenou 8mi mistnou sumu a preslo je to.

No vidis a ja znam alespon jednu firmu, ktere na tu sumu za tohle SLA kyvla, nejen pro "time to react" ale dokonce i na 5 minutovy "time to resolve".

[Max]

5 min time to resolve? Nechápu. Možná nějaká burza, za kterou sedí team lidí, zná dokonale systém a toto zaručuje, nevím.
Zdar Max

[Käyttäjä 11133]

Na tema toho jak bylo SLA plneno se fakt vyjadrovat nebudu; dodam pouze toliko, ze se vskutku jednalo o financni instituci.

[MP]

Super. Takze admini napisou spolehlive skripty, osetri vsechny problemove stavy, napisou srozumitelnou dokumentaci, postaraji se o vhodny zpusob monitoringu takoveho zalohovani, zaridi, ze to bude dostatecne odolne ...A kdyz prejdou do jine firmy, tak se budou muset ucit uplne novy zpusob zalohovani, snazit se porozumet tem skriptum...

A budou ti admini delat taky neco jineho?

Nemaji si taky napsat vlastni ovladani kvm, zdokumentovat...

Interni bastly jsou vetsinou to nejhorsi, co adminy muze potkat.

[Käyttäjä 11133]

A kdyz prejdou do jine firmy, tak se budou muset ucit uplne novy zpusob zalohovani, snazit se porozumet tem skriptum...

Tihle bastliri vetsinou do jinych firem neprechazeji, protoze maji docela dobrou paku na ten korporat kde to ubastlili.

[Max]

To je omyl. To nesouvisí s vlastní tvorbou, ale s tím, zda existuje dobrá dokumentace a pravidelné seznamování teamu s novinkami, nebo nikoli.
K proprietárním technologiím také musí existovat interní dokumentace, která bude popisovat aktuální nasazení, nastavení, zálohování a best practices. Když budu mít ve firmě x proprietárních app bez jediné dokumentace, tak nový člověk i sebemenší problém bude řešit šíleně dlouho.
Zdar Max

[Heron]

A budou ti admini delat taky neco jineho?

Pardon, ale jestli cokoliv z výše uvedeného někomu zabírá 100% času, tak je chyba spíše u něj. Popsal jste stav, který žiju už nějakých 13 let a výše uvedená činnost je zlomkem toho, co se dělalo.

Při pohovorech považuju znalost lvm na cli úrovni za základ, o kterém se ani nebudu bavit. Totéž bych dnes čekal i o zfs a btrfs, ale to se kdokoliv schopný naučí rychle. Co je těžkého na tom napsat skript, který provede snaphot a kopii dat?

Z mých zkušeností plyne, že je mnohem těžší dostat molochy typu veeam do funkčního stavu a stojí to násobně více času, než si to na své infra napsal od nuly. A pokud chce někdo argumentovat tím "to přece udělá dodavatel veeamu" tak si vemte jeho cenu a převeďte to na interní člověkohodiny. Ještě jsem nezažil případ, kdy byl externí dodavatel levnější. Bavím se o triviálních případech, takže mi nepište, jestli si jádro taky píšeme sami. Zálohování není raketová chirurgie.

[MP]

Tak mate skript, co syncuje data.

Kde mate retention policy? Kde mate recovery? Umi to ext4? Umi to xfs? Umi to pasky? Umi to S3? Umi to sifrovani? Atd...

Vlastne rikate, ze kazdy admin ma znovuvynalezat kolo pri nasazeni backup systemu.

[Heron]

Kde mate retention policy? Kde mate recovery? Umi to ext4? Umi to xfs? Umi to pasky? Umi to S3? Umi to sifrovani? Atd...

Smazat staré soubory na základě několika pravidel není problém. Nahrát na LV zpět data je stejná operace jako je nahrát jinam (cat soubor > /dev/vg/lv). Totéž btrfs / zfs receive. O šifrování se může postarat komprimátor nebo gpg. Upload na různé služby totéž.

Vlastne rikate, ze kazdy admin ma znovuvynalezat kolo pri nasazeni backup systemu.

Já vlastně jen říkám, že čas věnovaný na nasazení molochů je větší než čas strávený na to napsat si to sám. Je to taky otázka, zda investovat do vlastního know how nebo do know how někoho, kdo při nejbližší příležitosti provede vendor lock-in. Pokud se někdo naučí lvm, zfs, btrfs na cli (což jako admin stejně potřebuje), může tuto znalost použít kdekoliv jinde. Pokud se někdo naučí proprietární program, bude si muset na jiné místě opět koupit licence.

A pokud má někdo pocit, že vynalézá kolo, tak může nasadit bacula / bareos, backuppc apod.

[Käyttäjä 11133]

tak může nasadit bacula

No jako, nevim jak je na tom to reseni dneska, ale cca 8 let zpatky jsme o tom na jednom projektu uvazovali; kontaktoval jsem Anicku ze SUSE a ta mi to celkem silne jako maintainer tech balicku rozmlouvala...

[Heron]

Já to nasazoval před nedávnem a přišlo mi to mnohem jednodušší, než všechny ty hororové články popisovaly. Možná novější verze. Člověk trochu musí pochopit architekturu a co a kam se chce připojovat, ale potom přidávat další klienty byla hračka.

[Käyttäjä 11133]

Ok, dobre vedet! :).

[KOLEGA]

my baculu pouzivame a jsme celkem spokojeni, neni to tak desivy, jak to podle vseho vypada a dokumentace je pekne retro!

Nemyslim si, ze jsem nejakej zalohovaci guru, ale uz se bacula nekolikrat osvedcila ...

[Käyttäjä 11133]

+1.

[dustin]

Uplne primitivne ... udela se snap, pak dalsi a jeste dalsi ... ty snapy klidne muzes ve widlich videt ve vlastnostech souboru/folderu, takze pokud potrebujes starsi verzi souboru, muze si ji kazdej jeden user vytahnout sam.

Nesleduju to - jedná se o nativní brtfs pro windows?

[Heron]

Možná to myslel tak, že user může mít přes sambu připojen zálohovací stroj (třeba jen read only) a tam uvidí všechny svoje zálohy. snapshot je obyčejná subvolume a subvolume z hlediska userspace je totéž co adresář, takže s tím není žádný problém.

[dustin]

Mě překvapuje ten přístup k snapshotům přes vlastnosti souboru - to lze přes sambu zařídit? Nedovedu si to nějak technicky představit...

[Max]

To je naprosto běžné. Můžeš tak zpřístupnit i ZFS snapshoty.
Windows mají VSS (Windows Shadow Copy), takže vlastnosti nad souborem/složkou už tam mají pro toto option : "Předchozí verze". K těmto vlastnostem umožňují win přistupovat i vzdáleně přes smb protokol. No a samba umožňuje exportovat snapshoty z btrfs i zfs podobně jako VSS.
Zdar Max

[Max]

Resp. nechci teď mlžit, se ZFS to možné je, u btrfs teď nevím, ale možná už také.
Zdar Max

[Max]

Gentoo wiki jako příklad : Samba shadow copies
Zdar Max

[someone who cares]

Tvoja paticka, aky si mal sen Max?

[j]

Nevim jak se ZFS, na btrfs to funguje v pohode. Uz opravili to, ze snap nesnapoval xattr? To byl totiz jeden z pomerne zasadnich problemu, kvuli kterymu to prave na zfs udelat neslo.

[dustin]

Díky za objasnění.

[Heron]

Jo takhle. A jak moc je to ve windows světě používané? Já vím, že to previous versions má, ale vždy jsem to vypustil z hlavy a přistupovat ke snaphotům jako k adresářům. Je to nějak víc integrované do systému / umí s tím programy pracovat?

[Max]

Tak VSS se používá na zálohy všeho možného včetně Exchange. Jinak práci s VSS z uživatelského hlediska se používá u file serverů. My děláme třeba každé dvě hodiny VSS, takže když něco někdo zkazí na FS (excel, omylem si smázne nějaké pdf, foto apod.), tak mu můžeme (nebo i on sám) obnovit předchozí verzi maximálně 2h starou. Samozřejmě VSS není jako snapshoty u btrfs. VSS má by default limit asi 64 snapshotů, jde to myslím zvýšit, ale moc doporučováno to není. BTRFS je v tomto lepší, tisíce snapshotů bez performance impactu atd.
To ale nemění nic na tom, že je to dobrá fce, kterou je vhodné používat. Jinak vím, že u nějakého win10 buildu to dělalo zmršené VSS a obnovené dokumenty nebyly čitelné. To je myslím opraveno.
Jinak pokud uživatel nepracuje pod admin účtem, je tento způsob i dobrá ochrana proti cryptoware červům.
Zdar Max