Dotaz: Jaký SW na zálohování dat i s verzováním?

[Zopper]

V současné době využívám cloudových služeb (konkrétně SpiderOak) na zálohování a synchronizaci dat mezi více PC, přičemž občas využívám i toho, že mám přístup i ke smazaným či změněným souborům. Rád bych si ale tuto potřebu řešil vlastními silami, ať už kvůli větší bezpečnosti (nedávám data třetí straně), či rychlosti. Hledám tedy nějaký program či kombinaci programů, které by uměly následující:

• automatická záloha na server a následně replikace změn na další stroje
• verzování souborů - když přepíšu obrázek nějakým jiným, nebo ho smažu, chci mít možnost se dostat k několika předchozím verzím
• na straně klienta by měl být řešení platformově nezávislé

Samotné zálohování a replikaci by vyřešil rsync v cronu a síťový disk, nicméně nenašel jsem informace o tom, že by rsync uměl zálohovat X verzí každého souboru. Z toho důvodu ani nemůžu použít snapshotový FS, jelikož se chci obvykle vrátit u jednoho souboru a ne u všech. Co se provedení verzování týče, klidně by stačil zrcadlový adresářový strom, kde by se k názvu souboru přidalo datum odsunutí, či jen číslo verze - jde o to, aby se to nemíchalo v normálním stromě s aktuálními soubory.

Pod platformovou nezávislostí si představuji synchronizaci a verzování dostupné jak na Linuxu, tak na Windows (a možná do budoucna Apple). Pro mobilní klienty (Android, ...) bude přijatelné připojení se přes sftp, byť by bylo lepší, kdyby i tady šlo hlídat změny a verzovat.

Řešil někdo něco takového, či má nápad, jak na to? Děkuji.

---

---

Odpovědi

[NN]

Ja bych rekl, ze dost zalezi na objemu a stylu prace s daty na volbe zalohovacicho mechanismu. POkud pracujes casto s malym objemem, mozna bych pouzil nejake programatorske verzovaci nastroje jako git. Pokud jsou to rozsahlejsi data a vetsi objemy tak napr. bacula.

NN

[Zopper]

No jsou to běžné dokumenty, od zdrojových kódů až po hudbu, videa, ... prostě větší část home. Na baculu se podívám, ta vypadá jako to, co hledám, díky.

[Jooky (inactive)]

ja pouzivam software bacula v zmiesanom prostredi (director + storage na linuxe, file daemon na linuxe a windowse).
Priklad:

+-------+---------------------+---------------------+---------+-----------+----------+---------------+
| JobId | Name                | StartTime           | JobType | JobStatus | JobFiles | JobBytes      |
+-------+---------------------+---------------------+---------+-----------+----------+---------------+
| 6240  | /var/log/emerge.log | 2011-07-22 18:00:02 | B       | T         | 575      | 103161408     |
| 6231  | /var/log/emerge.log | 2011-07-21 18:03:44 | B       | T         | 77151    | 1400689036    |
| 6218  | /var/log/emerge.log | 2011-07-20 18:00:03 | B       | T         | 488      | 83690330      |
...
| 6019  | /var/log/emerge.log | 2011-06-28 18:00:03 | B       | T         | 76274    | 1328834334    |
| 5939  | /var/log/emerge.log | 2011-06-19 20:38:45 | B       | T         | 82992    | 1397323096    |
| 5871  | /var/log/emerge.log | 2011-06-12 14:40:13 | B       | T         | 83793    | 1575742423    |
+-------+---------------------+---------------------+---------+-----------+----------+---------------+

System si uklada informacie o kazdom backupe v databazovom katalogu. V GUI sa da pozriet aj timestamp samotneho suboru a checksum. Podla roznych kriterii sa da nastavit co ma obnovit. Samotna zaloha moze byt ako by sa ocakavalo "full backup", "incremental", alebo "difrerential".

Toto by odpovedalo na dve otazky: "Versionovanie", "Nezavislost na platforme".

Na synchronizaciu sa da pouzit moznosti obnovovania "restore". Z principu moznu nastat tri moznosti:
- subor sa nenachadza na cieli (obnovi sa zo zalohy)
- subor sa nachadza na cieli (prepise sa podla podmienky: always / ifnewer/ ifolder / never)
- subor sa nenachadza v obnovovanom zozname suborov (!?)

Ako by som implementoval poslednu moznost nie som si isty. V sekcii obnovovania (restore) sa takato moznost nenachadza, ale jedna funkcia by sa dala pouzit. Bacula vie porovnavat system oproti katalagu (vpodstate TripWire ochrana). Specialny typ job-u s pomenovanim "verify" sa o toto stara. Internou limitaciou sa da vygenerovat zoznam "zmazanych" suborov. Teda tych co su v katalogu, ale nenechadzaju sa na cielovom systeme. Tento zoznam sa moze pouzit napr. v "post exec" casti na vycistenie synchronizovanej masiny.

Dalsi moznost je v "pre exec" casti vymazat vsetko na cieli. Ja by som toto pouzival, len ak sa synchronizacia nebude vykonavat casto a neohrozi to funkconost systemu ... dost zalezi o ake data ide a ich mnozstvo.

[dustin]

Používáme již roky backuppc a jsme s ním zatím spokojeni. Jen perlička - dnes jsme zjistili, že již pár měsíců zbytečně pravidelně zálohujeme z několika vývojářských strojů celkem 150 miliónů již nepotřebných souborů. Nebýt stížností vývojářů na dlouhé časy běhu zálohovacího procesu, který je na vytížení disku znát (vždy několik dnů vs. desítky minut), ani bychom si toho nevšimli. HW - HP ML115 za 11 tis. a 4 SATA disky v RAID10, komplet zálohy včetně několika let historie celkem 1,4TB, počet souborů (většina jsou hardlinky do poolu - interní deduplikace backuppc) na zálohovacím filesystému odhaduji tak půl miliardy. Kopie na offline disky (mirror na úrovni sw raidu) trvá pár hodin.

[Jan Mikuš]

Co rdiff-backup.

[the.max]

jop, zrovna jsem ho sem chtel taky dopsat

[Zopper]

Díky za tipy, rdiff-backup sice (podle diskuzí) neumí synchronizovat změny mezi více PC, ale zkouším následující řešení:

Na serveru je jeden synchronizační adresář, který si všichni klienti synchronizují přes rsync a tento se po každé synchronizaci zálohuje přes rdiff-backup. Není to sice řešení pro spolupráci více osob, ale protože to stejně mám hlavně pro svou osobní potřebu "stejná data na všech PC, kde něco dělám", tzn. změna stejného souboru je prakticky vyloučená, tak řešení konfliktů metodou "nejnovější soubor" stačí.

Na Baculu a Backuppc se ještě podívám, ale přijde mi, že námaha a čas, kterou budu muset na instalaci vynaložit se mi proti výše zmíněnému řešení nevyplatí. Zatím tedy otázku nechám otevřenou, než vyberu definitivní řešení.

[Kit]

A co zmíněný Git? Jeho hlavní úlohou je verzování, zálohování je vlastně bonus. Je vhodný i pro synchronizaci práce více osob, dokonce i na stejných souborech. Je velmi úsporný na objem přenášených dat a tedy i rychlý.

[Zopper]

Git má bohužel problémy s velkými soubory - a já v tom rozhodně budu mít obrazy DVD, možná i virtuální disky pro VMWare. Nicméně při hledání nějakých informací o gitu a velkých souborech jsem kromě několika pokusů o vylepšení gitu našel i zápisek někoho, kdo použil svn (http://kitenet.net/~joey/svnhome/), které, i podle mých testů, nemá s velkými soubory problémy, nebo jsem je aspoň na testovacím vzorku nezpozoroval.

[Kit]

Git je určen především pro velké množství malých souborů, což je typické pro vývoj software. Obrovské soubory zmíněných typů jsou zpravidla výsledným kompilátem a proto se do archivu Gitu neukládají.

Pro velké soubory by bylo zase praktičtější použít rsync nebo rdiff-backup podle typu potřeb. Je možné provozovat oba systémy paralelně.

Významným rozdílem Gitu proti SVN je lokální úložiště projektu, které SVN nemá. Je tedy nutné si rozmyslet, jaké řešení potřebuji. Je možné Git a SVN kombinovat, tedy SVN na serveru a Git na klientovi, což považuji za velmi praktickou kombinaci. Zejména pro ty, kteří jsou na Git zvyklí a v zaměstnání jsou nuceni používat SVN.

[pavlix]

Git má bohužel problémy s velkými soubory

Máš pro to nějaký (současný) odkaz?

[Zopper]

Například prosinec 2010 - http://lwn.net/Articles/419241/. Očividně to jde nějak obejít, ale když můžu použít čisté SVN, tak proč mít upravený GIT.

[Kit]

Pokud vím, SVN nemá lokální úložiště. Nelze tedy verzovat bez přístupu k serveru. To může být pro mobilního uživatele hodně omezující.

[Zopper]

To záleží na tom, jak často má být verzování používáno. V mém případě je to hlavně ochrana proti tomu, když si omylem přepíšu/smažu nějaký soubor a případů, kdy se nemohu dostat na server je minimum (svn over ssh).

[Kit]

Hlavně jsou to dva podstatně odlišné systémy. V SVN je celá historie projektu soustředěna na serveru, je tedy nutné ho pravidelně zálohovat.

U Gitu má každý člen kompletní historii projektu plus své vlastní vývojové větve, které nechce nikde prezentovat. V případě havárie serveru je možné repozitář zrekonstruovat podle repozitáře libovolného klienta. Spolehlivost uložení dat je tedy řádově vyšší.

Je však možné, že uvádím vlastnosti, které nejsou prioritní.

[pavlix]

Například prosinec 2010 - http://lwn.net/Articles/419241/.

Tam žádný konkrétní popis problémů nevidím.

[Kit]

Našel jsem článek o tom, že i velké soubory se dají v Gitu elegantně řešit pomocí nástroje Bup. Podle popisu by to mohlo být na obrazy DVD nebo VMware velmi efektivní.

[Max]

Tak třeba seznam používá svn i jako zálohovací sw (svn backup). Ono to má dosti výhod, dobrá je i velikost zálohy, svn dobře šetří místem.
Zdar Max

[Pev]

3 roky stará informace, otázkou je, zda je to stále pravda.

[Zopper]

Tak zatím zkouším (zdá se že úspěšně) SVN. To co chápu jako hlavní výhodu GITu (tj. informace o revizích jsou lokální, ne jen na serveru) je pro mě nepodstatné. Pokud by se ale objevily nějaké problémy, které by GIT vyřešil snáz, zkusím i ten.

Pro automatizaci a usnadnění práce mám napsaný script (pokud bude všechno fungovat jak má, tak ho ještě rozepíšu, ošetřím nedostupnost serveru či chyby od SVN a tak, ale pro testování to stačí):

IFS=$(echo -en "\n\b")
export SVN_EDITOR=cat

# echo "provadim zmeny repozitare v pripade potreby"

ADDR_OUT="domain.tld" # vnejsi adresa
ADDR_HOME="192.168.0.1" # adresa ve vnitrni siti

# cesta k repozitari
PATH_REPO="/cesta/na/serveru/REPO"
PATH_SRC="/cesta/na/lokalnim/stroji/REPO"

cd $PATH_SRC

# Pingne na vnitrni adresu. Pokud dostane odpoved, predpoklada, ze je
# dostupna. Pokud vyprsi timeout, nastavi adresu SVN serveru na vnejsi
# adresu.
if [ `ping -q -c 1 $ADDR_HOME | grep "1 received" -c` -eq 0 ];then
        echo "nejsem doma, nastavim vnejsi repo"
        svn switch --relocate svn+ssh://user@$ADDR_HOME$PATH_REPO  svn+ssh://user@$ADDR_OUT$PATH_REPO
else
        echo "jsem doma, nastavim domaci repo"
        svn switch --relocate svn+ssh://user@$ADDR_OUT$PATH_REPO 
svn+ssh://user@$ADDR_HOME$PATH_REPO
fi

 
echo "processing files to add..."
find . | grep -v "\.svn" |  sed -e s/^/\"/g -e s/$/\"/g | xargs -r svn add 2>&1 | grep -v "under version control" 
echo "done" 

echo "processing files to delete..."
svn status | grep "^!" | sed -r 's/^\![ ]+//' | xargs -r svn delete
echo "done"

echo "processing commit..."
svn commit --non-interactive -q -m "auto" || echo "Nelze commitnout"
svn up || echo "nelze aktualizovat"
echo "done"

[Heron]

Z toho důvodu ani nemůžu použít snapshotový FS, jelikož se chci obvykle vrátit u jednoho souboru a ne u všech.

To jsem moc nepochopil.

Osobně používám kombinaci rsync (pro úsporné přenášení dat ze síťových strojů) a následný btrfs snapshots. Výsledkem je, že mám k dispocici kompletní data ze všech serverů a to ve velmi úsporné formě na disku. Kdykoliv mohu vytáhnout jakýkoliv soubor z jakéhokoliv snapshotu.

Celá tato operace je tak rychlá, že ji mám v cronu každou hodinu (což je možná overkill, ale chtěl jsem trochu vyzkoušet i co btrfs zvádne).

Snapshoty se tváří jako adresáře (resp mountpointy), takže můžeš pro "vytažení" zálohy použít jakýkoliv protokol na soubory (scp, ftp, samba, nfs).

[Zopper]

Aha... je pravda, že po btrfs jsem moc nepátral, vycházel jsem ze zkušeností s virtuálními stroji, kde se mi nikdy nepovedl získat konkrétní soubor ze snapshotu. Pokud jdou u btrfs snapshoty připojit jako adresář, tak to je možná nejjednodušší řešení mých potřeb.

[Heron]

Snapshot virtuálního stroje je ale něco jiného, než snapshot btrfs. Snapshoty FS (btrfs, zfs) jsou skutečně na první pohled adresáře s (okamžitou) kopií dat v daném okamžiku pořízení snapshotu.

Navíc ty FS ukládájí jen změněné bloky, takže 1000 snapshotů 100GB souboru, který se nemění, nezabírá kromě metadat nic navíc. Pokud se mění, ukládají se pouze změněné bloky. Výsledkem je, že máš historii 1000 změn 100GB souboru třeba na 200GB disku (pokud těch změn nění více než 100GB).

Snapshot virtuálního disku (nebo třeba LVM) na druhou stranu neví nic o FS, tam si ukládá změněné bloky (bez další logiky) tak, jak by se zapsaly na disk. Takový snapshot lze obnovit pouze za asistence toho softu, který jej vytvořil.

[Max]

Dokud nebude pro brtfs nějaký fsck, tak do něj nejdu :-/.
Zadr Max

[Zopper]

Když se bude dělat pravidelná záloha dat na jiný FS, tak to snad tolik nevadí.

[Heron]

Jak to říkal Stalin?

Zálohovat, zálohovat, zálohovat!

Pravda, měl jsem taky obavy, občas mi to napíše nějakou chybu (což je dáno verzí jádra v debianu a netýká se dat, ale featur), ovšem zatím tyto nevýhody předčily výhody. Mirror mirroruje, snapshoty fungují. Ta data by se zálohovala tak jako tak, takže když se to sesype, tak se nic neděje.

U všech dat kontroluju hashe (to k vůli možnosti nějakého silent corruption) a zatím je vše ok.

Jako funguje to. Na produkci bych to nedal, na to to ještě připravené není, ale pro early testera je to ideální stav.

Nasadil jsem to ve chvíli, kdy jsem potřeboval pracovat s 300GB adresářovým stromem. Jakýkoliv verzovací systém nepřipadal v úvahu. SVN by to musel tahat po síti a navíc ve svém lokálním repositáři ty data má dvakrát (zabíralo by to lokálně 1TB + ještě na serveru), git si na tom úspěsně vylámal zuby už při importu. Nedalo se s tím rozumně pracovat (rozumněj revert k nějaké předchozí verzi). Tady si udělám snapshot kdykoliv potřebuji a mám všechny předchozí verze živé a dokonce zapisovatelné. Ideální, rychlé, úsporné.

[Zopper]

Tak jsem se podíval a nějaké fsck už *je*... http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg10864.html

[Kit]

Snapshoty mohou nahradit zálohování, ale verzování nenahradí. Záleží na konkrétních potřebách. Je možné, že tazateli budou snapshoty stačit, ale jinému vyhovovat nebudou.

Jak se takový systém zálohuje pro případ fyzické poruchy média? Je možné to efektivně provést se všemi snapshoty?

[Zopper]

V mém případě naštěstí snapshoty stačí, riziko, že při havárii disku ztratím snapshoty zrovna když je budu potřebovat sice nelze vyloučit, ale benefity v podobě snadnosti použití, či úspory místa (nemusím mít data na serveru dvakrát - jednou v SVN, jednou jako použitelná data pro přístup přes scp) převyšují riziko.

[Heron]

S prvím odstavcem nezbývá než souhlasit.

To druhé, upřímně, to jsem ještě neřešil. Určitě to půjde zálohovat stejně jako každý jiný FS - umount a dd. Podle featur na wiki by to mělo mít incremental backup celého fs, ale nenašel jsem na to příkaz. Asi ještě není implementovaný.

Otázkou je, proč řešit zálohování zálohovacího media (pokud by to mělo vystupovat v této roli). Zálohovací pásky také přece nezálohujete.

[Kit]

O BTRFS uvažuji jako o primárním úložišti dat se snapshoty. Proto se ptám na možnosti zálohování včetně snapshotů. Disk může fyzicky zhavarovat kdykoli. dd neuvažuji, partimage to ještě neumí. Snad už jen RAID 1.

[Heron]

Já mám v btrfs dva disky a fs vytvořený jako mirror. Zdá se, že to funguje. Otestováné to nemám, ale to pro tebe nebude problém otestovat ve virtuálce. Na mdadm mirroru to jde vytvořit samozřejmně také.

[Zopper]

Takže finální řešení je takovéto: přes Unison synchronizuji data ze všech PC se serverem á la hvězda (rsync se mi nepovedlo rozchodit na plnohodnotnou obousměrnou synchronizaci, unison přitom rsync algoritmy částečně využívá), kde jsou data uložena na btrfs oddíle a každou hodinu je vytvářen snapshot (pomocí tohoto skriptu - hodinové snapshoty jsou jen pro posledních 24 hodin, za posledních 7 dní zůstávají jen denní, pak týdenní a nakonec už jen měsíční).

Protože server obsahuje i jiná data, než jen synchronizované soubory/zálohy, běží ještě v cronu rsync, který vytváří kopii na druhém disku s jiným, než btrfs souborovým systémem.

K datům na serveru se mohu dostat i přes ssh (či jakkoliv jinak, díky unison nejsou uložena v nějaké databázi, ale jako normální soubory) a jakékoliv změny v nich se projeví i na synchronizovaných strojích. V případě potřeby bych mohl i rozchodit přístupnost jako síťový disk, ale zatím to nepotřebuji.

Pro moje potřeby je takovéto řešení zcela dostačující. Pokud by ale byla zapotřebí pořádná správa verzí (nešlo by o data jednoho uživatele na více strojích, ale více uživatelů na jednom projektu), určitě by bylo lepší sáhnout po svn, či zkusit git s nějakým rozšířením pro velké soubory.