Dotaz: Jednoduche zalohovani s GUI?

[James_Scott]

Zdravim, hledam nejaky zalohovaci program s GUI pro Linux, jako alternativu k CobianBackup z Woken. chci aby -byl jednoduchy -podporoval sitove zalohy -moznost planovani

Diky :)

Odpovědi

[Fuky]

Myslím, že GUI je pro zálohování zbytečné, jestli chceš napiš příklad jak si automatickou/ruční zálohu konkrétně představuješ a můžeme to zkusit vyřešit pohodlněji skriptíkem. Případně, když přesně specifikuješ jak si představuješ to GUI, může se tu dříve či později objevit.

[saman2]

Dobrý den, kdysi jsem v práci na Windows používal právě CobianBackup a později jsem doma na Linuxu hledal podobný nástroj. Pokud Vám nevadí, že je to psané v Javě, velice mi vyhovuje (a Cobianu je to v lecčem dost podobné) Areca Backup, který najdete zde:
http://www.areca-backup.org/
Myslím, že to umí vše, co požadujete.

[pee]

Cobian neznam, ale co pouzit gnomackou nadstavbu nad rsync grsync ?

[pee]

jeste jsem objevil toto, treba to je to, co hledate.

[Andrej]

Jednoduché zálohování s plánováním, podporou sítí a možnostmi, které GUI nikdy mít nebude: cron a rsync.

Rozumnou kompresi a inkrementální zálohy umí zajistit například tar --listed-incremental=.... (Podrobnosti znamenitě popisuje manuálová stránka.)

Složité zálohování s GUI: Co třeba sbackup?

Všechna zmíněná řešení jsou ale pořád ještě amatérské postupy hodné Windows. Můžou totiž klidně zazálohovat nekonzistentní data. Korektní postup je (1) vytvořit LVM snapshot, (2) zazálohovat snapshot (přes rsync nebo tar --listed-incremental=... nebo jakkoliv jinak) a (3) uvolnit LVM snapshot. Pro snapshot je potřeba zanedbatelný zlomek kapacity originálu, pokud se používá jen krátce a originál se během té doby nemění příliš radikálně.

[kyytaM]

A LVM snapshot bude vzdy konzistentny? (napr. taka databaza? ;) )

[ntyrnbyr]

flush tables with read lock...

[pee]

+1 .. nedavno tady bylo o LVM snapshotu docela dlouhe vlakno ..

[Andrej]

Dělat snapshot nad oddílem, kde běží databáze, jednoduše není rozumné. Databáze má přece vlastní a mnohem sofistikovanější zálohovací mechanismy. Zkopírování dat soubor po souboru je nejlepší způsob, jak tu databázi úplně odepsat. Stačí zapomenout třeba na zachování timestampů u souborů a data ze zálohy už nikdo nikdy neuvidí. Jediný opravdu spolehlivý způsob, jak zazálohovat databázi, je dump. Ať už je to SQL dump nebo něco binárního, bude to vždy konzistentní a bude to umět přečíst každá současná i budoucí verze příslušného DBMS na každé platformě.

Kromě toho existují i mnohem triválnější protipříklady než databáze. Například přidání uživatele do skupiny. Příslušná utilita či skript ho přidá do /etc/group, v tom okamžiku někdo udělá snapshot a teprve poté dojde k přidání do /etc/gshadow. Vznikne snapshot, který je v jistém ohledu nekonzistentní.

Snapshot má pouze zajistit, aby nevznikaly poškozené soubory, které někdo zrovna přepisuje zálohovacímu programu pod rukama. Soubory, které se často a nahodile mění, se samozřejmě můžou i do snapshotu dostat v nekonzistentní podobě. Nicméně otázka je, k čemu takové soubory jsou a zda je opravdu cílem je zálohovat.

[Šangala]

Jen poznámka, například mysqldump bez správných parametrů také nemusí být konzistentní.
viz --lock-all-tables --single-transaction --lock-tables atd.

A jinak je možné například databázi(či jinou službu) zastavit, vytvořit snapshot,a znovu ji spustit a v klidu zálohovat její konzistentní data.

[Andrej]

Jistě, takové triky jsou možné, ale ten dump se jednak obejde bez downtime a druhak může zabrat mnohem méně místa, pokud je zvolen vhodný formát a vhodná komprese. To druhé je celkem jedno, ale o to první jde skoro vždy. Kromě toho, dump se dá obnovit i v kterékoliv novější verzi DBMS, což se o nízkoúrovňových datech rozhodně říct nedá. Například PostgreSQL bude rozumět pouze datům ze stejné minor verze.

[Šangala]

Souhlasím - jen jsem to doplnil :).
Snapshot používám jen na optimistickou zálohu XEN strojů jako celku pro snadné a rychlé obnovení.