Fórum Root.cz
Hlavní témata => Server => Téma založeno: ZAJDAN 18. 09. 2019, 09:19:35
-
Ahoj,
měl jsem možnost vidět zálohování VMWARE snapshotů pomocí VEEAM a moc se mi líbilo, že veeam ukádal na zálohovací disk již komprimované soubory VBK. Dá se nějak dosáhnout metody takovéhoto komprivoní během transferu pomocí rsync nebo podobných nástrojů?
-
Mám výbornou zkušenost se zálohováním přes Veeam.
Úplně skvělá vlastnost je zapnout dedup-friendly kompresi a na Windows Serveru mít svazek se spuštěnou deduplikací.
Veeam pak komprimuje data tak, aby bloky odpovídaly i po zápisu a byly deduplikovatelné.
Díky tomu jste schopný mít neuvěřitelně dlouhý archiv záloh, aniž by to žralo moc místa.
-
Mám výbornou zkušenost se zálohováním přes Veeam.
.....
asi jste mne nepochopil....mím cílem je si ty zálohy ukládat přes vlastní script(pauznout virtualku, snapshot, rsync někam, smazat snapshot) a k tomuto standardu doplnit tu kompresi během transferu
-
asi jste mne nepochopil....mím cílem je si ty zálohy ukládat přes vlastní script(pauznout virtualku, snapshot, rsync někam, smazat snapshot) a k tomuto standardu doplnit tu kompresi během transferu
Aha, znovuobjevovat kolo :).
Rsync komprimuje během přenosu, ale na konci zase dekomprimuje (aby zdroj a cíl byby totožné).
Jedinou možností je hned na zdrojovém serveru spustit komprimaci a tu přenášet (patrně ne rsyncem, ale něčím jiným).
Nenapsal jste, jakou platformu na virtualizaci používáte.
Kompresi na zdrojové straně bych moc nedoporučoval, budete tím žrát moc prostředků, se kterými pak hypervizor nemůže hospodařit pro virtuálky. Proto se zapíná jen lehká přenosová komprese, aby to nebylo moc agresivní.
-
v titulku je napsáno ESXi tedy VMWARE
ano ja chci kompresi na cíl/záloze
-
v titulku je napsáno ESXi tedy VMWARE
ano ja chci kompresi na cíl/záloze
Pak to není asi úkol na rsync, ale udělejte si to přes SSH:
cat soubor | ssh cílový.sever "gzip > destination.gz"
Budete asi řešit hodně situací, než se Vám to podaří a budete riskovat, že se něco nepřenese (není nic smutnějšího, než write-only záloha).
Být Vámi nevynalézal bych už objevené, využil bych toho, co je.
-
Ahoj,
měl jsem možnost vidět zálohování VMWARE snapshotů pomocí VEEAM a moc se mi líbilo, že veeam ukádal na zálohovací disk již komprimované soubory VBK. Dá se nějak dosáhnout metody takovéhoto komprivoní během transferu pomocí rsync nebo podobných nástrojů?
Zkuste tohle, používám na několika instalacích a funguje v pohodě.
https://33hops.com/xsibackup-vmware-esxi-backup.html (https://33hops.com/xsibackup-vmware-esxi-backup.html)
Možnosti jsou tu https://33hops.com/xsibackup-indexed-resources.html (https://33hops.com/xsibackup-indexed-resources.html)
-
...
Být Vámi nevynalézal bych už objevené, využil bych toho, co je.
souhlasím s Vámi, ale říká se 'no money no love' :_)
-
souhlasím s Vámi, ale říká se 'no money no love' :_)
Což je pěkná hovadina. Pokud máte data, mají nějakou cenu. I čas ZAJDANA má cenu, a tipuji, že v tomto oboru nad průměrnou mzdou. Chyba = ztráta dat, ztráta zakázek nebo i větší průšvihy.
Je bláhové si myslet, že je levnější něco dělat od nuly. Cena produktů je nastavená právě tak, aby se vyplatila (jinak by to nikdo nekupoval).
Musíte započítat i budoucí náklady, např. že musíte svůj home made systém kontrolovat, jestli fakt funguje (v případě produktu typu Veeam nebo Acronis Vám v tom pomáhají masy dalších zákazníků a testerů). Musíte to kontrolovat po updatech. Být si jistý, že se to neskříží se snapshoty, které budete dělat ručně. Musíte mít zajištěno, že to proběhne i při přesunu do jiného úložiště (změní se uuid ve /vmfs/). Nesmíte vynechat žádný důležitý soubor a vědět, který můžete a který nesmíte (nesmíte vynechat všechny starší snapshoty, naopak musíte přeskočit ten aktuální). Musíte poslat do virtuálky Quiesce a vyhodnotit, jestli ho přijala.
Prostě spousta práce, která nikdy nemůže být levnější než hotové řešení.
Spíš si myslím, že spoustu problémů zatím jen nevidíte, abyte posoudil, že ruční výroba bude dražší.
-
chci kompresi na cíl/záloze
duplicity je tool který hledáš. Ale komprese se bude počítat už na zdroji.
..
Pokud máte data, mají nějakou cenu.
..
I čas ZAJDANA má cenu
..
Je bláhové si myslet, že je levnější něco dělat od nuly.
..
ruční výroba bude dražší
..
+1.
-
duplicity je tool který hledáš. Ale komprese se bude počítat už na zdroji.
Obávám se, že to na ESXi nedostane, nebo možná za cenu cinknutí nepodepsanou binárkou. To je trochu nedobrý nápad, pokud už si vybral VMware jako platformu. (S čímž hluboce souhlasím).
-
.....
Opět máte pravdu, ale já řeším jen tu nadstandardní komprimaci během transferu....zálohy jako takové mám, nic neohrožuji, jen jsou prostě velké.
-
Opět máte pravdu, ale já řeším jen tu nadstandardní komprimaci během transferu....zálohy jako takové mám, nic neohrožuji, jen jsou prostě velké.
Během transferu = na zdrojové straně. Tj. "zaserete" CPU hypervizoru, to není moc dobrý nápad.
Ale pokud chcete, stačí to jen otočit, co jsem psal:
gzip soubor | ssh cílový.sever "cat > destination.gz"
-
Na placeném xsibackupu používám OneDiff, dělá to backup rozdílově na úrovni bloků. Je to dost podobné jako Duplicity ale není třeba počítat rozdíly, jen je slíznout ( CBT ) a aplikovat na backup obraz. Beží to i na vmware free verzi a dělám si tím na cílovém serveru/datastoru vlastně stand by virtualku co čeká až na ní přijde čas, pak se jen zapne v DR lokalitě v případě potřeby.
Jinak stále můžete použít Veeam komunity verzi co je free do 10 virtualních strojů, jen je toho kolem třeba více.
-
Opět máte pravdu, ale já řeším jen tu nadstandardní komprimaci během transferu....zálohy jako takové mám, nic neohrožuji, jen jsou prostě velké.
Ještě mě napadá jedno daleko nejjednodušší řešení.
Ukládejte to u sebe na ZFS. Tam můžete zapnout jak kompresi, tak deduplikaci. Tím pádem budete moct klidně použít rsync (pokud Vám na ten účel vyhovuje) a o zbytek se nestarat.
-
Tahat to z vmfs filesystému nástrojí, které nejsou VMwaru rozhodně není dobrý nápad. Dá se na to vyžít třeba https://<vcenter>/folder/, kde je k dispozici všechny volumy. Popř. /mob API atd.
Jinak licence Veeamu stojí v essentials balíku nějakých 20k. To se fakt nevyplatí to řešit sám.
-
Tahat to z vmfs filesystému nástrojí, které nejsou VMwaru rozhodně není dobrý nápad.
ZAJDAN je tady takový kutil, který vždy hledá cestu tam, kde ostatní vědí, že nevede :). Ale proč ne, snaží se, neprudí, netroluje, je radost mu odpovědět.
Dá se na to vyžít třeba https://<vcenter>/folder/, kde je k dispozici všechny volumy. Popř. /mob API atd.
Opravdu přes vcenter? Pokud se nepletu, musí tam být přímo konkrétní host, vcenter to nepřeproxuje.
Jinak licence Veeamu stojí v essentials balíku nějakých 20k. To se fakt nevyplatí to řešit sám.
Mám pocit, že Acronis umí podobné kousky a je ještě lacinější.
-
Citace: chsajarsa Dnes v 14:13:58
Tahat to z vmfs filesystému nástrojí, které nejsou VMwaru rozhodně není dobrý nápad.
ZAJDAN je tady takový kutil, který vždy hledá cestu tam, kde ostatní vědí, že nevede :). Ale proč ne, snaží se, neprudí, netroluje, je radost mu odpovědět.
Nevím jak na aktuálním vmfs, ale dřive se prostě muselo na manipulaci z vmdk soubory používat vmkfstools, protože při použití třeba cp hrozil data corruption. Čtení je, ale asi v pohodě.
Opravdu přes vcenter? Pokud se nepletu, musí tam být přímo konkrétní host, vcenter to nepřeproxuje.
Podle mě tam může být i host, ale tím, že se potkávám hlavně s většími farmamy, tak se mi moc ve skriptech nechce řešit na kterém co běží hostu a třeba i případně řešit prostupy na FW.
Mám pocit, že Acronis umí podobné kousky a je ještě lacinější.
Dá se použít i třeba český vmcom, který tu práci odvede taky dobře.
-
ZAJDAN je tady takový kutil, který vždy hledá cestu tam, kde ostatní vědí, že nevede :). Ale proč ne, snaží se, neprudí, netroluje, je radost mu odpovědět.
:) díky
nehledejte ve všem Enterprise řešení....vždyť virtální prostředí má dnes již kde kdo doma. Mě ty partizánské řešení vyhovují, fungují a člověk pochopí mnoho jiných věcí, které se na to nabalují.
-
nehledejte ve všem Enterprise řešení....vždyť virtální prostředí má dnes již kde kdo doma. Mě ty partizánské řešení vyhovují, fungují a člověk pochopí mnoho jiných věcí, které se na to nabalují.
To nejsou enterprise řešení. Jste upozorňován na to, že to děláte mimo postupy dané výrobcem. VMware rozhodně nedoporučuje mít spuštěné SSH a kopírovat soubory natvrdo rsyncem. Je to dáno mnoho důvody, jeden který mluví za vše: soubor může být na storage přes iSCSI, které když se rozpadne, zablokujete si tím možná i celý hypervizor při kopírování. Když na to použitjete postupy a nástroje vmware, tak to nehrozí.
Takže si klidně zálohujte ručně, ale začněte tím, že si nastudujete, jak se má přistupovat k souborům na vmfs.
-
.....
mám jeste jinej server, kde jsem si kazdej virtual hodil na LVM a snapsotuji LVM....pouzivam jiz 2 roky bez problému, ale chci si vyzkouset i jine partyzánštiny