Távoli titkosított mentés?

Segédprogramok

Backup megoldást keresek duplicity helyett, amely távoli nem megbízható szerverre tud úgy titkosítva menteni, hogy a titkosítás a kliens oldalon történik, és a távoli szerveren soha nincs jelen a jelszó, kulcs vagy az adat kibontva. Cél: saját helyi gépemen bizonyos mappák szinkronizálása a szerveremre, amihez teljes hozzáférésem van (SSH vagy más protokoll). De nem lenne baj ha idegen tárhelyre is megoldott lenne.

Duplicity-t használtam, de megint egy bugos verzióba futottam bele. Régebben is állandó problémám volt vele, most végleg leteszek róla. RHEL 6 vonal nem szállít gyárilag semmi használható megoldást, ezen nem is lepődök meg, ez semmilyen operációs rendszeren nem volt még megoldva soha normálisan.

Teszteltem EncFS + SSHFS + Rsync-et úgy, hogy a távoli szerverem egyik mappáját felcsatolom helybe, majd ezt tovább csatolom EncFS-el egy másikba, és ebbe Rsync-elek. Sajnos nagyon lassú a sok kis fájlnál, és semmilyen performance tuning sem segít csökkenteni a latency-t. Ugyanezt kipróbáltam SSHFS helyett NFS-el + SSH port forwarddal - közel ugyanaz lett az eredmény. Igazából itt látható, hogy az SSH tunelen keresztüli fájlműveletek a szűk keresztmetszet, és ez felett mindegy milyen protokollt használok. Habár itt az lett volna jó, hogy az EncFS-el a titkosítás teljesen helyben zajlik, és a távoli szerverre mindig csak titkosított fájlok kerülnek fel, és a fájl szintű titkosítás miatt szinkronizálni is hatékony lett volna.

EL 6 szállítja Amanda-t, de persze nem tud titkosítást. Rsnapshot szintén, rdiff-backup szintén.

Annyi elég lenne, ha Rsync-nek a fájlokat a hozzáférés előtt valahogy át lehetne folyatni egy EncFS szerű megoldáson, ami fordítva működik: a helyi nem titkosított fájlokból látnék csak titkosítottat, és arra futtatnám az Rsync-et. Egyelőre nem találok semmi használhatót. Persze jobb lenne open source, és ráadásul rendesen kitesztelt megoldás, mégis csak backup-ról van szó.

Megfordult a felyemben, hogy vajon érdemes lenne-e lefejleszteni egy keveset tudó, butácska backup script-et (pl. tiszta Python kódban, mert azt szállítja az OS), de most megint sajátot fejleszteni egy ilyen régóta meglévő alap igényre? Még ha le is lenne fejlesztve, ott van a tesztelés kérdése. Ha már szinkronizál meg titkosítás is játszik, már sokkal bonyolultabb a dolog, minthogy házilag megfelő mértékben tesztelni lehessen mint egy egy soros megoldást.

Miért nem tud alapból az OS a fenti követelményeknek megfelelő backup-ot csinálni? Tudnátok használható megoldást ajánlani?

Truecrypt image-be tolni az adatokat, majd az image fájlt szinkelve nem egészen megfelelő, mert ott kell egy extra másolatot tartani az adatokból. Viszont így EncFS-el is meg tudnám csinálni - vagyis helyileg szinkelném egy másik mappába, és a titkosított verzióra nyomnék Rsync-ket - de itt is duplán kellene adatokat tartani - hely meg nincs erre a helyi gépen elég.

Egyéb ötletek kész megoldásokra? Vagy szerintetek érdemes lenne lefejleszteni egy apró script-et a bughalmaz duplicity-hez helyett? (Szerk.: mindezt úgy, hogy a megbízhatóság érdekében alacsony szinten tartani a kód méretet és a funkciók számát - és persze kész lib-eket használni az SSH-hoz és GnuPG-hez)

  • 11258 megtekintés

( cvk v | 2012. 12. 31., h – 10:40 )

Szia!

Ha már lementetted a fájlokat és generáltál magadnak gpg kulcspárt, azzal titkosíthatod és aláírhatod azokat:

for fajlok in `ls /mentesek/*.gz`; do
echo titkositas $fajlok
gpg --passphrase-file /$USER/mentes-jelszo -es -r gpg-mail@ cim.hu $fajlok
scp $fajlok.gpg nev@ tavoliszerver.hu:/backup/
rm $fajlok.gpg
done

( gergov | 2012. 12. 31., h – 10:54 )

Most lehet en emlekszem rosszul, de ha nem, akkor meglep, hogy nem vetted eszre, hogy az encfs tud forditott modban is mukodni. Nezz utana a --reverse kapcsolonak, szerintem az pont azt tudja, amit te akarsz.

Uhh, ha ez így van, akkor nagy köszönet! :) Most megnézem...

Amúgy meg még az obnam-ot kezdtem el nézegetni, van ezzel valakinek tapasztalata esetleg?

Szerk.: ez kell nekem (EncFS --reverse), érvényes a RTFM!

Köszi!

Akkor ezek szerint a megoldás egyetlen helyi mappa felcsatolás EncFS-el fordított módban, majd mehet is az rsync SSH-n keresztül!

Leírnád (linux kezdő szinten), hogy mi lett a végső megoldás?
Ilyenre gondoltam:

- fstabban az alábbi módon csatolod encfs-el a távoli gép backup könyvtárát.
- az alábbi cron bejegyzéssel fut az rsync (vagy bármilyen script, bármilyen ütemezési móddal)
- az rsync a következő paraméterekkel (vagy a script, ami a mentést végzi)

Köszönjük. :) 

openSUSE 12.2, vagy ami éppen jön.

Leblogolom majd szerintem a végső megoldásomat. Amúgy meg kb: 


# add user to fuse group + relogin + modprobe fuse
encfs --reverse /home/user /tmp/dir
rsync -av --progress /tmp/dir/ user@szerver:backup/
fusermount -u /tmp/d

Cron-t meg egyebet már egyszerű beállítani. Most még azon gondolkodok, hogy van-e lehetőség ezzel a megoldással bizonyos könyvtárak kizárására, és ha igen, akkor hogyan. Nyilván több EncFS felcsatolást nem szeretnék. Ezt még majd megírom mire jutok.

Symlinkelésen gondolkodok..

De ugye már titkosított fájl neveket látok az encfs felcsatolás másik oldalán. Tehát titkosított neveket kellene megadnom, ami viszont nem látszik hogy melyik, meg nem is kideríthető (maximum a mappa fájlainak számából meg fájl méretekből lehetne trükközni).

Úgy látom symlink-ek nem működnek egyelőre.

Úgy látszik igen: 


mkdir /tmp/d
encfs --reverse /home/user/fonts /tmp/d
ls -lkSr /home/user/fonts/ /tmp/d/
/tmp/d/:
total 273248
-rw-rw-r--. 1 andras andras      2 Dec 31 11:40 u7p0iW8RUMUjz9MLCON9SDGe
-rw-------. 1 andras andras    103 Nov 23  2007 Ul1SFymZMych5zfFoOFEV50j3ExBWnoIhvQrSsFIIipnB,
-rw-------. 1 andras andras    430 Sep 26  2007 GgG6H1t13yICqxUNLTnWmOXjMfJaW,iU3pEHlXxqdP5vi-
-rw-------. 1 andras andras  10265 Jul  5  2008 J84ROMvK4HFwf2HPqXTPMsWLXHJm8V376GNwIJf7o7tZw-
-rw-------. 1 andras andras  34951 Jul  5  2008 LhUor4e6tDGFhVKQ2BLnteb1R2kZNtTIAPcSCP74Oa572,
-rw-------. 1 andras andras  37401 Mar 31  2008 uLDuuETVx41xdSKAElMtzUGjPab0H3d2njU0r,WwFZE5-,
-rwx------. 1 andras andras 190082 May 11  2007 EqWdO2RuAypQTdsLnG51FhYl9adovu0M6Xw,fpcs0VssW0

/home/andras/fonts/:
total 273244
-rw-------. 1 andras andras    103 Nov 23  2007 AvantGardeITCbyBT-Book-hun.zip
-rw-------. 1 andras andras    430 Sep 26  2007 Garamond_font.zip
-rw-------. 1 andras andras  10265 Jul  5  2008 huni_fontok.tar.gz
-rw-------. 1 andras andras  34951 Jul  5  2008 unicode_fonts.tar.gz
-rw-------. 1 andras andras  37401 Mar 31  2008 linux_system_fonts.tar.gz
-rwx------. 1 andras andras 190082 May 11  2007 win_system_fonts.zip

A végén rányomni szerver oldalon egy rekurzív touch-ot

Ezután jó eséllyel nem lesz képes restore-kor sem a timestamp-ek visszaállítására...

az rsync meg méret vagy chksum alapján szinkelne

Nem ez a probléma. A probléma az, hogy az 

encfs --reverse

repo formátuma információt szivárogtat a távoli szerveren.

Példa: 


$ ls -l /usr/bin/zip*

-rwxr-xr-x. 1 root root 216008 2010-05-24 16:23:44 +0200 /usr/bin/zip
-rwxr-xr-x. 1 root root 110376 2010-05-24 16:23:44 +0200 /usr/bin/zipcloak
-rwxr-xr-x. 1 root root   2953 2008-10-10 19:40:36 +0200 /usr/bin/zipgrep
-rwxr-xr-x. 2 root root 164128 2010-05-25 17:19:16 +0200 /usr/bin/zipinfo
-rwxr-xr-x. 1 root root 101856 2010-05-24 16:23:44 +0200 /usr/bin/zipnote
-rwxr-xr-x. 1 root root 105280 2010-05-24 16:23:44 +0200 /usr/bin/zipsplit

Fogd a három utolsó állomány méretét (164128 101856 105280) és indíts velük (együttesen megadva) egy google keresést. Nálam a nyolcadik találat tartalmazza a fenti file-ok neveit.

Attól függ, mi a cél. Ha csak a zasszony elől akarod eldugni a pornógyűjteményed (mert csupa szőke csajok vannak benne, közben ő meg barna hajú), tökéletesen megfelel. Ha a rendőr elől akarsz eldugni valamit, amiről ráadásul azt is akarod állítani, hogy egyáltalán nem is létezik, akkor viszont kínos.
Én sajnos nem vagyok jártas kriptográfiában, de érdekelne, hogy esetleg segít-e ez a tulajdonság a titkosítási kulcs visszafejtésében, illetve hogy az egész EncFS mennyire tekinthető biztonságosnak a blokkszintű megoldásokhoz képest, feltéve, hogy a tárolt adatok egy kis része ismert, illetve nem akarom letagadni az adatok létezését.

Mindenesetre a jelenlegi tudásom alapján én a következőképp csinálnám a dolgot:
Az adatokat helyben is titkosítva tárolnám. Ez a mai processzoroknak már igazán nem gond, bőven gyorsabban tudnak mondjuk AES kódolni, mint a háttértár írni/olvasni. A titkosítást egy DRBD köteten blokkszinten csinálnám, amit normál használatban kettévennék, a mentés pedig az újbóli összekapcsolás lenne, ami egyben egy szinkronizációval is jár.
Ennek a megoldásnak megvan az a kockázata, hogy ha épp a mentés közben döglik meg a menteni kívánt adatokat tartalmazó adathordozód, akkor a túloldalon inkonzisztens állapot marad, és nem túl sok esélyed van viszontlátni az adataid. Ezt a kockázatot vagy lehet vállalni, vagy a távoli oldalon két példányt tartani, és előbb az egyiket, majd a másikat felülírni. Így legrosszabb esetben marad egy eggyel korábbi mentésed.

Nekem speciel meg fog felelni, mivel email-eket, képeket, családi videókat, doksikat meg saját cuccokat mentek mindig, tehát számomra az mtime és a méret nem gond. Ami még infó szivárgás lehet, az a cél mappába mentett xml fájlja encfs-nek, de ez sem érdekel. Nem akarok önszívatásba futni túlzások miatt, ha majd alkalom adtán kelleni fog a mentés. Illetve saját távoli szerverre nyomom jelenleg a mentésem, de mivel webszerver fut rajta, ezért nem akarok ennél több infó szivárgást én sem.

Már csak a mappák exclude-olását akarom megoldani (esetleg mount --bind).

Valószínűleg az encfsctl eszköz lesz a megoldás adott mappák kizárására a mentésből:

"encode: Allows you to specify a filename on the command line, and displays its encoded version. This is useful if e.g. you are taking a backup of an encrypted directory and would like to exclude some files."

De akár. Most ott tartok, hogy inkább azt fogom leprogramozni inkább, hogy a script-em tetején megadom egy listában a kizárni kívánt könyvtárak útvonalát, és ezt megkeresem a titkosított oldalon, és azt rsync-kel fogom exclude-olni (amit Oregon is említett először). Ez lesz a legmegfelelőbb és legáltalánosabban használható megoldás mindenkinek szerintem, mivel a symlink nem fog menni (kizárás helyett megmondani mit), és így nem kell átrendezni az adat struktúránkat sem.

Teszteltem és úgy látom, hogy nem változnak a fájl nevek - illetve ha változna sem lenne gond, mert mindig megkerestetném aktuálisan - most az a kérdés hogy ezt hogy. Az encfsctl körül nézegetek továbbra is.. Illetve azt is lehetne, hogy tmp-n mappa név létrehoz, majd teszt felcsatolás, és kiolvasom a titkosított nevet - valszeg ez lesz. És az összeset egy lépésben.

Ami nem világos, hogy a kizárandó mappák neveit honnét veszi. De kiindulásnak jó.

Szerk.: Illetve hogy hogy küszöböli ki, hogy ne kérjen jelszót az encfsctl? Bekérhetem előre a script-emben, de nem látok opciót arra, hogy átpasszolhassam a encfsctl parancsnak.

Szerk.: megvan: 

encfsctl encode --extpass "echo my password" /dir/to/backup subdir/name

Nem, mert -- legalábbis ha az 

encfs --reverse

-- ér valamit, akkor a 

/tmp/dir/

könyvtár legfeljebb egy kódolt image file-t és néhány metaadat file-t tartalmaz. Ezek együttesen semmit sem árulhatnak el a forrásról (a méretén kívül), tehát ezen nem tudhatsz szűrni az rsync-kel. (Az rsync a kódolt image-filet tükrözi.)

( uid_2716 | 2012. 12. 31., h – 11:22 )

Nahát, a duplicity-ről én is nemrég tettem le. Két problémám volt vele: (1) nem tudtam neki párhuzamos tömörítőt beállítani, (2) valami az "async scheduler" ill. az ideiglenes chunk file-ok kezelése környékén mindig pofára esett benne. Ezen túlmenően nem bántam volna egy kényelmes(ebb) megoldást UDP-n keresztüli feltöltésre (otthoni kapcsolatról a beépített TCP alapú moduljai, pl. sftp, dögletesek a bufferbloat miatt).

Úgyhogy most a duplicity csomagból az "rdiffdir" programot használom inkább egy saját script-tel. A tömörítés lbzip2-vel megy, a feltöltést pak + udp_copy2 kombinációval csinálom kézzel, utólag (ezt így is akarom). A szignatúra file-okat csak a távoli végen tartom meg (a duplicity ugye megtartja itt is, ott is, és a lokális szignatúra használata előtt ellenőrzi, hogy azonos-e a távolival), növekmény készítéséhez esetileg töltöm le.

Sajnos az rdiffdir sem ideális: növekményes módban az adatdeltát helyesen állítja ugyan elő, ugyanakkor az ehhez a friss állapothoz tartozó szignatúra is csak egy delta (szignatúra-növekmény), nem egy teljes szignatúrafa. Ez azért baj, mert az rdiffdir (a teljes duplicity-vel ellentétben) új növekmény előállításakor szignatúraláncot nem tud benyalni, csak egy db szingatúrát. Inkrementum képzéséhez teljes szignatúrafa kell (a duplicity ezt képes dinamikusan összeolvasni szignatúra-növekményekből is). Lásd https://answers.launchpad.net/duplicity/+question/103229 (javasoltam egy megoldást a 4. kommentben, de lusta vagyok nekiállni).

Úgyhogy most kétszer futtatom az rdiffdir-t növekmény készítéséhez: (a) növekmény elkészítése, (b) teljes szignatúrafa elkészítése a majdan következő növekmény alapjául.

Az rdiffdir-ben van egy olyan gond is, hogy a kimenő file-t (pl. növekményt) válogatás nélkül lezárja. Ez stdout-nál gond, mert a python-ban, úgy látszik, van valami atexit jellegű handler, amely az interpreter kilépésekor megpróbálja kiüríteni az stdout-ot. Mivel a duplicity azt addigra (hibásan) lezárta, ilyen futtatásoknak a vége mindig egy python exception (érvénytelen művelet stdio stream-en, vagy valami ilyesmi).

RHEL 6 vonal nem szállít gyárilag semmi használható megoldást

A bacula valószínűleg megfelelő eszköz vállalati környezetben (ahol a hosszadalmas konfiguráció, a dedikált backup szerver root hozzáféréssel megoldható).

EncFS + SSHFS + Rsync-et úgy, hogy a távoli szerverem egyik mappáját felcsatolom helybe, majd ezt tovább csatolom EncFS-el egy másikba, és ebbe Rsync-elek. Sajnos nagyon lassú a sok kis fájlnál, és semmilyen performance tuning sem segít csökkenteni a latency-t.

Egy másik félmegoldásom hasonló, sshfs + losetup + cryptsetup + ext3 + rdiff-backup. Tényleg dög lassú; az ext3 metaadat masszírozása irdatlan forgalmat generál.

Nem tudok mit ajánlani. A duplicity architektúrája jó. Kellene bele egy konfigurálható filter az rdiff delta és a gpg közé (ez most bedrótozottan gzip vagy bzip2, library-ből, nem utility-ből), ill. a programozási hibákat egyszerűen ki kellene javítani benne. Szintén hasznos lenne a növekmény lokális előállítása (és a feltöltés felhasználóra bízása), függetlenül attól, hogy a teljes archívum (full backup + korábbi növekmények) távol vannak.

Megnéztem a linkeket, köszi. Ki kellene próbálnom, hogy lássam a repo formátumot, de úgy sejtem, ez megint nem teszi lehetővé, hogy a változásokat lokálisan generáljam, majd én töltsem fel (a teljes repót tarthatnám helyben és tükrözhetném távolra, de ezt nyilván nem akarom). A másik probléma, hogy (legalábbis a manual szerint) a 

--compress-with=PROGRAM

opcióban a PROGRAM opt-arg csak "none" ill. "deflate" lehet. Gáz.

Azt hiszem, maradok az rdiffdir-nél, számomra annak a legjobb az architektúrája. Az a fontos, hogy a könyvtárfa-növekményt valami képes legyen előállítani (+ a frissített szignatúrát), illetve helyreállításkor alkalmazni. A többire (tömörítés, titkosítás, feltöltés) van bevált "módszerem". Rá kéne néznem arra az rdiffdir bugra...

Sajnos az rdiffdir sem ideális: növekményes módban az adatdeltát helyesen állítja ugyan elő, ugyanakkor az ehhez a friss állapothoz tartozó szignatúra is csak egy delta (szignatúra-növekmény), nem egy teljes szignatúrafa. Ez azért baj, mert az rdiffdir (a teljes duplicity-vel ellentétben) új növekmény előállításakor szignatúraláncot nem tud benyalni, csak egy db szingatúrát. Inkrementum képzéséhez teljes szignatúrafa kell (a duplicity ezt képes dinamikusan összeolvasni szignatúra-növekményekből is). Lásd https://answers.launchpad.net/duplicity/+question/103229 (javasoltam egy megoldást a 4. kommentben, de lusta vagyok nekiállni).

Elküldtem a patch-eket (sajnos a lista-szoftver nagyon lassú): http://lists.nongnu.org/archive/html/duplicity-talk/2012-12/index.html

Több fajta, és majdnem folyamatosan. Most legutóbb SL 6-on Epel repóban lévő duplicity (0.6.18) nem akarja elindítani a feltöltést "unknown server" hibával: google:// "duplicity scp unknown server" dob egy rakás bejegyzést erről (is). Egyszerűen elszállt a bizodalmam tőle, mivel egy szimpla alap funkció nem működik jelen esetben. Ez gáz. Ha nagyon extra paraméterezéssel futok bele, akkor ok.

Tudom hogy letölthetnék új verziót stb. de hosszú távon volt sok hiba. Legutóbb Fedorán a deja-dup-os frontenddel nem volt gond - legalábbis nem látszott. De ki tudja az is melyik frissítésig tartott volna.

Ilyen alkalmazasnal siman lehet freezelni szerintem. Vagyis egy adott verzional lehorgonyozni. Mivel nem kiszolgalo, minimalisan tamadhato, igy sokkal kevesbe vagy kenyszeritve a "mindig friss" hasnzalatara.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

De - mint írtam - elszállt a bizodalmam tőle. Éppen azért, mert ha egy ilyen alap funkció bug-os, akkor mit várhatok a fontosabb algoritmusok környékén. Nehogy akkor vegye észre az ember hogy korrupt a backup, ha éppen kell. Persze lehet tesztelni is, de az sem kevés idő, főleg nem távoli 30-40 GB-os mentéseknél.

( goodbyte v | 2012. 12. 31., h – 14:10 )

subs

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( igor | 2012. 12. 31., h – 17:20 )

Crashplan headless módban a szerverre. A kliensen ssh tunnel a szerverre + crashplan kliens. A fájlokat jelszóval vagy kulccsal is alá tudod írni. És ez így free.

( sheridan | 2012. 12. 31., h – 20:18 )

Szia!

Ötlet. Ha nem gáz, hogy egyetlen fájlba kerülnek az adatok, akkor egy sor az egész - SSH kulcs csere, utána:

tar zcf - ./cucc | gpg --symmetric --yes --passphrase=abc123 | ssh backup@ warbird.valami.hu 'cat - > cucc.tar.gz.gpg'

Tarral nyilván lehet exclude-olni is könyvtárakat. Ha nem akarsz commandline jelszót rakni, akkor írd át a gpg parancsot kulcsosra. Esetleg OpenSSL-t is használhatsz GPG helyett ha az jobb. Remélem segít valamit.

Szerk: Eh, most látom, hogy teljesen más irányba mentetek el - úgyhogy nem szóltam. Azért itthagyom, hátha valakinek azért jól jön, ha az egyszerűség fontos...

( hedermisi v | 2013. 01. 02., sze – 17:19 )

Szia!

Ami nekünk remekül bevált:
1) hálózaton keresztül megosztunk egy block device-et. A mi esetünkben ez iSCSI, de gondolom lehetne NBD, vagy ha helyi háló akkor AoE
2) a kliens oldalon felcsatoljuk
3) LUKS titkosított fájlrendszert hozunk létre és mountoljuk
4) Az így felcsatolt fájlrendszerre rsync-el szinkronizálunk

Előnye, hogy elég gyors, hiszen az rsync-nek csak a lokális gépen belül kell deltákat számolnia. Néhány millió fájl (tipikusan mail folderek) esetén érdemes al-mappánként futtatni az rsync-et, de addig jól bírja.

Hátránya, hogy egy sima ssh vagy rsync port nem elég hozzá, fel kell tudnod húzni mondjuk egy ISCSI vagy NBD szervert a távoli gépen.

Ez valóban használható, azonban ahogy fentebb írtam:

Egy másik félmegoldásom hasonló, sshfs + losetup + cryptsetup + ext3 + rdiff-backup. Tényleg dög lassú; az ext3 metaadat masszírozása irdatlan forgalmat generál.

Illetve a topikindítóban:

Sajnos nagyon lassú a sok kis fájlnál

... "lakossági interneten" nagyjából a hajad kitéped, mire ezres nagyságrendben átnéz file-okat. Arról nem beszélve, hogy ha elszáll a net mentés közben, akkor utána futtathatod az fsck-t (vagy pörgetheted a journal-t) ugyanazon a cérnavékony kapcsolaton keresztül. Gondolom, ti minimum gigabit ethernet felett használtok iSCSI-t.

Lehetséges, hogy a protokollt nem erre találták ki, de attól még tűrhetően működhet így - nem ez lenne az első eset a technika történetében. Az is igaz, hogy a késleltetésre érzékeny. Mindettől függetlenül van olyan eset, amikor teljesen megfelelő, például nálunk: van hozzáférésünk egy 200km-re lévő iSCSI szerverhez, 1G sávszéllel és mentéseket tolunk oda. A késleltetést túléljük, a telephelytől pedig kellően távol van ami a mentésnél szempont. Íme, egy eset amikor az iSCSI teljesen oké.

"sshfs + losetup + cryptsetup + ext3 + rdiff-backup"

Talán hozzá kellett volna tennem, hogy az általam javasolt megoldásnál épp az a lényeg, hogy jó eséllyel cache-elni fogja az initiator a fájlrendszer fontos részeit. Elképzelhető, hogy az általad vázolt kombóban (amit nem teljesen értek amúgy) ez nem jött össze. Minden esetre megerősíthetlek, ha minden egyes alkalommal olvasni kell a metaadatot akkor megette a fene, főleg, hogy a mentőszerver nyilván nem írkál az adatokba, tehát tudjuk, hogy azok úgyse változtak a legutóbbi mentés óta. Innentől kezdve viszont fontos a RAM/mentendő adat arány. Néhány giga mentendő cucc esetén nagyon jól jártál, terabájtoknál meg reménytelen.

Másrészt pedig az ext3-at nem javasoltam. Mostanában méregettek hallgatók nálunk elég sokat, ha jól emlékszem az XFS lett a nyerő kisfájlos esetekben.

Arról viszont valóban lemaradtam, hogy ezt otthoni nettel kéne. Mi 1G/10G esetekben használunk ilyesmit, viszont a telephelyek a kilométerekre vannak egymástól, így itt már beszélhetünk távoli mentésről. 100M-el is van még tapasztalat, tűrhető.

Az általam vázolt kombó részletesebben:

  • Létrehozok egy pár GB méretű image file-t a távoli szerveren (ssh-val belépve, fallocate paranccsal). Ez egyszeri lépés.
  • A helyi gépen sshfs-sel felcsatolom a távoli gépről az image file-t tartalmazó könyvtárat. Az image file így látható a helyi gépen.
  • Az image file-t losetup segítségével /dev/loop%d-ként álcázom. Utóbbi már egy block device. (A loop driver egyébként akaratlanul is cache-el (mivel file-ba ír); emiatt például nem is szerencsés VM diszknek loop device-t adni. Ezen mondjuk sshfs opcióval lehet reszelni.)
  • A /dev/loop%d-t megformázom cryptsetup-pal LUKS device-nak (először), ill. megnyitom vele (minden további alkalommal). Ennek hatására létrejön egy új device mapper node (/dev/mapper/crypt_dev), ami szintén block device.
  • A /dev/mapper/crypt_dev-et megformázom a mke2fs paranccsal (először), majd felcsatolom (minden további alkalommal) pl. /mnt/backup mount point alá. Ez a file system valószínűleg önállóan is cache-elt lesz.
  • Az rdiff-backup utility-vel a (mondjuk) /home/ könyvtárat mentem a /mnt/backup/home alá.

Az rdiff-backup első körben a leíró adatok változását nézi, rekurzívan bejárva és összehasonlítva a két fát. Amikor mond egy stat()-ot, akkor az ext2/ext3 fs-ből kell az inode. Ha cache-elve van, jó; de bármely file legelső érintésekor (legalábbis ha a link count 1) nincs cache-elve. Ezért az ext2 driver benyalja a megfelelő blokkot a /dev/mapper/crypt_dev-ről, amit a dm-crypt a /dev/loop%d-ból old fel, amelyet a loop driver az sshfs driver-hez továbbít FUSE-zal, amelyet az sshfs driver SFTP block request-re fordít le. Ennek a round trip-je irdatlan nagy (lakossági neten), ráadásul abszolút szinkron módon megy -- amíg a legfelső szintű ext2 driver vár az inode-ot tartalmazó blokkra, addig az alkalmazás a stat()-ban áll, mint a cövek.

Tehát nem az a baj, hogy gyakran kell olvasni a metaadatot. Az a baj, hogy rengeteg file inode-ját kell egyszer benyalni, szigorúan sorosítva, nagy válaszidejű hálózaton.

A backup után nyilván lebontjuk a teljes mount/blockdev kupacot, a felépítés fordított sorrendjében (amúgy is eltelik mondjuk 1-2 nap a következő backup-ig, amely idő alatt párszor újraindítjuk vagy aludni küldjük a helyi gépet, tehát a hálózati kapcsolatoknak kampó). Így a következő backup-nál hideg a cache.

Az XFS-sel az a baj, hogy extrém érzékeny az umount nélküli elszállásra (ha lehet hinni az olvasottaknak). Utóbbi sajnos meglehetősen lehetséges: a backup közbeni hálózati megdöglés pontosan ennek felel meg. (A helyi XFS/ext2/ext3 driver szennyese, valamint a helyi sshfs szennyese a helyi kernel cache-ében van, a tartós tár meg a távoli gépen.)

Félreértés ne essék, ez a kombó borzasztóan otromba, szóval nem reklámozom.