Zrcadlení disku po síti: něco lepšího než rsync

[CPU]

Zdravím,

jak zrcadlit obsah disku z jednoho DEBIAN serveru na druhý?

Mám server a na něm zálohy co dvě hodiny.
Server zdechne před nebo v průběhu vytváření zálohy a jsem bez zálohy.

Je něco lepšího než RSYNC, čím bych mohl synchronizovat obsah disku?
Nemám velkou důvěru ve schopnosti RSYNCu vůči živé databázi.

Nemám problém se ztrátou nedokončených transakcí, server/databáze se z toho dokáže vylízat a v nejhorším použiju tu dvě hodiny starou zálohu, ale jak to udělat nejlíp?

Před pár lety jsem provozoval RAID po síti s EXT3 (?) a byl jsem upozorněn, že je to vážně hloupý nápad. 
Ale teď jsou k dispozici věci jako DRBD (Distributed Replicated Block Device), což vypadá líp.
DRBD nevypadá špatně...
https://www.howtoforge.com/setting-up-network-raid1-with-drbd-on-ubuntu-11.10
No nemám s tím žádné zkušenosti.

Teď, když to lehne, je plán obnovy to vyřešit ručně (na automatizaci nebo solidní SANku nejsou milionky).

[Reklama]

[Martin Mlynář]

DRBD je dobre, ale NENI to zaloha. Neochrani te pred poskozenim FS. Vesmes mas tyto moznosti (mozna nekdo doplni), pokud se jedna o DB:

 - LVM a snapshot, ktery odlejes nekam pryc
 - provest zalohu databaze pres urceny nastroj a rsync/cokoliv smerem pryc
  - nepostrehl jsem, co je to za databazi, pokud postgres, staci napr pres pg_start_backup - viz https://www.postgresql.org/docs/9.3/continuous-archiving.html nebo nastavit WAL shipping.
  - s mysql se obavam, ze budes muset pouzit mysqldump, ale tam nejsem kovany, takze ruce do ohne za neexistnci jinych reseni nedam

[CPU]

DRBD je dobre, ale NENI to zaloha.

No a co to je, když to není záloha?
FS se dokáže vyhrabat i dost špatnýho stavu.
Databáze se dokáže opravit z logů.
Pokud bude poslední log poškozený, tak jsem přišel o poslední kousek, poslední chvíli, ale ne dvě hodiny.
Pokud se systém neočekávaně vypne, téměř vždy je něco víc nebo míň nakopnuté a všechno nějak funguje.
Moderní souborové systémy jsou transakční, databáze zahodí rozdělané transakce a naběhne, jako v systému může zůstat dost čurbesu, ale tak to je normální.

Nedělám chytrého, ptám se. Ne...co by kdyby na Prahu zrovna spadl meteorit, ale běžně s běžnou pravděpodobností.

Prostě k tomu přijdu, provedu kontrolu disku, kontrolu databáze a znova to nakopnu. Pokud ne, tak obnovím data ze zálohy. Ne?

Hlavní zálohu vytvářím co dvě hodiny a hned jí odlévám pryč, dokonce mám i Offline zálohu s retencí 1D-7D.

[Martin Mlynář]

No a co to je, když to není záloha?

Kód: [Vybrat]

DRBD®– software is a distributed replicated storage system for the Linux platform (src: https://linbit.com/drbd/)
Ne ale ted vazne. Pokud jsi jeste nemusel resit poskozeny journalovaci FS, tak to povazuj za stesti. Resit to je fakt radost. Samozrejme je jista sance, ze se ti nic nestane. Pokud mas zalohy, asi ok. Ale ja bych do toho teda nesel. DRBD se hodi na uplne jine veci. Kdyz pominu to, ze musis resit, ze muzes mit primountovane jen na "jednom konci" - pokud nepouzijes neco jako ocfs2, tak block device bohuzel neni tak trivialni disciplina, jak se muze zdat, jakmile k read/write/seek primotas bariery, sync a dalsi srandy. Pokud pojedes synchronne, prida ti to zase latenci.

Pro DB proste existuji vhodnejsi reseni jako napr. wal shipping.

[Jakub Štech]

Na primáru dělejte co dvě hodiny snapshoty (btrfs, zfs, lvm), jejich diffy oproti předchozímu snapshotu posílejte na repliku, kde to rovnou aplikujte na živý filesystem. Něco jako:

Kód: [Vybrat]

# tohle v cronu na primáru jednou za 2h
btrfs subvolume snapshot -r / /mnt/backup/snapshots/123
btrfs send -p /mnt/backup/snapshots/122 /mnt/backup/snapshots/123 | gzip > /mnt/backup/temp/122-to-123.gz
scp /mnt/backup/temp/122-to-123.gz replika:/mnt/backup/incoming/new.gz
rm -f /mnt/backup/temp/122-to-123.gz
btrfs subvolume delete /mnt/backup/snapshots/122


Kód: [Vybrat]

# tohle v systemd.path triggeru na replice, čekat na /mnt/backup/incoming/new.gz
gzip -d < /mnt/backup/incoming/new.gz | btrfs receive /mnt/backup/replica
rm -f /mnt/backup/incoming/new.gz

V /mnt/backup/replica bude vznikat chronologická řada snapshotů se stejnými názvy a obsahem jako na primáru, a narozdíl od rsync je to atomická operace.

[Reklama]

[CPU]

Tak stav co 2 hodiny mám i teď pomocí Veeamu. Abych si pomohl, musel bych to dělat co 5 - 10 minut 

BTW - k čemu DRBD tedy je? Co je jeho best use case?

Čekal bych posun oproti mdadm raidu na iSCSI...který fungoval slušně a testovací snapshooty se dařilo obnovit.

Klidně bych použil i mirror driver, který duplikuje provoz do pipe na druhý stroj. Druhý stroj není živý...

[_Tomáš_]

DRBD je levný SW raid 1 po síti se všemi nevýhodami (výkonnost, latence, zotavování po výpadku atd.). Na extu to můžeš mít pouze jako active-pasive s failoverem. Asi jako hlavní nevýhoda je, že to je trochu poruchové, funguje pouze v privátní síti (nepodporuje šífrování a ani bezpečnou autorizaci) a je výrazně ovlivněno vytížením jednotlivých nodů (není třeba dobrý nápad takhle replikovat data z živé zatížené databáze nebo webového serveru), replikujena úrovni bloků, takže se občas může fs poškodit.

Potřebuješ to synchronně nebo asynchronně? Jaký objem dat a jaké iops? Jak je důležitá latence a doba obnovení?

Já na domácím labu mám cifs, v práci máme enterprise diskové pole a glusterfs. Dobře funguje zfs. Někdy lépe funguje dělat replikaci o úroveň výš, např. v databázi, aplikaci.

[Zopper]

Nemám velkou důvěru ve schopnosti RSYNCu vůči živé databázi.

Pokud jde jen o tu databázi, a chcete okamžitá data (co 2 hodiny je pozdě), tak bych hledal v databázovém světě. Primární DB + repliky, které se synchronizují přímo z databáze per operace. S trochu štěstí bude ta vaše databáze mít nějakou přímou podporu, kterou jen nakonfigurujete. Například https://www.oracle.com/database/dataguard/. Přijde mi to jako mnohem spolehlivější způsob, než databázi pod rukama krást soubory.

Pokud tohle nijak jednoduše udělat nejde... Jak složitá je ta aplikace? Dávalo by smysl přidat mezivrstvu, co rovnou posílá zápisy/updaty na víc databází?

[Filip Jirsák]

Nejprve je potřeba si uvědomit, co vlastně chcete. Chcete zálohovat? Záloha znamená, že v případě nutnosti obnovy ze zálohy máte data platná k okamžiku zálohy, o novější data přijdete. Nebo chcete dělat online zrcadlení, tj. v okamžiku potvrzení zápisu mít data uložená na více místech? Každé slouží k něčemu jinému a pokud chcete minimalizovat pravděpodobnost ztráty dat, potřebujete obojí. Chcete to dělat obecně nad souborovým systémem (kde není zaručeno, že o data nepřijdete, pokud aplikace se souborovým systémem nepracuje správně)? Nebo to chcete dělat nad databází (které obvykle mají podporu pro to, aby online synchronizovaná nebo zálohovaná data byla konzistentní)?

[CPU]

Mám zálohu co 2 hodiny.
Jde mi o snížení ztráty dat, tj. abych nepřišel o data za dvě hodiny, ale třeba o data za 5-10-15 minut.
Nemá/nemusí to být spolehlivá záloha dat, pokud bude načutnutá, tak se to nepoužije, nebudu si s tím lámat hlavu a použiju zálohu z Veeamu. Kopírovat to chci v rámci místní a to dedikované sítě 10 Gbps, šifrované to být nemusí.

Spíš mě děsí ty zmíněné náznaky "ne"spolehlivosti DRBD.

to je trochu poruchové

[Filip Jirsák]

Mám zálohu co 2 hodiny.
Jde mi o snížení ztráty dat, tj. abych nepřišel o data za dvě hodiny, ale třeba o data za 5-10-15 minut.

Tak zálohujte častěji.

Pořád nevíme, co chcete zálohovat. Obecné soubory, databázi?

Nemá/nemusí to být spolehlivá záloha dat, pokud bude načutnutá, tak se to nepoužije

Jste si jistý tím, že dokážete poznat, že je ta záloha špatná?

Spíš mě děsí ty zmíněné náznaky "ne"spolehlivosti DRBD.

Distribuované úložiště není záloha.

[_Jenda]

Nemám velkou důvěru ve schopnosti RSYNCu vůči živé databázi.

No samozřejmě, že když rsyncem budeš kopírovat datové soubory běžící databáze, tak to nebude fungovat. K tomu musíš udělat snapshot.

Použij funkci databázové replikace - všechny běžné databáze ji mají. Na rozdíl od synchronizace souborového systému to také bude mnohem efektivnější.

Problém je, pokud ti tam běží aplikace, co si drží konzistenci mezi soubory a databází, a neumí replikaci. Al nenapsal jsi, co tam teda provozuješ.

Na primáru dělejte co dvě hodiny snapshoty (btrfs, zfs, lvm), jejich diffy oproti předchozímu snapshotu posílejte na repliku, kde to rovnou aplikujte na živý filesystem.

Tazatel to chtěl realtime, a jinak tohle zní dost fragilně - jako že je dlouhá cesta, kde může nastat chyba a pak to v cíli nebude fungovat, a bude složité se z toho zotavit. btrfs snapshoty dělám, ale kopíruju je na souborové úrovni (rsync --inplace).