Dotaz: Zalohovani Databazi, doporuccte Software

[2012]

Ahoj,

poohlizim se po software, ciste pro zalohovani Databazi. Jde mi o zalohovani Postgres, Mysql, Sqlite(by bylo vyhodou), Oracle ani Mongo neni potreba. Vim ze to umi Bacula, ale rikam si, jestli to neni prilis "kanon na vrabce".

Dekuji za doporuceni.

Odpovědi

[Heron]

To trochu záleží na tom, co vlastně potřebujete zálohovat a k čemu ta záloha bude určená. Jestli vám stačí obyčejný dump (pg_dump, mysqldump), což pro menší db stačí, tak tento dump potom stačí uložit na zálohovací server a je to. Napsat si na to skript je triviální.

Pokud máte nasazen snad libovolný zálohovací systém (backuppc nebo tu baculu), tak snad každý z nich má možnost spustit příkaz před zálohou a tedy tam si lze dát skript na ty dumpy.

Pro větší db už jsou dumpy celkem nevýhodné a je lepší nasadit streaming zálohování binárních logů. Výhodou je možnost obnovení db ke stavu těsně před crashem (tj na poslední potvrzenou transakci). Pro postgresql je to PITR (point in time recovery), nebo prográmek pgBarman, který to nasazení zjednodušuje.

[2012]

Dobry den, dekuji jeste uprasnim detaily:

• DB, ktere se budou backupovat, bude co do poctu pocitam tak 10-50 (do budoucna).
• DB budou vetsinou male, v radu Gb, sem tam nejaky vetsi kousek, ale max. 50G
• DB jsou MySQL/PostgreSQL, obcas Sqlite
• DB musi by po zaloze konzistentni
• Super kdyby byla i moznost, vybrat DB ktere chci zalohovat (pokud jich je na stroji vic). Pripadne port pokud je nestandardni

Staci mi denni zalohy, asi nejlepe gzip dumpy, s rekneme max 2.tydenni historii. Jde mi o obnovu DB, v pripade "zhravarovni/rozbiti" stroje.

SW pro zalohovani nemusi mi GUI, klidne mi staci neco s textovymi konfiguraky. I kdyz zase na druhou stranu necim peknym s GUI nepohrdnu.

Klidne si necham poradit, a budu rad i za vice moznosti, ze kterych vybrat.

[Heron]

No pro zálohu PostgreSQL osobně používám právě pgBarman (pozor, starší článek, dneska toho umí víc). Stačí přidat další server do konfigurace a už to valí.

Pro zálohování serverů s MySQL použivám backuppc (bacula mi nevyhovovala z důvodu použitého storage řešení, které vychází ještě z dob pásek) a před zálohou definuju mysqldump skript. Následně backuppc ten dump uloží. Má to cli i webové rozhranní.

SQLite je prostě soubor na disku. Pro konzistentní zálohu by chtělo, aby jej nikdo nepoužíval v době zálohy, nebo použít snapshoty (tj fs s jejich podporou (btrfs, zfs)).

Takže moje zálohování db vypadá tak, že se v backuppc spustí skript (DumpPreUserCmd), který provede dumpy všech db a následně se zazálohuje.

Kontejnery (jaily) zálohuju prostě celé jako zfs snapshoty a zfs send (tj mimo téma tohoto dotazu).

Jo a místo gzip je lepší přejít na zstd. Je výrazně rychlejší, má podporu více cpu a lze si zvolit výrazně lepší kompresi (a stále rychlejší) než gzip. To jen tak poznámka na okraj. Před x lety se nasazovalo xz, které má teda ještě lepší kompresní poměr, ale je krutě pomalé. zstd bude, zdá se, novým králem.

[2012]

Dekuji. Automatizovane zalohovani (souboru) uz vyresene mame pres rsync/dirvish. Ja nyni prave potrebuju jeste neco, cim backupovat/dumpovat ciste jen Databaze.

Z.

[Jendа]

To zálohování souborů by bylo dobré mít taky atomické. No a pak už můžeš zálohovat i tu DB v souborech. Navíc by bylo dobré mít i konzistentní soubory vůči databázi -- třeba pokud je v databázi nějaký seznam/index souborů, které jsou fyzicky na disku, tak potřebuješ sejmout databázi a soubory ve stejný okamžik.

Atomičnost bych zařídil tak, že bych udělal LVM snapshot (případně btrfs, pokud máš, ale tam se CoW pro databáze myslím nedoporučuje, protože se to minimálně na non-SSD fragmentuje a zpomalí) a zálohoval z něj.

[Josef Kufner]

Databázím jde říct, že se bude dělat snapshot, ať si to na disku uvedou do konzistentního stavu. Pak uděláš snapshot, takže je vše konzistentní. Nakonec databázi zas necháš pracovat. Celá ta věc zabere sotva pár sekund a se snapshotem si pak můžeš dělat co je libo a jak dlouho je libo. Navíc ti nepopadají spojení, jen se čeká na zámek, takže pro aplikace a uživatele to jen trochu cukne.

[j]

Pokud je to udelane spravne, tak necukne, jenze tohle mysql vubec neumi.

Totizto aby to fungovalo, potrebujes dva disky, ne jeden. Na jednom mas data, a na druhym logy. Pak posles pres API krles, databaze dokonci bezici transakce, a odpovi ti OK. Muzes ten snap vyrabet klidne hodinu, databazi je to jedno, protoze dokud nereknes zpet, ze ses hotov, zapisuje do logu.

Takhle ovsem ziskas pouze datove konzistatneni zalohu, nikde neni receno, ze takova zaloha bude i aplikacne konzistentni. Coz je opet typicky problem prave u vseho, co pouziva mysql.

Ale protoze leda blazen by na mysql provozoval cokoli, co stoji za hovor, tak to prevazne nevadi. Specielne nad mysql mas totiz jen dve moznosti, jak to udelat (se stejnyma dusledkama).

1) posles lock na celou databazi = sestrelis aplikaci

2) stopnes tu appku

Nijak jinak se ke konzistentni zaloze nedostanes*

*jo, daj se zkouset jeste vopicarny na tema replikace a jejich pozastaveni, coz je prevazne nejlepsi zpusob jak rychle a efektivne prijit o data. Tak jako tak to neresi problem, ze mysql zalohovat neumi.

---

Dete s tim guuglem dopice!

[MP]

Pokud staci backup na urovni dumpu ukladany primo na server, tak kazdy DB server ma svoje vlastni konzolove nastroje. O zalohovani a udrzovani poctu zaloh se pak postara libovolny souborovy backup. Ten dump zavola bud neco na urovni cronu, nebo ten souborovy backup.

[ehmmm]

Asi tak. Pro kazdy typ databaze bych si napsal skript, ktery pouziva nastroje dane DB. A do toho skriptu bych jen dopisoval nazvy databazi.

[Jendа]

Staci mi denni zalohy, asi nejlepe gzip dumpy, s rekneme max 2.tydenni historii.

Tak pak nevím, co řešíš. Já dal před každou noční zálohou spustit příkaz mysqldump --all-databases | gzip --rsyncable > databaze.gz (TBH nevím jestli u dumpu DB rsyncable pomůže) a hotovo. Ale 50 GB mi na každodenní dumpování přijde už trošku dost.

[PetebLazar]

Má jít o off-line či on-line zálohu databází? Předpokládám, že v obou případech je cílem konzistentní záloha DB.

[2012]

Dobry den, ano presne, zalohy musi byt konzistentni a jsou mysleny on-line zalohy.

[dustin]

Vždy je potřeba řešit konzistenci záloh. Postgres neumím, ale u mysql/mariadb je dobré se podívat na význam parametrů --single-transaction a s tím související --skip-lock-tables umožňující backup produkčního stroje (jinak se na zámku zasekne produkční provoz).

U velkém DB se mi osvědčilo zálohovat do formátu soubor = tabulka (parametr --tab), než vše do obrovského texťáku. Následný inkrementální backup je pak daleko efektivnější, protože deduplikace sjednotí soubory bez změny tabulek od minulého data, případná obnova může zahrnovat jen vybrané tabulky (pokud lze) a může jen více tabulek paralelně (s dočasně vypnutou referenční integritou a aktualizací indexů (zálohovací skript rovnou do dumpu přidává SET @@session.unique_checks = 0; SET @@session.unique_checks = 0;). Samozřejmě TXT soubory po dumpu zkomprimovat, používám xargs bzip2 na malé soubory nebo pbzip2 na velké.

Pro binární klon produkční DB s rychlou obnovou je daleko vhodnější binární Percona Xtrabackup (mysql) nebo mariabackup (mariadb), ale samozřejmě to nelze inkrementálně přidávat, deduplikovat atd.

[Heron]

u mysql/mariadb je dobré se podívat na význam parametrů --single-transaction a s tím související --skip-lock-tables umožňující backup produkčního stroje (jinak se na zámku zasekne produkční provoz).

S tím, že je velmi nutné upozornit na to, že ne všechny mysql engine umí transakce. Takže bez zámků se ta db mění během zálohy a dump tedy není moc konzistentní. Obecná MySQL se dá afaik zálohovat jen s lockem a je tedy během zálohování zaseklá.

U PostgreSQL si můžeš vesele dumpovat a máš jak konzistentní zálohu, tak i neustále dostupnout db pro klienty.

[dustin]

Jistě, proto jsem napsal, aby se podíval na význam toho parametru. Provozovat v dnešní době ještě netranskační storage engine mi přijde naprosto zbytečné. InnoDB je defaultní engine už pěkně dlouho. Konverze sice jednorázově bolí, ale IMO se bohatě vyplatí (a už měla být dávno provedena). Samozřejmě při té příležitosti opravit nesmyslný 3bajtový kvazi-utf8, který považuji za hlavní legacy problém mysql/mariadb.

[2012]

To by byla taky vyhoda. Kdyby tohle zmineny backupovaci soft umel zohledit. Tz. aby Administrator nemusel resit, jestli tam je InnoDB, nebo MyIsam.