> urovni filesystemu - nikoliv na urivnich vyssich. Takova bezici databaze > bude po takovem prekopirovanim ve stejnem stavu jako by byla kdybych > pocitac v nahodnou chvili vypnul a pote zapnul. pgsql a oracle jsou v klidu nebot maji 1. rollforward recovery, 2. bugfree partial write recovery. U tech pokud maji data jen na jednom fs lze s klidem pouzivat fs snapshoty (zfs, ffs), dokonce je to i u prikladu pouziti snapshotu na zfs.
Pokud jsou data db pres vice FS tak nutno predem oznamit databazi online backup a pak zazalohovat data libovolnym zalohovacim nastrojem (tar, dump). Firebird2 ma svuj online backup program, ktery pracuje trochu jinak nez oracle/pgsql. V manualech k db je tato metoda podrobne popsana, jedna se o nejpouzivanejsi system zaloh velkych db. mysql s myisam nema zadny recovery mechanismus, mysql s innodb ma jen rollforward recovery, partial write recovery v mysql terminologii AKA innodb double write ma v mysql4.1 a 5.0 bug, crashne to, pokud transakce soucasne zvetsila db soubor a pri recovery je mensi nebot se zmena velikosti nestacila do fs zapsat a zaznam ukazuje na neexistujici blok. mysql 5.1 jsem netestoval. Pokud se narazi na tenhle bug, mysql nenabehne. U fs snapshotu by to ale mohlo i s mysql/innodb pracovat korektne, protoze tam se mu velikost souboru diky snapshotu zmensovat nebude. Podrobne jsem to ale netestoval. Ja osobne pouzivam snapshoty s mysql/myisam nebot nemam v mysql zadna dulezita data. Naopak nizsi spolehlivost tohoto reseni z nekolika duvodu vitam a tak mi nevadi, ze pri kazde odbnove dat ze snapshotu se nejaka data ponici. online backups ala Oracle v mysql jeste dlouho nebudou: http://forge.mysql.com/wiki/OnlineBackup takze pro spolehlive zalohy zbyva mysqldump --single-transaction pripadne --lock-tables zalohovani BerkeleyDB pomoci snapshotu je obecne problem. Pokud nemaji vytvoren transakcni log, tak vetsinou dojde k nenavratnemu poskozeni dat pokud byl soubor v dobe zalohy otevren pro zapis pokud aplikace nedela po kazdem zapisu sync db (coz prakticka zadna nedela). Vetsinou to nevadi, aplikace pouzivajici tuhle db s jeji nizsi spolehlivosti pocitaji a nepouzivaji ji pro dulezita data, pouzivaji ji povetsinou jako cache. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
