Dotaz: Zálohovadlo, které šifruje u mě

[Jendа]

Ahoj,

mám na vzdáleném stroji shell účet a hodně místa. Chtěl bych si tam zálohovat. Normálně bych si tam vytvořil velký prázdný soubor, naformátoval cryptsetupem, vyrobil ext2 a rsyncoval, jenže se bojím, že tam binárku cryptsetupu někdo upraví, aby ukládala klíče.

Takže požadavky:

• Šifrování na mém počítači; odesílání již zašifrovaných souborů
• Inkrementální zálohování bez historie
• Zotavení se z přerušeného spojení (jako rsync)

Díval jsem se už na duplicity, ale bojím se, že to není to, co chci - vyrobí obrovský tar, ten zašifruje a nahraje a pak dělá přírůstkové tary. Já chci fakt jenom aktuální kopii (i z důvodu velikosti).

Nějaké nápady?

Dík

Odpovědi

[Bilbo]

Co takhle adresar s tim souborem vyexportovat treba pres NFS a ten soubor pak z lokalu mountnout pres cryptsetup? Data pres sit by sla uz sifrovana, sifrovani/desifrovani by se nedelo na serveru, tam by jen prichazely a odchazely sifrovane bloky z/do velkeho souboru.

Cili lokalne by pribyl dalsi disk, na ktery je mozne tlacit zalohy (rsync?) dle libosti.

Akorat nevim jak moc je tohle odolne vuci rozpojeni spojeni (mozna by se to muselo cele unmoutnout a znovu remountout....), nezkousel jsem to.

[Jendа]

To jsem zkoušel (konkrétně přes sshfs) a jenom vytvoření ext2 v tom vyexportovaném souboru trvalo půl hodiny (22GB, 1Mbps upload). S rsyncem by to bylo úplně nepoužitelné, protože jen při inicializaci přenosu si z FS tahá data změny všech souborů a když počítá rozdíly mezi soubory, pochopitelně ten celý soubor taky potřebuje.

[Filip Jirsák]

To tedy znamená, že nechcete aby se při zálohování tahalo vše po síti zase zpět na váš PC. Pak máte jedinou možnost – soubory k zálohování určit jen na základě lokální kopie, bez údajů ze zálohy. Tedy např. pomocí data modifikace. Takové soubory vám dokáže vyhledat i find, pak už zbývá jen soubory zabalit, spakovat, zašifrovat a odeslat.

Pokud byste chtěl dělat skutečně inkrementální zálohy (rozdíly), musíte vždy buď stáhnout zálohu zpět na lokální počítač, rozšifrovat a porovnávat s ní, nebo poskytnout vzdálené straně klíč, aby mohla zálohu rozšifrovat ona (pak už stačí přes síť přenášet jen hashe). Teoreticky by bylo možné hashe zálohovaných bloků si uchovat v nešifrované podobě (ať už na vzdálené straně, nebo lokálně), ale to byste si musel nejspíš napsat vlastní zálohovací software, protože externalizovat hashování podle mne žádný zálohovací software neumí. Ono by asi stačilo jenom implementovat protokol rsync, kde by se hashe nepočítaly ze souborů na disku, ale použily se ty zapamatované.

[Jendа]

Tedy např. pomocí data modifikace. Takové soubory vám dokáže vyhledat i find, pak už zbývá jen soubory zabalit, spakovat, zašifrovat a odeslat.

Jo, myslel jsem, že by si ten zálohovací software zapamatoval, kdy byla provedena záloha, a příště zašifroval a odeslal všechny novější soubory. Asi si budu muset napsat nějaký skriptík. Co byste mi doporučili pro to šifrování? GnuPG, openssl, něco jiného?

[Filip Jirsák]

Jo, myslel jsem, že by si ten zálohovací software zapamatoval, kdy byla provedena záloha, a příště zašifroval a odeslal všechny novější soubory.

Podle mne je nejlepší na začátku si udělat timestamp (touch na nějaký soubor) a pak porovnávat soubory pomocí find -anewer, -cnewer nebo -newer. Jenom je potřeba před vytvořením timestampu si ten původní zazálohovat a porovnávat vůči němu

Co byste mi doporučili pro to šifrování? GnuPG, openssl, něco jiného?

Nevím, pokud máte s něčím zkušenosti, použijte to, jinak bych zkusil udělat nějaký test rychlosti obou variant, případně s čím se bude lépe pracovat…

[pht]

Inkrementální zálohy jsou o ničem, tohle bych řešil klasicky tar + gzip + gpg.

[Bilbo]

U mne z tar + gzip vypadne asi tak 5-6 GB, coz je na kazdodenni nahravani nekam na server precejen trosicku moc (nehlede na to, ze takovahle zaloha se vyrabi cca pul hodiny)

Mozna pomoci findu vytvorit seznam novych/nove zmenenych souboru, ten pak nacpat nejakemu archiveru (p7zip?), aplikovat gpg a poslat na server

[dustin]

Tar umí také jen soubory od určitého data (parametr  --newer-mtime), používá to např. backuppc. Inkrementální záloha na velkých adresářových stromech je pak mnohem rychlejší než rsync.

[Jendа]

No jo, ale to pořád neřeší, že tam jednou nahraju 10GB tar (full-backup) a pak tam každý den přibude 50MB tar... A ten full-tar nebudu moct nikdy smazat a žádné ty inkrementální taky ne...

[Filip Jirsák]

Normálně se inkrementální zálohy dělají jen v mezidobí mezi plnými zálohami – tedy např. děláte týdenní plné zálohy a mezi tím děláte denní inkrementální zálohy. Pro zjednodušení obnovy a redundanci záloh jde také dělat inkrementální zálohy vůči předchozí plné záloze. Uchovává se pak několik plných záloh zpět – když si někdo za měsíc vzpomene, že si smazal nějaký soubor, aby bylo odkud jej obnovit.

[pht]

A až Vám to jednou doma klekne tak se z toho skládání inkrementálů po.

[dustin]

Od toho jsou zálohovací nástroje, které z inkrementálních záloh vždy pomocí hardlinků vytváří plné snapshoty.

[iji]

duplicity ma volbu pro pocet starsich zaloh (jak pocet, tak cas), ktere se maji zachovat.

[mkmm]

A co udelat ten sifrovany image u sebe, zalohovat do nej a pak ho rsyncovat?

[Jendа]

Dobrej nápad. Těch pár giga místa bych na to i obětoval. Ale zase to během zálohování bude v nekonzistentním stavu - když se zálohuje na úrovni souborů, dá se přijít pár souborů, tady bych se bál. LUKS je celkem v pohodě (nekonzistentní blok(y) prostě nerozšifruje), ale je otázka, co to udělá s ext2...

Pokud znáte nějaký odolný FS (FAT?), budu rád

[mkmm]

Toho bych se nebal, po skonceni to bude zase konzistentni. V podstate se to nelisi od fyzickeho sifrovaneho disku. Mam sifrovane oddily s ext3 a kdyz mi to spadlo, tak se to normalne opravilo pomoci fsck.

[biolog]

Po skončení konzistentní opravdu bude, ale skončení nemusí nastat - když klient stihne nahrát jen část (image na serveru se znekonzistentní) a pak mu odejde disk.

[Filip Jirsák]

To je ale to samé, jako pokaždé přenášet kompletní zálohu. Zašifrováním je potřeba dostat co nejvíce náhodnou posloupnost bitů, takže jestli vám rsync najde na staré a nové záloze nějaké stejné bloky, ten šifrovací program rovnou zahoďte.

[Jendа]

dm-crypt při každém zápisu přešifruje jenom ty bloky, do kterých se zapisovalo a zbytek nechá.

[Filip Jirsák]

Aha, ono je myšleno šifrování souborového systému, tedy šifrování po blocích. To takhle musí fungovat, ale nejsem si jist, jak je to pak s bezpečností takového šifrování.

[Jendа]

No ono by jinak ani disky šifrovat nešlo. Nedokážu si představit, že by se při změně jednoho souboru přešifrovával 100GB filesystém.

A bezpečnost? Nejsem kryptolog, ale tady je na to seminárka a vypadá to, že když se zvolí rozumný mód, tak to se současnými zveřejněnými znalostni prolomit nejde.

[Jendа]

Soubor se 100MB náhodných dat jsem naformátovat cryptsetupem (AES-XTS-PLAIN). Potom jsem v něm vyrobil vfat. Zapsal jsem 97 souborů po 1MB:

for i in `seq 1 97`; do dd if=/dev/urandom of=${i}.bin bs=1M count=1; done

Odpojil jsem a provedl jsem rsync.

Znovu jsem vše připojil a provedl 10MB změn:

rm 6?.bin
for i in `seq 60 69`; do dd if=/dev/urandom of=${i}.bin bs=1M count=1; done

Odpojil jsem a provedl rsync s parametrem -P.

sent 10544457 bytes  received 71711 bytes  1930212.36 bytes/sec
total size is 104857600  speedup is 9.88

To je dobrý výsledek...

[xkucf03]

A co použít EncFS? Takhle:

server – sshfs – EncFS – rsync – tvoje data

[Jendа]

Hezké. Teď jsem to vyzkoušel a asi to tak udělám. Rsync budu spouštět s --whole-file.

[Jendа]

Tohle vypadá, že funguje. Už se to tam tlačí. Kdyby spadla na Prahu atomovka, data budou zachována! Hurá! (zatím jsem zálohoval jenom na disky kolem sebe )

#!/bin/sh
sshfs -p 4011 user@stroj:/kam/ /mnt/někam/

encfs /mnt/někam/enc /mnt/někam/open

rsync --whole-file --delete --progress -z --compress-level=9 -av co /mnt/někam/

sync

fusermount -u /mnt/někam/open

fusermount -u /mnt/někam

[xkucf03]

a neměl bys zálohovat spíš do /mnt/někam/open ?

[Jendа]

Jo, ve skriptu to mám dobře, když jsem to sem vkládal a přepisoval cesty, tak jsem přepsal i to open.

[Jendа]

Právě jsem dojel Zkusím patchnout a zkompilovat ten rsync...

[Semo]

dar - mala by to byt ako evolucia taru (Disk ARchiver namiesto Tape ARchiveru). Myslim, ze by presne vyhovoval. Dokaze robit rozdielove zalohy, sifruje uz hned pri vytvarani zalohy. Ta najlepsia finta je ta, ze dokaze vyrobit iba archiv metadat (casy modifikacii, hashe a neviem co este pouziva na detekovanie, ci sa subor od minula zmenil a cele to ma len par desiatok MB) a tento archiv mozes mat lokalne a skutocny archiv aj so samotnymi datami mas ulozeny vzdialene.

Mimo tvojho pocitaca existuju iba zbalene a zasifrovane subory a pritom nemusis pri vyrabani zoznamu suborov zmenenych od minula a urcenych teda k zahovaniu byt pripojeny vobec k sieti. Len na konci prenesies vyrobeny zasifrovany subor.

Vyzera, ze uz existuje, je vyvijane a udrziavane dostatocne dlho, aby tomu clovek zveril data.