LVM - manipulace se svazky

[abc123]

vsak snapshot je samozrejmost to som tiez spominal od zaciatku ale to je, jedno su proste existujuce overene riesenia, neviem preco vymyslat teplu vodu.

[Reklama]

[ZAJDAN]

ok, nechám si poradit od zkušenějších a počáteční stav na backup server udělám přes rsync
bude problém když:
- remote LVM je větší než source LVM ?

je jedno ? zda posílám rsync na:
- rsync /dev/mapper/myGroup--lv1 ssh user@ip:/dev/mapper/myGroup--lv1
nebo
- rsync /dev/myGroup/lv1 ssh user@ip:/dev/myGroup/lv1

[abc123]

rsyncovat vies len subory, cele blokove zariadenie ti bez DDcka nepojde prekopirovat cize ak rsync, tak /path/to/source/ /path/to/destination/

Ale potom ti snapshoty lvciek nepomozu, uz budes musiet robit incremental backupy suborovej urovni.

[Lol Phirae]

vsak snapshot je samozrejmost to som tiez spominal od zaciatku

Pro tazatele evidentně ne. 

[ByCzech]

ok, nechám si poradit od zkušenějších a počáteční stav na backup server udělám přes rsync
bude problém když:
- remote LVM je větší než source LVM ?

To mi připomíná, když jsem si jednou v hospodě u takové hezké blonďaté servírky objednal dvojitý džus (4 dcl), odkráčela s nechápavým výrazem, aby se za chvíli s ještě nechápavějším vrátila s otázkou: "A můžu to dát do půllitru?" Když se dočkala odpovědi: "Pokud se to vejde, tak klidně!" už se její nechápavý výraz nedá ani popsat . Objednávku donesla s omluvou, že si ze mě nechtěla dělat srandu .

[Reklama]

[ZAJDAN]

rsyncovat vies len subory, cele blokove zariadenie ti bez DDcka nepojde prekopirovat cize ak rsync, tak /path/to/source/ /path/to/destination/

Ale potom ti snapshoty lvciek nepomozu, uz budes musiet robit incremental backupy suborovej urovni.

proto jsem od samého začátku šel po 'dd'
takže celá ta věda je zastavit virtuál a pustit rsync na soubory?
rsync /mnt/virtualmachine-1 ssh user@ip:/mnt/virtualmachine-1

to by ale neřešilo live backup (běžícího virtuálu)

[JardaP .]

rsyncovat vies len subory, cele blokove zariadenie ti bez DDcka nepojde prekopirovat cize ak rsync, tak /path/to/source/ /path/to/destination/

Tak ono by nejspis melo jit rsyncovat blokova zarizeni. Proc ne, kdyz to v systemu je videt jako soubor. Otazka tedy je, jak by se rsync tvaril na to, ze kazde to zarizeni ma jinou fyzickou velikost.

Ale tim porad nemizi problem s dd, ze na cilovem stroji ziskam leda tak nabourany FS se soubory v nekonzistentnim stavu.

[Tuxik]

rsyncovat vies len subory, cele blokove zariadenie ti bez DDcka nepojde prekopirovat cize ak rsync, tak /path/to/source/ /path/to/destination/

Ale potom ti snapshoty lvciek nepomozu, uz budes musiet robit incremental backupy suborovej urovni.

proto jsem od samého začátku šel po 'dd'
takže celá ta věda je zastavit virtuál a pustit rsync na soubory?
rsync /mnt/virtualmachine-1 ssh user@ip:/mnt/virtualmachine-1

to by ale neřešilo live backup (běžícího virtuálu)

Nenene... zastavit aplikace na virtuálu, udělat snapshot (pár sekund), pustit služby, přimountovat snapshot, zazálohovat snapshot, odmountovat, smazat snapshot. Běžící stroj včetně aplikací je konzistentně nezálohovatelný, pokud na to aplikace nejsou připraveny a nemají to ošetřeno. U nějakých webů s pár přístupama to nebude problém a zastavovat většinou netřeba, ale jestli je to kritická aplikace, ve které může kdykoliv někdo něco dělat a hlavně měnit, pak bych se podíval do její dokumentace na doporučený postup. Pokud tam nic takovýho není, omlátit výrobci o hlavu, vypovědět smlouvu a hledat něco rozumnýho.

[ZAJDAN]

rsyncovat vies len subory, cele blokove zariadenie ti bez DDcka nepojde prekopirovat cize ak rsync, tak /path/to/source/ /path/to/destination/

Tak ono by nejspis melo jit rsyncovat blokova zarizeni. Proc ne, kdyz to v systemu je videt jako soubor. Otazka tedy je, jak by se rsync tvaril na to, ze kazde to zarizeni ma jinou fyzickou velikost.

Ale tim porad nemizi problem s dd, ze na cilovem stroji ziskam leda tak nabourany FS se soubory v nekonzistentnim stavu.

od sameho zacatku je mi jasne ze dd ma smysl jen pri unmountlem zarizeni.....to jsem byl ochoten udelat - jednou pro ziskani vychozich dat
s tím ze dale bych to jen prikrmoval snapshotama

[Lol Phirae]

od sameho zacatku je mi jasne ze dd ma smysl jen pri unmountlem zarizeni.....to jsem byl ochoten udelat - jednou pro ziskani vychozich dat

Goto. To snad není možné.

[abc123]

https://www.baculasystems.com/enterprise-backup-solution-with-bacula-systems/vm-performance-backup-suite

Priklad, prvy odkaz v googli, treba to porovnat s moznostami free baculy. spravi to backup virtualiek na najpouzivanejsich hypervizoroch, full aj incremental. neviem ci OP potrebuje nieco viac ako uz hotove riesenia. Je XY inych free rieseni ktore uz budu mat vsetko vymyslene, su tam trigre na stopovanie aplikacii a databaz v case backupu, 99% usecasov je uz vynajdenych a overenych casom. Preco nas ma zaujimat ci to na pozati robi DD, alebo cat, alebo si to vola nejaku vlastnu binarku?

[ZAJDAN]

Nenene... zastavit aplikace na virtuálu, udělat snapshot (pár sekund), pustit služby, přimountovat snapshot, zazálohovat snapshot, odmountovat, smazat snapshot. Běžící stroj včetně aplikací je konzistentně nezálohovatelný, pokud na to aplikace nejsou připraveny a nemají to ošetřeno. U nějakých webů s pár přístupama to nebude problém a zastavovat většinou netřeba, ale jestli je to kritická aplikace, ve které může kdykoliv někdo něco dělat a hlavně měnit, pak bych se podíval do její dokumentace na doporučený postup. Pokud tam nic takovýho není, omlátit výrobci o hlavu, vypovědět smlouvu a hledat něco rozumnýho.

díky...výstižné, teď už se mi to konečně začíná objasňovat

[ZAJDAN]

takze jednim minimalistickym resenim by mohl byt tento script volaný dle potreby cronem:

Kód [Vybrat] Rozbalit

#!/bin/bash

# Create a LVM snapshot of the var LV
lvcreate -L 50G -s -n websnap /dev/myGroup/webserver

# Mount the snapshot
mount /dev/myGroup/websnap /mnt/webserver-snapshot/

# Copy to remote
rsync /mnt/webserver-snapshot/  ssh supervisor@ip:/dev/myGroup/webserver

# Remove the snapshot
umount /mnt/webserver-snapshot/
lvremove -f /dev/myGroup/websnap

[ZAJDAN]

takze jednim minimalistickym resenim by mohl byt tento script volaný dle potreby cronem:

Kód [Vybrat] Rozbalit

#!/bin/bash

# Create a LVM snapshot of the var LV
lvcreate -L 50G -s -n websnap /dev/myGroup/webserver

# Mount the snapshot
mount /dev/myGroup/websnap /mnt/webserver-snapshot/

# Copy to remote
rsync /mnt/webserver-snapshot/  ssh supervisor@ip:/dev/myGroup/webserver

# Remove the snapshot
umount /mnt/webserver-snapshot/
lvremove -f /dev/myGroup/websnap

diky Tuxiku za srozumitelnou osvětu!

[Tuxik]

takze jednim minimalistickym resenim by mohl byt tento script volaný dle potreby cronem:

Kód [Vybrat] Rozbalit

#!/bin/bash

# Create a LVM snapshot of the var LV
lvcreate -L 50G -s -n websnap /dev/myGroup/webserver

# Mount the snapshot
mount /dev/myGroup/websnap /mnt/webserver-snapshot/

# Copy to remote
rsync /mnt/webserver-snapshot/  ssh supervisor@ip:/dev/myGroup/webserver

# Remove the snapshot
umount /mnt/webserver-snapshot/
lvremove -f /dev/myGroup/websnap

diky Tuxiku za srozumitelnou osvětu!

Není zač, tak nějak to je. Ještě upozorním, že záloha DB je dost samostatná věc, na úrovni fs bude fungovat, ale pokud je DB větší a je v ní nějaký pohyb, budeš v podstatě pokaždé dělat full backup. To se potom řeší vynecháním DB z rsync, nějakou plnou zálohou třeba jednou týdně (může být i ta fs) a potom se k tomu zálohují redo logy / transaction logy, ale to už je databázově závislý. Pokud tam DB nemáš, nebo není moc velká, netřeba řešit.