Sok fájl (hardlink) mentése

Debian GNU/Linux

Költöztetni szeretnék egy 4T-s fájlrendszert, ami 90%-ig tele van, és van rajta 18 millió db fálj (reiserfs). Két db. 2T-s diskre tudnám lementeni (vagy inkább 3-4db 1.5T-s diskre). Az adatok jórészt már eleve tömörítettek, illetve 60%-80%-ban nem is fájlokról, hanem hardlinkekről van szó. A jogosultságok, attributumok, acl-ek nem érdekesek.

Olyan cucc kéne, ami a leghatékonyabban kezeli a hardlinkeket, plusz az ideális az lenne, hogy mint a tar, ha megtelik a szalag (disk), akkor új disket adhatok neki, amire folytatja az írást, azaz nem lenne a gépben egyszerre az összes disk amire mentek, hanem pl. nfs-en át kapna tárterületet, amire ment és amiről visszaállít.

A tar, cpio mellett a rar, arj, zip, 7zip merült fel bennem, tehát ötleteim vannak. Viszont érdekelne, hogy van-e valakinek konkrét tapasztalata ilyen mentésről, amikor jobbára hardlinkeket kell menteni.

  • 4020 megtekintés

( Fisher v | 2012. 07. 25., sze – 14:36 )

Csináltam egy rövid tesztet jóval kevesebb (kb. 200k) fájlra.
Nos, nem igazán meglepő módon a 7zip, rar, stb. csak bután nézett a hardlinkekre, nem boldogult vele. A többiek viszont egész jól elkocogtak (az arj pl. kezeli a hardlinkeket). A tömörítés mértékében nem láttam eszevetett különbséget, de a sebesség már jelentősen eltér:

Test: tar + gz + split:4.4G:4.0G

real 13m46.033s
user 5m49.562s
sys 1m37.622s

Test: cpio:8367736 blocks
4.4G:4.0G

real 24m9.775s
user 15m0.056s
sys 1m27.585s

Test: dar:4.4G:4.0G

real 42m18.556s
user 32m3.316s
sys 1m18.941s

Test: arj:4.4G:4.0G

real 20m38.286s
user 9m3.554s
sys 2m28.861s

Mivel a dar túl lomhának tűnt ezért lefuttattam újból, de akkor se lett fürgébb. A bámulatos script ami a teszteket futtatta itt csodálható: http://pastebin.com/JAtFgyBY

De ha az idő kritikus és az adatok nagy része már tömörített egyébként is, akkor minek tömöríteni egyáltalán?
pbzip2 pl. nálam egy partíció mentést komolyan lelassít (mondjuk +50% idő a tömörítetlenhez képest), de nálam számít a méret.

És a másik: ha pbzip2-n megy keresztül, akkor a CPU a szűk keresztmetszet, ha tömörítetlenül megy, akkor meg az I/O.

Én tömörítetlenül vagy valami gyors dologgal, mint lzop tolnám.

G

( mauzi v | 2012. 07. 25., sze – 21:27 )

- Ezek gondolom rsync-kel készült inkrementális mentések, azért van ennyi hardlinked.
- Ha nem tudod egy cél-fájlrendszerre menteni az egészet, akkor úgyis lőttek a hardlinkeknek, legalább egy duplikátumod lesz.
- A sebesség szempontjából a szűk keresztmetszet ott lesz, hogy (fájl alapú mentésnél) minden fájlnál fel kell kutatni, hogy van-e rá hardlink. Az meg ennyi fájlnál lassú, bármilyen okos eszközt találsz hozzá.
- Jelen környezetben a hardlinkekre nyilván szükség van. Érdekes is volna mindenből duplikátum...

Én amondó vagyok, hogy a cél diszkekből csinálj a költöztetés erejéig egy megfelelő méretű logikai diszket (JBOD, RAID, ...) aztán image/snapshot alapon told át az egészet.

Azok.
Ezt nem értem, a tar, arj, cpio, stb, kezeli a hardlinket.
A sebesség másodlagos, idő kb. annyi van, amennyit rászánok. Azért lehetőleg 1-2 nap alatt fusson le. És ahogy nézem inkább CPU cappos a dolog (bár az 5m user time ennek ellent mond). De majd teszek egy tesztet pgzip-pel is.
Nyilván :)

Amúgy a menetrend kb. az lesz. A raid10-et szétszedem, a feléből csinálok egy degradált raid6-ot, arra pvmove, aztán beleteszem a 2 paritást, illetve a maradékokkal felbővítem a raid tömböt, hozzányújtom a pv-t, és boldogság van. Elvileg folyamatosan élni fog az FS, elvileg nem vész el adat, és elvileg nem lesz szükség a mentésre.

( tovis v | 2012. 08. 06., h – 13:29 )

Lehet hogy jobb lenne ha hallgatnék ...

Az adatok jórészt már eleve tömörítettek

Akkor miért nem egyszerűen tömörítés nélkül a tar, minek az arj, bzip gz és ami még akad?
A tar tökéletesen fel van készítve a hardlinkekre és kezel mindenféle jogosultságot.

* Én egy indián vagyok. Minden indián hazudik.

Így van, jórészt tömörítettek, illetve a tesztek alatt erősen IOlimites volt a gép, a cpu pihent. Aztán a valós adatoknál már kicsit más volt a helyzet, így a végleges megoldás az lett, hogy nfs-en át tar, a célhelyen meg gzip. Már csak azért is, mert fogalmam se volt arról, hogy a célterületen el fog-e férni a cucc. Elvileg persze el (el is fért), de mivel kicsit szűkösnek ítéltem, ezért úgy voltam vele, hogy egy gzip nem árthat neki.

A tökéletes felkészítés amúgy valahol hibádzott, a mentés előtt:

/storage/data1
/storage/data2
/storage/data3
etc, etc

volt, visszaállítás után pedig:

/storage/data1
/storage/data2 (az adatok 10%-a itt)
/storage/storage/data2 (a maradék 90% itt)
/storage/data3
etc, etc

Csak egy könyvtárnál hibázott, de persze abban volt a legtöbb cucc. Szerencsére ezt volt a legkönnyebb pótolni, egy full mentéssel meg is oldottam. Sajnos nem hiszem, hogy alkalmam lenne még egyszer kibontani az egészet vagy valami módon tesztelni, hogy mi is volt a baj.