Pár blbými příkazy jsem si poškodil hlavičku šifrovaného diskového oddílu a tím nenávratně přišel o 600 GB dat na něm uložených. Nebýt téměř přesné a asi dva dny staré zálohy celého oddílu na druhém disku, jejíž automatické provádění jsem před časem díky bohu/bohům nastavil s využitím nástroje Back in Time, bych asi právě procházel standardní pěticí fází truchlení podle Elisabeth Kübler-Rossové (popírání, hněv, smlouvání, deprese a smíření). Tak a teď o trochu podrobněji:
Jsem trochu paranoidní (ale fakt jenom trochu :-)). Používám šifrování prakticky veškerých svých dat na svých discích. Když vyšlo Ubuntu 12.04 LTS, definitivně jsem přemigroval z MS Windows na GNU/Linux jako svůj hlavní operační systém. Nějakou dobu jsem ještě data skladoval na Truecryptem šifrovaných NTFS oddílech, na které se dalo dostat z Windows i Linuxu, a nastavoval si složité symbolické odkazy z příslušných míst C:\Users\... na Windows a /home/... na Linuxu do sdíleného oddílu, kde jsem měl takové věci jako profil Thunderbirdu a dalších aplikací, a veškerá data. Když jsem po asi roce zjistil, že Windows už skoro vůbec nevyužívám, zrušil jsem postupně Truecrypt a NTFS a začal používat dm-crypt/LUKS a ext4 oddíly. Jen proto, že upgrade na Windows 8 Pro byl v době uvedení tak levný, jsem těch cca 800 korun Microsoftu někdy v tom lednu vysolil, odměnou je dobrý pocit z výhodného nákupu a ucpaných 40 GB tímto prima operačním systémem (na nejrychlější části disku tj. jeho začátku), který pro udržení formy nabootuju tak jednou za dva měsíce.
No ale teď konkrétněji k těm Linuxem šifrovaným diskovým oddílům. Historicky z doby, kdy jsem ještě měl 320 GB disk, jsem měl hlavní datový oddíl velký 250 GB. To držím dodnes, ačkoli už používám disk terabajtový. Vedle toho mám speciální oddíl pro /home/brozkeff, což je takový paskvil, ale vznikalo to organicky historicky a není to až taková tragédie. A s tím, jak jsem povýšil na terabajtový disk, vzniklo na jeho konci spousta místa, a to jsem ucpal velikánským datovým oddílem o velikosti cca 600 GB, pojmenovaným podle drobného chaosu, jež na něm panoval, „babylon“ a, jak asi už správně tušíte, právě o tento oddíl jsem pár blbými příkazy spuštěnými se sudo rootovskými právy přišel. Je to vlastně docela jednoduché, jak si navěky znemožnit přístup k obsahu LUKSem šifrovaného oddílu (varování, tohle nezkoušejte):
- zdá se vám že na souborovém systému je nějaká chyba, tak oddíl odpojíte (
sudo umount /dev/sdaX) - a následně spustíte kontrolu souborového systému (
sudo fsck.ext4 /dev/sdaX) - a tím jste navěky v prdeli.
Jak to, že šlo odpojit cryptoloop oddíl přes obyčejný umount s uvedením /dev/sdaX, namísto obvyklého /dev/mapper/blablabla? Může za to „featura“ fs-typu „crypt“, která poněkud skrývá přirozenost věcí, jak by možná pravil Hérakleitos :-) Při ručním připojování oddílu s LUKS můžeme postupovat tak, že zadáme sudo cryptsetup luksOpen /dev/sdaX blablabla, pak se zadá jedno z teoreticky až 8 hesel, a tím se objeví loop device /dev/mapper/blablabla, které lze standardně připojit, třeba sudo mount /dev/mapper/blablabla /media/blablabla (pokud tenhle adresář existuje). Způsob připojování oddílů přes pam_mount při přihlášení uživatele ale může udělat ten trik, že připojí oddíl nikoli tímhle dvoukrokovým způsobem, ale jediným příkazem mount s uvedením souborového systému "crypt". V případě využití hesla při loginu pro odemčení partition tak zpravidla stačí do /etc/security/pam_mount.conf.xml doplnit na správné místo něco jako
<volume user="brozkeff"
fstype="crypt"
path="/dev/disk/by-uuid/abcdefgh-ijkl-mnop-qrst-opqrstuvwxyz"
mountpoint="/media/blablabla" />
a ještě případně nastavit pár dalších drobností, které popisuje řada návodů, a mít samozřejmě aspoň na jednom z keyslotů stejné heslo jako to pro přihlášení. Výsledkem pak je automatické připojení takových oddílů po přihlášení bez nutnosti něco dalšího řešit. (Hodí se mít docela silné heslo a nepoužívat ho nikde jinde.)
(Odbočka: Ubuntu i Linux Mint, který z Ubuntu vychází, nabízí při instalaci možnost šifrování domovské složky — to ale využívá ecryptfs šifrování jednotlivých souborů a jejich názvů na běžném (ext4, btrfs…) oddílu, nikoli šifrování celého blokového zařízení. Ecryptfs je pohodlné, ale z mé zkušenosti dost pomalé.)
Využití jednokrokového mount.crypt /dev/sdaX namísto dvoukrokového cryptsetup luksOpen /dev/sdaX a pak mount /dev/mapper/blablabla ale maskuje skutečnost, že /dev/sdaX není obyčejný oddíl, ale šifrovaný. Výpis připojených oddílů (mount) nebo třeba zobrazení volného místa (df -h) v tom prvním případě alespoň v mém Mintu nedá o nějakém cryptoloopu vůbec znát, zatímco v tom druhém případě to je zjevné aspoň tím, že to, co je připojené, je něco v /dev/mapper. Takže teď když jsem nechal vypsat mount, tak moje šifrovaná /home/brozkeff vypadá ve výpisu takhle:
/dev/sdaX on /home/brozkeff type crypt (rw)
zatímco LUKS oddíl připojený nikoliv automaticky při přihlášení přes mount.crypt, ale přes kliknutí na něj v grafickém správci souborů (caja, nautilus ap.) je připojený následovně
/dev/mapper/udisks-luks-uuid-abcdefgh-ijkl-mnop-qrst-opqrstuvwxyz-uid1000 on /media/blablabla type ext4 (rw,nosuid,nodev,uhelper=udisks)
Jelikož vím, že jde vlastně o oddíl nacházející se na /dev/sdb1, při připojení příkazem mount.crypt /dev/sdb1 /media/blablabla bych pak zobrazením připojených oddílů dostal odpověď analogickou tomu prvnímu příkladu z /home/brozkeff,
/dev/sdb1 on /media/blablabla type crypt (rw)
A zatímco příkaz mount nám ukáže ten typ – buďto ext4, nebo crypt, příkaz df -h nám jen hezky zobrazí zdroj a mountpoint a volné místo, ale o typu tiše mlčí.
Čímž se konečně se dostáváme k tomu, jak jsem si poškodil hlavičku LUKS oddílu, která pokud si ji uživatel někdy dřív nevyzálohuje (cryptsetup luksHeaderBackup --header-backup-file hlavička.img /dev/sdaX), tak třeba příkazem sudo fsck.ext4 /dev/sdaX o ni definitivně přijde resp. se bez varování poškodí něco v master klíči se solí, že to je konečná a zadávané heslo se zdánlivě neshoduje s žádným keyslotem. Na rozdíl od Truecryptu, který pokud si pamatuji, má i záložní klíč s jinou solí na konci šifrovaného oddílu/kontejneru, LUKS nic takového nevede a bez zálohovaného klíče se k datům dostat prostě nedá.
Back in Time
Takže teď chvála toho programu.
Je to něco jako Time Machine na Apple OS X. Jednoduché, pohodlné, funkční. Využívá funkcionality hardlinků na unixových souborových systémech a rsync. Z bodu A kopíruje všechno na místo B ve zvoleném intervalu a to tak, že se pokaždé vytváří nový obraz bodu A s možností si kdykoli snadno zobrazit libovolný dřívější stav. Vše, co zůstalo odminula stejné, se jen na sebe odkáže pomocí hardlinků, takže to nezabírá skoro žádné místo. Zbytek se normálně nakopíruje. Smazáním kteréhokoli staršího obrazu (snapshotu) zůstávají všechny ostatní obrazy plně funkční. Dokud na má hardlinkovaný soubor aspoň jediný ukazatel, je naživu, „smaže“ se až odstraněním posledního odkazu. (Time Machine na Macu to má ještě lepší, protože může dělat i hardlinky celých adresářů, nikoli individuálních souborů, což samozřejmě šetří další místo – vyžaduje to ale podporovaný souborový systém). Frekvenci zálohování si program nastavuje přes cron a není potřeba nijak znát syntaxi cronu.
Můj zálohovací model je asi takovýto: V notebooku mám trvale 1TB disk, kde je v podstatě všechno. V šachtě na optickou mechaniku nosím normální DVD mechaniku, která je ale zmáčknutím magického tlačítka vytažitelná za chodu. Když přijdu domů, vytáhnu tímto způsobem DVD mechaniku, do díry strčím mediabay, ve kterém je druhý 1TB disk, který se pokud se znovu přihlašuji, připojí jako další oddíl, a jakmile je tento oddíl připojen a Back in time zjistí, že cíl pro zálohy už je dostupný, při nejbližší příležitosti provede nový snapshot (pokud se tedy vůbec nějak liší od toho předešlého).
Stejně by to samozřejmě šlo dělat i s eSATA nebo USB diskem bez nutnosti vytahovat optickou mechaniku (resp. na Linuxu při použití UUID je to úplně jedno, když chci zálohovat i pracovat s DVD, přehodím disk z baye na eSATA kabel nebo do USB rámečku. Jelikož ale nemám dokovací stanici, kde bych měl záložní disk trvale zapíchlý, preferuji zasunutí baye před neustálým zastrkávánm eSATA kabelu, což jde docela ztuha a mám u toho vždycky pocit, že ještě takhle ten konektor zasunu a vysunu dvakrát a něco se v tom portu vyvaklá a rozbije ;-) Nevýhodou baye je zase snadnost s jakou lze zapomenout záložní disk v notebooku před jeho cestováním za hranici bytu, což je poněkud riskantní věc, pokud by třeba takový notebook někdo ukradl (spolu s třeba jedinou zálohou), nebo spadl za chodu a zem a rozbily se oba disky, atp.
No a to je v podstatě všechno, co jsem chtěl říct. Time Machine s AirPort Time Capsule je samozřejmě ještě o kus pohodlnějším řešením, ale taky dražším (nejen za tu kapsuli, ale za ten Mac ;-)). Rsync lze z Linuxu i Windows dělat na skoro jakýkoli jiný NAS, ale každý NAS stojí něco navíc oproti obyčejnému USB disku. Své místo mají samozřejmě i cloudová úložiště, RAID pole a všechny další způsoby ochrany. Více mechanismů se dá různě kombinovat a vzájemně jistit…
Běžný uživatel, kterému stačí 500GB disk, je schopen výše uvedené řešení realizovat za cenu kolem tisícovky za ten druhý USB (3.0) 500GB disk pro zálohu. Kdo potřebuje terabajt jako já, má to o trochu dražší. Dva terabajty pořád ještě jdou i v notebooku, pokud je v bayi druhý terabajtový disk a oba dohromady jsou zálohované třeba na dvouterabajtový externí 3,5“ disk. Víc než 2 TB si dnes (11/2013) zatím moc v notebooku nedovedu představit, ale asi je to zase jen otázkou času :-)
