quiesced snapshot fails

erdekelne, hogy ki milyen eszkozokkel es modszerekkel keszit *konzisztens*, image alapu backup-ot VMware 6U2+ VM-eken !futo! SLES12SP1/SP2-rol (OS up-to date, a sikeresseg workloadtol fuggetlen), hogy az nem crash-el el kozben FIFREEZE/FITHAW ioctl hiba miatt random minden 2. ejszaka... enableSyncDriver=false-ban egyelore nem bizunk, mivel meg senki nem adta pecsetes papiron, hogy az igy keszult mentes konzisztens. Mivel? - Symantec NetBackup, IBM TSM, Veeam Backup. Ha persze valaki lobogtat pecsetes szagertoi velemenyt, azzal szivesen konzultalnek privat. TY. EOT

UPDATE: SLES11 SP4 és SLES12 SPx-eken, ahol open-vm-tools van és kernel >= 3.0, ott a /etc/vmware-tools/tools.conf-ba be kell rakni ezt:

[vmbackup]
enableSyncDriver=false

Majd egy vmware-tools restart.

Az ok, hogy régen, amikor még nem volt teljes FIFREEZE/FITHAW ioctl implementáció a kernelben, akkor a vmware készített egy "saját" megoldást. Ha a fenti beállítással nem kapcsoljuk ki a vmsync driver-t, akkor összeakad a két irányból jövő FREEZE és ott marad fagyott állapotban az összes FS.

tobbek kozott emiatt is tartunk az elozotol (OS uzemelteto mernokokkent.). Gondolom a "Van bevalt modszered az utobbira?" kerdesre nincs univerzalis valasz. (a valasz trivialis, nyilvan.) Viszont erdekelne, hogy egy DR tervhez ki es milyen megoldast tartana elfogadhatonak pl. egy 2+1 node-os [A +1 a quorom node, stand-by modban + 3 fuggetlen NIC-rol es VLAN-bol jovo 3db iSCSI SBD disk] (node-ok ugy meretezve, hogy mindket kornyezetet kiszolgalja akar 1 node is) aktiv-aktiv SAP pacemaker cluster (2xDB2, 2xCS, 2xERS, 2xMaster/Slave RG) es 4-6 AS (1-1 primary + 1-1 secondary + 1-1 3. AS) kornyezet helyreallitasahoz...

--
A gyors gondolat többet ér, mint a gyors mozdulat.

Storage oldali snapshot? Az is crash consistent, viszont az osszes LUNt _egyszerre_ lehet snapshotolni.
Tudtommal ESXi nem kepes tobb VM-et pontosan egyidoben snapshotolni, igy az ilyen sokVMes rendszereket nem biztos hogy lehet jol backupolni VM oldalrol.

Egyebkent az nem lehet, hogy vmi SLES bug van a hatterben? RHEL eseteben nem tapasztalunk ilyen jellegu hibat.

Szerintem az se tekinthető teljesen konzisztensnek, mert a kliens oldal memóriájában ugyan úgy lehet még ki nem írt (syncelt) adat ami így nem jelenik meg storage oldalt. Ezért is van az, hogy a teljesen konzisztens esethez mindenképp kell az, hogy a kliens is tudjon arról, hogy most backupot kell csinálni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem is irtam azt, hogy teljesen konzisztens lesz a mentes, hanem crash consistent, ami egy idobeli pillanatnyi allapota a kiirt adatoknak. Az OS es a filerendszer felelossege, hogy a journaling alapjan egy crash consistent allapotbol recoveryzni tudja magat es folytatni a mukodest.

crash consistent != "minden irt adat ki van irva" fele konzisztens != applikacio konzisztens (csak lezart tranzakciok vannak, stb.)

Teljesen konzisztens mentest ugy szoktunk, hogy mindenki befejezi a maga kis tranzakciojat, usereket kizarjuk ertelmes idovel leallas elott. Mindennel *szabalyosan* leallunk, VM shutdown es snapshot.

Valoban, az en - eredeti - kerdesem teljesen felreertheto volt.
Amire celoztam, az a napi, standalone VM-ek snapshot-olasa volt. Sajnos, jelenleg ez sem megy, mert kb. minden 2. backup eredmenye egy kernel crash reboot-tal vagy egy kezi VM reset.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( Huncraft v | 2017. 06. 07., sze – 09:38 )

Nem tudom mennyire elfogadható megoldás, de ötletnek talán jó: sync után snapper-rel készített snapshot-ról image backup külsős tárolóra / hálózati meghajtóra?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Rossz tapasztalatok (mas helyen elszenvedett, helyreallithatatlan adatvesztes miatt) a Btrfs-t nem preferaljuk, sot egyenesen tiltjuk eles uzemi hasznalatban. (Kirendelt, Novell-es support mernokunk is csak szidta, mint a bokrot eleddig... :F)

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( AiRLAC v | 2017. 06. 08., cs – 09:16 )

NetApp VSC-vel volume alapú snapshot :)

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."