LVM - manipulace se svazky

[ZAJDAN]

a me zase pripada, ze vubec nechapete pointu:
ten backup server ma ciste disky, jen predvytvorene LMVka (prazdné kontajnery)
pokud na nej rsyncuju jen samotnej snapshot zdrojoveho LVM, tak logicky i laik jako ja si domysli, ze to fungovat nebude
vzdyt ten snapshot se odkazuje na matricni data a to je to proc chci pouzit k inicializaci dd
dd udelam pouze jednou a pak uz bych jen rsyncoval snapshoty

[Reklama]

[Lol Phirae]

Kterou část z toho, že dd je absolutně nevhodné na zálohu běžícího systému, jsi přesně nepochopil? To to na několik dní odstavíš? A pokud ano, tak proč tu zálohu kurva neuděláš správně místo toho dd rovnou? Jseš fakt úplně blbej?

[ByCzech]

Kterou část z toho, že dd je absolutně nevhodné na zálohu běžícího systému, jsi přesně nepochopil? To to na několik dní odstavíš? A pokud ano, tak proč tu zálohu kurva neuděláš správně místo toho dd rovnou? Jseš fakt úplně blbej?

No neříkal jsem to?

tak je nejspíš jen úplně blbej a je to takový ten případ, kdy chce slyšet jen potvrzení svého debilního řešení, které jsi vymyslel a bude se snažit věci kroutit, aby měl možnost si zdůvodnit, že je důvod ho použít i když nám je jasné, že není

Pořád hledá ten pravý důvod svého jednání.

[ZAJDAN]

vzdálené LVM je prázdné
na zdrojovém LVM udělám snapshot -> ten rsyncnu na vzdálené LVM (jak popisujete)
ten snapshot má třeba 1GB z referenčních 100GB(celé LVM)

z čeho na vzdáleném LVM ten 1GB snapshot veme referenční data....toto mi nejde do hlavy

díky za objasnění

[JardaP .]

@ByCzech,  Lol Phirae: Nedelejte si pulky a radsi vymyslete, jak by se ten dd prece jen na neco dal pouzit!

@ZAJDAN: Mohl byste upresnit, co presne chcete rsyncovat? Protoze pokud hodlate rsyncovat zdrojova data proti cilovym datum, tak nevim, v cem by mel byt zakopany pes.

[Reklama]

[Lol Phirae]

@ByCzech,  Lol Phirae: Nedelejte si pulky a radsi vymyslete, jak by se ten dd prece jen na neco dal pouzit!

S výhodou to lze použít na transparentní velmi účinnou kompresi dat, např.

Kód: [Vybrat]

dd if=/dev/zero of=/dev/sda bs=4096
Tím se pak následné zálohování velmi zrychlí!

[abc123]

ja som OPovi povodne radil aby pouzil uz nejake existujuce riesenie to ci to na pozadi robi transport blokoveho zariadenia alebo rsyncuje subory po jednom je v principe jedno a urcite to bude konfigurovatelna moznost, je rozdiel backupovat home (co ked mame raw volumy naformatovane bez FS? kopec hypervizorov si tak odklada obrazy virtualiek do poolu priamo na raw device a nie do suboru na FS).
Neviem preco vam je DD proti srsti, ked ZFS/BTRFs cez prikaz send a recieve robia to iste. Tiez prenasaju bitovu kopiu blokoveho zariadenia cez ssh, Len si treba dat pozor aby to bolo spravene spravne. Ale to maju existujuce backup tooly uz otestovane komunitou predsa.

[Lol Phirae]

Neviem preco vam je DD proti srsti

To už tady celý den vysvětlujeme, jsem rád, že se našel další blbec, co to ještě nepochopil.

ked ZFS/BTRFs cez prikaz send a recieve robia to iste. ... Len si treba dat pozor aby to bolo spravene spravne.

Ne, nerobí to isté. Nejdřív se vytvoří snapshot, a ten se pak odešle, čímž se zajistí konsistentnost dat.  Celou dobu tady o tom mluvíme! Kristova noho!!!

[ByCzech]

@ByCzech,  Lol Phirae: Nedelejte si pulky a radsi vymyslete, jak by se ten dd prece jen na neco dal pouzit!

No to už mě napadlo prve, že by na zdrojovém serveru mohl pustit dd if=/dev/null of=lvm a tím by se mu vyhovělo a problém, který má by už taky nebyl. Sice by si otevřel nové vlákno na to co s prázdným lvm, ale tohle by se mohlo uzavřít

[ByCzech]

@ByCzech,  Lol Phirae: Nedelejte si pulky a radsi vymyslete, jak by se ten dd prece jen na neco dal pouzit!

S výhodou to lze použít na transparentní velmi účinnou kompresi dat, např.

Kód: [Vybrat]

dd if=/dev/zero of=/dev/sda bs=4096
Tím se pak následné zálohování velmi zrychlí!

LOL, jsem si nevšim, žes mě předběh a poslal jsem něco takového taky

[ByCzech]

a me zase pripada, ze vubec nechapete pointu:
ten backup server ma ciste disky, jen predvytvorene LMVka (prazdné kontajnery)
pokud na nej rsyncuju jen samotnej snapshot zdrojoveho LVM, tak logicky i laik jako ja si domysli, ze to fungovat nebude
vzdyt ten snapshot se odkazuje na matricni data a to je to proc chci pouzit k inicializaci dd
dd udelam pouze jednou a pak uz bych jen rsyncoval snapshoty

Hele proč chceš radu, když už ses dávno rozhodl, že to tak chceš udělat? Tak to udělej, spal si prsty a neptej se

[Tuxik]

To chce klid... postupně... dd se dá použít k vytvoření "počátečního stavu", ale je to zbytečné, bude se přenášet i prázdné místo... počáteční stav se dá stejně dobře vytvořit i tím rsyncem a to úplně stejným příkazem, jak pozdější synchronizace. Není na tom co vymýšlet. Ještě upozorňuji, že v rámci zachování konzistence na všech úrovních je třeba zastavit aplikace, databáze atd, vytvořit snapshot, spustit aplikace a to ostatní a snapshot tím pádem bude obsahovat konzistentní data (pokud toto není ošetřeno jinak na aplikační úrovni).

[JardaP .]

Jestlipak v Linuxu nejak umime zrcadleni serveru, jako umel NetWare SFT-III? To by se zde docela hodilo.

To chce klid... postupně... dd se dá použít k vytvoření "počátečního stavu", ale je to zbytečné, bude se přenášet i prázdné místo...

Jsi si tim jisty? Vzhledem k tomu, ze ten stroj zretelne nemuze vypnout/premontvat disky RO, tak si predstavuju, jak pomoci dd na cilovem stroji vytvorim leda tak nabourany FS s nekonzistentnimi daty. Ten FS budu muset napred opravit a nasledne muzu rsyncovat data. Vzhledem k tomu, ze v tech datech na cilovem stroji muzu ocekavat pekny bordel, bude zahodno rsyncu vnutit kompletni kontrolu kazdeho souboru, namisto defaultniho porovnavani timestampu a velikosti (nebo co to presne porovnava). Zbytecne prenasene prazdne bloky by mne asi trapily uplne nejmene.

@ZAJDAN: Pokud pres vyse uvedene a pres vsechno uvedene predtim stale jeste trvate na pouziti dd, tak byste se asi mel jit lecit. V kazdem pripade nevahejte a vypravejte, jak dobre byly vysledky.

[ZAJDAN]

To chce klid... postupně... dd se dá použít k vytvoření "počátečního stavu", ale je to zbytečné, bude se přenášet i prázdné místo... počáteční stav se dá stejně dobře vytvořit i tím rsyncem a to úplně stejným příkazem, jak pozdější synchronizace. Není na tom co vymýšlet. Ještě upozorňuji, že v rámci zachování konzistence na všech úrovních je třeba zastavit aplikace, databáze atd, vytvořit snapshot, spustit aplikace a to ostatní a snapshot tím pádem bude obsahovat konzistentní data (pokud toto není ošetřeno jinak na aplikační úrovni).

díky za podporu
přesně toto mi nebylo jasné, jak vytvořit počáteční stav
a co lvconvert   ...?

[Tuxik]

To chce klid... postupně... dd se dá použít k vytvoření "počátečního stavu", ale je to zbytečné, bude se přenášet i prázdné místo... počáteční stav se dá stejně dobře vytvořit i tím rsyncem a to úplně stejným příkazem, jak pozdější synchronizace. Není na tom co vymýšlet. Ještě upozorňuji, že v rámci zachování konzistence na všech úrovních je třeba zastavit aplikace, databáze atd, vytvořit snapshot, spustit aplikace a to ostatní a snapshot tím pádem bude obsahovat konzistentní data (pokud toto není ošetřeno jinak na aplikační úrovni).

díky za podporu
přesně toto mi nebylo jasné, jak vytvořit počáteční stav
a co lvconvert   ...?

No lvconvertem by se dal LVM převést na mirror, ale to by tak nějak očekávalo lokální dostupnost obou "disků", takže buď v rámci jednoho stroje, nebo SAN, nebo třeba DRBD. Ale pokud je to ve stavu, že to není možné teď nějak předělávat, udělal bych rsync a až to možné bude, zamyslel bych se nad tím btrfs. Je to samozřejmě otázkou peněz, v ideálním případě dvě SAN pole propojená optikou v oddělených lokalitách a mezi nimi mirror... ale to se bavíme o miliónech.