Se snapshoty je možné rámci exportu a importu (nebo by bylo možná lepší definovat to jako odeslání a příjem) manipulovat pomocí příkazů send a recv. Je tak možné snapshot odeslat a přijmout na jiném poolu toho samého nebo jiného stroje či vzdáleného úložiště.. V rámci jednoho stroje a poolu je možné snapshot odeslat do souboru. Tuto operaci budu dále nazývat exportem snapshotu. Export bude také náš případ z dalšího důležitého důvodu – exportované soubory poolu se budou zálohovat na externí úložiště. Více o popsané manipulaci se snapshoty je možné zjistit např. na docs.oracle.com.
Pokud by se zvolil nejjednodušší způsob exportu snapshotu do souboru, vypadal by příkaz např. takto:
# sudo zfs send
tank1/usr/home/vojtaj@2013-06-19 > /zalohy/snaps/snap.`date
+%Y-%m-%d`
Vznikne tak soubor příslušného názvu a velikosti 14 359 MB. Na výpisu ze systému se ale ukáže trochu něco jiného:
# zfs list NAME USED AVAIL REFER MOUNTPOINT tank1/zalohy 11,9G 803G 209K legacy tank1/zalohy/backup 209K 803G 209K /zalohy/backup tank1/zalohy/snaps 11,9G 803G 11,9G /zalohy/snaps
Pokud bychom si chtěli ověřit úspěšnost komprimace, tak je výsledek následující:
# sudo zfs get compressratio tank1/zalohy/snaps NAME PROPERTY VALUE SOURCE tank1/zalohy/snaps compressratio 1.18x -
Vzhledem k tomu, že se soubory s exportovanými snapshoty budou kopírovat na externí úložiště, je možné zvolit ještě jednu variantu a přímo je komprimovat. Tato operace je samozřejmě znatelně pomalejší než předchozí, ale má určitě svoje výhody:
# sudo
zfs send tank1/usr/home/vojtaj@2013-06-19 | bzip2 >
/zalohy/snaps/snap-`date +%Y-%m-%d`.bz2
Výsledná velikost souboru je 9 574 MB:
# zfs list NAME USED AVAIL REFER MOUNTPOINT tank1/zalohy 9,35G 806G 209K legacy tank1/zalohy/backup 209K 806G 209K /zalohy/backup tank1/zalohy/snaps 9,35G 806G 9,35G /zalohy/snaps # sudo zfs get compressratio tank1/zalohy/snaps NAME PROPERTY VALUE SOURCE tank1/zalohy/snaps compressratio 1.00x
Zálohy pomocí snapshotů HOME se budou provádět jednou týdně. Při této operaci je nutné brát v úvahu, že scrubbing a export snapshotu do komprimovaného souboru může trvat i několik hodin a samozřejmě velmi značně zatěžuje diskový systém. Je proto velmi vhodné operaci startovat v době, kdy se na stroji právě nepracuje.
Zatím nemám v plánu tuto část zálohy nějak automatizovat. Nebylo by to asi moc přínosné vzhledem k tomu, co bylo popsáno výše.
Kopírování souborů se snapshoty je pak už samo o sobě jednoduché a vzhledem k jejich velikosti docela rychlé.
Pro usnadnění práce v této oblasti zálohování jsem udělal dvě opatření: některá uživatelská data jsem přesunul mimo domovský adresář (upřesním v části o zálohách uživatelských dat) a pro operaci vytvoření a exportu snapshotu jsem vytvořil jednoduchý skript – viz soubor snapback.txt.
Zálohování uživatelských dat – interní
Pro zálohy uživatelských dat se bude využívat běžně dostupných aplikací, které jsou k tomuto účelu vhodné a dostupné přes balíčkovací systém. Jistě nemusím připomínat, že je k dispozici celá škála nástrojů od těch velmi rozsáhlých a sofistikovaných (Bacula, AMANDA apod.) až po ty velmi primitivní (cp, tar atd.).
Myslím si, že na jednom desktopu nemá smysl žádné „těžké“ řešení instalovat a používat. I tak je nabídka možností pořád dostatečně pestrá a každý si může vybrat. Abych to příliš nerozvíjel, tak jenom uvedu, že jsem zvolil dva typy záloh. Jedna ukládá komprimované rozdílové (podle časových rozmezí i úplné) zálohy vybraných uživatelských adresářů. Druhá provádí synchronizaci, nebo chcete-li, zrcadlení vybraných adresářů.
Pro každý z těchto typů vytvoříme příslušný dataset a nastavíme mu komprimaci:
# sudo zfs create -o mountpoint=/zalohy/backup/history tank1/zalohy/backup/history # sudo zfs create -o mountpoint=/zalohy/backup/mirror tank1/zalohy/backup/mirror # sudo zfs set compression=on tank1/zalohy/backup/history # sudo zfs set compression=on tank1/zalohy/backup/mirror
Pro oba datasety se provede změna vlastníka na běžného uživatele, který spouští zálohovací operace.
Je asi zřejmé, že pro každý typ zálohy bude nutné použít jinou aplikaci. Já jsem konkrétně pro rozdílové zálohy vybral duplicity a pro synchronizaci unison (tedy konkrétně balík unison-nox11). K dispozici jsou verze 2.40.102 a devel 2.45.28. Při synchronizaci v rámci jednoho stroje není verzování žádný problém. Pokud by ale bylo vaším cílem to provádět na jiný stroj, je nutné na obou použít přesně stejnou verzi unisonu!
Pro rozdílové zálohy jsem vytvořil jednoduchý skript, který je založen na možnostech duplicity a provádí zálohu vybraných adresářů. Jeden příklad za všechny:
# duplicity –no-encryption --full-if-older-than=7D /usr/home/vojtaj/Projekty file:///zalohy/backup/history/projekty >> /usr/home/vojtaj/.Duplicity/Projekty.log
Velký popis asi není třeba, takže letecky: žádné šifrování, pokud je poslední full záloha starší 7 dnů, udělá se full, jinak increment, zálohovaný adresář, záložní dataset, soubor, do kterého se ukládají logy – viz přílohu Projekty.log.
Pokud se instaluje a spustí aplikace unison, tak se vytvoří adresář $HOME/.unison. V něm je nebo se musí vytvořit soubor s příponou *.prf. Já tam mám konkrétně default.prf s tímto obsahem:
# Unison preferences file # Root directory root=/usr/home/vojtaj/ root=/zalohy/backup/mirror/ # Dirs path=Apps path=Develop path=Dokumenty path=Projekty path=.mozilla path=.thunderbird batch=true group=true owner=true
Zase jenom krátký popis: synchronizované „domovské“ adresáře, synchronizované konkrétní adresáře (relativně k domovským), nastavení – na nic se neptat, zachovat původní vlastníky a skupiny souborů a adresářů.
Synchronizace se pak spustí příkazem
# unison default.prf
Výpis v terminálu je při běhu aplikace poměrně obsáhlý – ukázka je v příloze unison.txt. Kdo by chtěl třeba ukládat výpisy do souboru, může použít další nastavení:
silent=true – vypisují se pouze chyby
Při každém běhu se také automaticky doplňují záznamy do souboru $HOME/unison.log. Příklad jeho obsahu obsahuje stejnojmenná příloha unison.log. V adresáři $HOME/.unison se při každém běhu aktualizují čtyři soubory s velmi „podivnými“ názvy… Uvedu zde pouze jejich hlavičky, které trochu objasní jejich účel a obsah:
Unison archive format 22 Archive for root //pcbsd-6584//zalohy/backup/mirror synchronizing roots //pcbsd-6584//usr/home/vojtaj, //pcbsd-6584//zalohy/backup/mirror Written at 2013-07-02 at 14:53:47 - case sensitive mode Unison archive format 22 Archive for root //pcbsd-6584//usr/home/vojtaj synchronizing roots //pcbsd-6584//usr/home/vojtaj, //pcbsd-6584//zalohy/backup/mirror Written at 2013-07-02 at 14:53:47 - case sensitive mode Unison fingerprint cache format 2 Unison fingerprint cache format 2
Jak jsem se již zmínil v předchozím odstavci, provedl jsem některé úpravy domovského adresáře a některé adresáře a soubory přemístil mimo něj. Jedná se hlavně o takové adresáře, jejichž obsah se příliš často nemění – fotografie a obrázky, hudební kolekce, veškeré instalační soubory včetně ISO obrazů a soubory virtuálních strojů. Tyto adresáře jsou umístěné do zvláštního adresáře, který se zálohuje na externí úložiště podle potřeby a v návaznosti na případné občasné změny. Tím se poměrně dramaticky zmenšila velikost HOME a samozřejmě i exportovaný soubor snapshotu. U těchto adresářů není také nutné provádět pravidelné zálohování ani zrcadlení.
Zálohy a zrcadlení uživatelských adresářů zatím probíhají v jednoduchém „automatickém“ režimu. Oba skripty se spouštějí při startu LXDE. V případě zrcadlení je prodleva při startu minimální. U zálohy záleží na tom, jestli probíhá pouze inkrementální (to trvá velmi krátce), a nebo full. Ta je potom samozřejmě mnohem delší.
Do budoucna bych chtěl v tomto režimu ponechat pouze zrcadlení pomocí aplikace unison.
Vytváření inkrementálních záloh bych chtěl rozšířit jednak směrem k častějšímu provádění (na při startu systému, ale v průběhu dne 2–4×) a také k lepší automatizaci.
Automatické provádění úloh je v PC-BSD možné dvojím způsobem. K dispozici je samozřejmě obvyklá aplikace cron (či anacron) a crontab pro běžného uživatele nebo roota.
Kromě toho je k dispozici ještě systém periodic, který je určen k provádění shellových skriptů.
V posledním díle o zálohování se budu trochu podrobněji věnovat možnostem využití systémů cron a periodic a také se zaměřím na zálohování jailů.
ČLÁNKY DO MAILU