Backup probléma nagy fájlmennyiségű ext4-en

Linux-haladó

Sziasztok,

tanácsot szeretnék kérni tapasztaltabb kollégáktól napi adatmentés területén. Az alábbi alapján

- ext4 fájlrendszer, jelenleg 11 millió állomány, legtöbbje kis méretű, összességében 770 GB
- rsnaphot/rsync inkrementális mentés (20 nap), 3 különálló logikai konfiguráció (levelezés, kis mennyiségű adatok, nagy mennyiségű adatok), cronból indítva eltérő idővel
- helyi mentés másik diskre, ext4-re (csak backupra van)

a kis és nagy mennyiségű adatok mentése mindig egymásra fut (mert nem végeznek időben), eléggé leterheli a szervert, és sokszor 6-7 órán keresztül is dolgozik.

Ahogy elnézem, a legtöbb idő nem magával a mentéssel megy el, hanem azok törlésével, és egyebek mellett ez az, ami nagyon terheli a szervert.
Meg kell említenem a 16 GB-os mysql adatbázist, ennek dump alapú mentése is bekavar a terhelésbe, főleg a tömörítés miatt (ezt szerintem megoldom innobackup-al, 30 perc alatt végez, csak a visszaállításra kell még felkészülnöm).

Korábban rdiff-backupot használtam, de az egy idő után kevés lett, átváltottam az rsnapshot-ra. Egy ideig nagyon jó volt, de ahogy nőtt a mentendő adatmennyiség, úgy kezdett el
ez is "kevés" lenni. Úgy érzem, hogy már olyan határokat feszegetünk, amit önmagában szoftverrel nem, csak egyedi megoldássokkal lehet megoldani.

Van valakinek tapasztalata ezen a területen?

Előre is köszönöm a segítséget!

  • 9768 megtekintés

( Elbandi v | 2013. 06. 03., h – 14:25 )

mennyire van szetszorva az a sok fajl konyvtarakban?

tapasztalatom szerint ~20-30k db fajl per konyvtar meretig eleg gyors, felette erosen kezd lassulni.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( tompos v | 2013. 06. 03., h – 14:35 )

Most akkor mi is a lassu? A server vagy a kliens?

backupolando oldal
==================
- tuningold az fs-t (semmit nem irtal rola, csak az ext4-et)
- cserelj fs-t (pl. xfs)
- cserelj alatta storage-ot (pl. ssd, kulso storage, tobb tengely..stb)
- 16GB db semmi, seperc alatt at kell mennie
- nezd meg, hol van a szuk keresztmetszet

backup szerver oldal
====================
- hasznalj cow FS-t v. storage-ot + snapshotokat + rsync --inplace + snapshot delete
- hasznalj zfs-t mindket oldalon -> zfs send/recv
- hasznalj gyorsabb storage-ot (lsd. fent)
- szedd szet kisebb darabokra es futtasd parhuzamosan a jobokat
- valogasd meg, h valoban akarod-e menteni, amit leszedsz (pl. cache-t ne)
- hasznalsz fs szintu tomoritest
- rakhatod image-re a szervert es akkor csak az image-et kell mentened, ehhez hasznalj deduplikaciot

A szerver és a kliens ugyanaz, azaz fizikailag adott gépen belül marad a mentés. Egy raid1-es tömbön lévő adatokról készül naponta mentés egy másik diszkre - nem tankönyvi, de a célnak idáig megfelelt.

Sajnos a jobokat nem nagyon merem párhuzamosan futtatni, mert a terhelés az egekbe szökik, főleg akkor, mikor törlési fázisban vannak - Én legalábbis ezt gondolom szűk keresztmetszetnek. Időben is sokszor jóval tovább tart, mint maga a mentés, és komolyabb terhelést is okoz. Sok kisméretű fájlról van szó, tulajdonképpen csak ilyenek vannak. Nem méretre, hanem darabra sok, ezért okoz többlet terhelést az rm -rf.

Az ext4 "gyári" módon lett létrehozva és mountolva ráadásul a fájlrendszerek tuningolásához sajnos semmit nem értek (tulajdonképpen ez is az egyik ok, hogy hozzátok fordulok). Sőt, nem is gondoltam arra, hogy az ext4 esetében tuningolásra keressek, mert önmagában a teljesítményével semmilyen probléma nincs. Mountként usrquota, user_xattr és noatime van megadva.

Gondoltam már arra is, hogy betennék egy másik gépet csak backup storage-nak, de ezt most ebben a pillanatban nem akarom meglépni. Viszont SSD-t cache-nek beraknék.

Most, hogy említetted a ZFS-t, utána néztem, mert ugyan korábban is nézegettem, de akkoriban még nem tartották product szintűnek (Ubuntu-ra kellene mennie). Találtam egy áprilisi bejegyzést, amely szerint már stabil a 0.6.1-es verziótól, viszont ez az a világ, amit totál nem ismerek. ZFS esetén milyen megoldás létezhet, mit javasolnátok, ha csak a backup diszkre tenném ezt, a mentendő adat maradna ext4-en?

Az egy könyvtárban lévő fájlok számát nem tudom megbecsülni. Legtöbb esetben honlapokról van szó, Joomla, Wordpress, egyéni fejlesztések, sok feltöltött anyag. Azt mondanám, hogy az átlag könyvtárakban nem lóg földig a lista, viszont az átlag könyvtárakból nagyon sok van, és van pár kiemelkedő ügyfél, akiknél 100 ezernél több állomány van. Ők a 11 millió állomány mintegy felét képviselik.

Más.
A mysql mentése szerintem azért tart sokáig, mert táblánként történik a dumpolás. Konkrétan ezt nem tudom mennyi, adatbázisból most kábé 900 van. A méret önmagában szerintem se túl nagy probléma, itt valószínűleg maga a mentési módszer az, ami teljesítménybeli problémát okozhat. Azért mentem táblánként sql dumppal, mert az ügyfelek kivétel nélkül táblaszinten beszélnek mikor visszaállítást kérnek. Ezt a mentési módszert lefogom váltani innobackup-ra, már teszteltem, majdhogynem álom szintű volt. Ha egy ügyfél visszaállítást kér, a megfelelő verziójú innobackup-ot elindítom egy másodlagos mysql szerverrel, kidumpolom a kérdéses táblákat és visszaállítom. Bár többlet munka, egy év alatt nem sokszor kérnek ilyet, viszont a mentés sokkal gyorsabban lemegy, ráadásul észrevehető terhelés nélkül.

> a célnak idáig megfelelt.

Melyik celnak?:)
Nyilvan addig jar a korso a kutra, amig meg nem basszak a vizhordo lanyt, azaz az ugyfeleid is addig lesznek boldogok, neked meg penzed, amig a tap el nem pukkan a gep teljes tartalmaval egyetemben..vagy vmi hasonlo tortenik.

> SSD

Cache formajaban szerintem itt nem fog sokat segiteni.

> zfs

Mi az, hogy milyen megoldas? Leirtam reszletesen par otletet

> mysql

Nem ismerem az innobackup-ot.
De ha jol gondolom, csinal egy snapshotot a file-ok partiocijarol es a nyers file-okat masolja at.
Ehhez nem kell innobackup. Ha mas varazslas es okosabb, akkor hajra.

tompos

Szerintem valamit félreértettél, vagy félregondoltál, kérlek gondold át még egyszer. Nem azt írtam, hogy single tápos, játékos kedvű szerveres fickó vagyok amit szeretnék fokozni, hanem a korábban vázolt problémával kapcsolatban szerettem volna tanácsot kérni. Hogy abból hogyan szűrted le a következtetésedet, azt nemtom, de szép cél lehetne ezt a szokást elhagyni.

A számodra részletes leírás számomra powerpoint kulcsszavak előadás nélkül. Nyilván nem vagyunk szakmailag egy szinten (nem is mondanám magam szakmabelinek), nem is baj, mindig kell valamit tanulni. Ahhoz viszont nem tőszavak kellenek, nyilván megérted. Szerintem Te sem így tanultad, és bevallom, Én sem így szeretném. Nyilván nem tarthatsz gyorstalpalót a zfs-ből, de 5 mondattal több, vagy egy link, vagy egy trükk tarsolyból mielőtt tovább adom, mint pl ez:

http://wwerther.de/2011/10/migrate-rsnapshot-based-backup-to-btrfs-snapshots

szóval ilyesfélére gondoltam. Elismerem, a Te hatásodra találtam meg. De ez mégsem zfs, hanem btrfs.

Az SSD esetében arra utaltam, hogy beruházás tekintetében most ez áll hozzám közelebb, nem egy backup szerver. Inkább több munka, legyen akár az ext4-ből is zfs megtámogatva SSD-vel, csak megfelelően működjön a mentés.

Más.
Innobackupex: https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html

Hot backupot készít lockolás nélkül elsősorban myisam és innodb táblákról. A végeredmény tulajdonképpen egy mysql data könyvtár tükrözés, ami egy az egyben elindítható, természetesen innodb problémák nélkül. A backupot lehet streamelni is, tömöríteni, erőforrást szabályozni, szóval mysql mentéshez kiváló (egy nagyon jó barátom javasolta, akinek naponta 1.2 TB-ot kell így mentenie nagyüzemben).

rakd be azt a másik gépet.
egyrészt onnantól van backupnak nevezhető backupod, másrészt a külön diszkek jót fognak tenni mind a sebességnek, mind az eredeti szerver terhelésének.

a duplicity-t is ajánlom megnézésre. rsnapshot-hoz képest kicsit pilótavizsgás de ha nem sokszor kell visszaállítani akkor ez a jó megoldás, minimálisat fog a gépen.
a saját script faragást kevésbé ajánlom, van pár jól összerakott backup csomag, kár feltalálni a melegvizet - szerintem.

--
Gábriel Ákos
http://i-logic.hu

hidd el tomposnak és nekem, a gépen belüli backup öntökönszúrás. pont akkor nem lesz amikor kéne nagyon. ssd-re backupolni az megint nem hangzik ésszerűnek. ha hostingban van akkor lehet backupolni a hostingcég által adott tárhelyre, vagy akár amazon glacier-be (vagy s3-ba, ez drágább). duplicity helyből tudja.

--
Gábriel Ákos
http://i-logic.hu

Nagyon köszönöm a jótanácsot, komolyan!

Szívesen betenném a backup gépet (már csak azért is, hogy ne vegyen el erőforrást), de ennél az egy gépnél sajnos nem célszerű. Néha arra gondolok, hogy bánja fene, berakok egy tartalék szervert, de egyszerűen ki kell még bírnom 5 hónapot, amíg lejár a szerződés, utána pedig átteszem a többi géphez, itt lesz backup szerver is (amúgy 5 hónap hosting díjából már majdnem kijön egy backup gép). 3 helyen vannak szervereim, ezeket vonom össze egy helyre az idén.
Egy ideig csináltam azt, hogy ide mentettem, de a 100 Mbit-es sávon nem volt túl jó, főleg, ha hirtelen nagy mennyiségű adatot tettek fel. gigabitet két helyen kellene vennem, ez sem túl jó. Ezért aztán az amazon sem jöhet szóba, adatvédelmi okok miatt viszont senki. Ebben a helyzetben nem látok más megoldást csak a jelenlegi folytatását.

Nem hiszem el, hogy 100MBiten ne lehetne menteni. Rsnapshotnak is, duplicitynek is be lehet állítani limitet, mondjuk 30 MBit. Rsnapshot-tal, 30MBit-tel 6 óránként mentek le komplett gépet. 40 percig tart általában. Duplicity-vel naponta, többet.
Mivel csak 30MBit-et tol át, igazán egyik gépet sem eszi, sem a küldő sem a fogadó oldalt.

--
Gábriel Ákos
http://i-logic.hu

( uid_6201 v | 2013. 06. 03., h – 14:50 )

Kell neked access time valamire?
Ha nem, akkor a "noatime" mount opció is sokat segít, mert olvasáskor nem kell visszaírnia a diszkre az elérési időket.

( hnsz2002 v | 2013. 06. 03., h – 16:49 )

Én úgy oldottam meg a sokfajta mentést, hogy egymás után lesznek indítva, így biztos nem futnak egymásra...
0 1 * * * root /root/scriptek/backup/mailbackup.sh; /root/scriptek/backup/sqlbackup.sh; /root/scriptek/backup/wwwbackup.sh

Egyébként meg noatime, nodiratime mount opciók. Én rdiff-backupot használok, nincs vele baj.
--
The Community ENTerprise Operating System

( freeoli v | 2013. 06. 03., h – 17:00 )

Incremental only backup alkalmazások erre fel vannak készítve és * hatékonysággal tudják végezni. Lehet, hogy a sok apró file miatt egy réteggel lejjebb kellene vinned a backupot vagy valamilyen blokkszintű replikával ments valahova ahol pl snapshotokkal tartasz meg korábbi állapotokat ...

( maszili | 2013. 06. 03., h – 18:49 )

Hasonló mentést készítnünk és nincs ilyen gond.

Egy korábbi hozzászólásban írtam:

Több mint százmillió file, 1118 GByte, napi szinkronja ~6 óra alatt szokott lemenni minden éjféltől.
Tehát minden alakalommal egy teljes szinkron készül (az összes file aznapi állapota) a komplett rendszerről hardlinkek segítségével deduplikálva több napra/hétre/hónapra visszamenőleges állapotokkal.

Mindezt úgy, hogy a mentés külön backup szerverre megy gigabites hálózaton keresztül.
Tehát először megy a szinkron a produktív szerverről a backup szerverre (kb. 6 óra alatt megvan), majd a backup szerveren megy a régi szükségtelen mentések törlése ami már nem zavarja a produktív rendszert.

--
maszili

maszili, a gigabites hálózat nekem csak úgy menne, ha közvetlen a gép mellé tennék be egy másik gépet, ezt viszont ennél a gépnél most nem akarom megtenni. Egyébként adtál egy jó ötletet: ha jól emlékszem, van lazy delete az rsnapshotban, talán az alkalmi megoldást jelenthet. Vagy a törlést teljesen másként is megoldhatjuk, jóval korábban vagy később, rsnapshot-tól függetlenül.

A lazy_delete azt mondja, hogy a törlendő snapshot könyvtárat egy tmp könyvtárba mozgatja, törli a lockfile-t, majd nekiáll törölni a tmp könyvtárat. Szóval ezzel annyit érsz el, hogy a kritikus szekció rövidebb lesz, hamarabb indulhat a következő rsnapshot job, de esélyes, hogy ez a következő job és az előző törlése részben egy időben fut majd. Ha jól értem a fentieket, akkor ez neked nem lenne jó...
Ellenben talán lehetne egy olyat trükközni, hogy megadod a /bin/true-t mint custom rm parancsot, és akkor az rsnapshot csak tmp könyvtárakba mozgat, és nem áll neki törölni, azt majd megcsinálod te valamikor később.

( ncc1701 | 2013. 06. 03., h – 20:34 )

Egy hülye ötlet: sokszor egyszerűbb formázni a partíciót, mint letörölni a csilliárd apró fájlt.

sz, ez látod nem rossz ötlet. Írtunk egy kis python programot, amivel nagy mennyiségű fájlokat tudunk úgy törölni, hogy az nem vesz el annyi erőforrást, mint az rm. Persze jóval tovább is tart a dolog :) , de ezzel utólag ellenőrizve tudnánk törölni.

A lazy_delete átnevezi a törlendő könyvtárt, asszem hozzáteszi, hogy _delete vagy .delete (nem teszi el tmp-be), a cmd_rm -nek pedig a /bin/true azt adhatja vissza, hogy sikeres volt a törlés. Egyébként csinálhatnánk egy saját programot is, egy sor az egész, a lényeg a hatás. A törlésről pedig magunk gondoskodhatunk.

Talán azért, mert az "rm aaa" nem csak egy szimpla unlink() hívást csinál: 


11:53:22.538939 lstat("aaa", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
11:53:22.539012 stat("aaa", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
11:53:22.539082 geteuid()               = 0
11:53:22.539119 getegid()               = 0
11:53:22.539155 getuid()                = 0
11:53:22.539203 getgid()                = 0
11:53:22.539241 access("aaa", W_OK)     = 0
11:53:22.539293 unlink("aaa")           = 0
11:53:22.539367 close(1)                = 0
11:53:22.539431 exit_group(0)           = ?

Miközben a perl-ben egy unlink("aaa"): 


11:53:54.988544 lstat("aaa", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
11:53:54.988623 unlink("aaa")           = 0
11:53:54.988747 exit_group(0)           = ?

De gyanús a find kontra perl regexp sebesség is sok (jelen esetben közel 40) minta esetében. A beégetett cucc, amit ki kell váltani, "-exec rm {} \;"-mel megy, azzal szemben több százszor gyorsabb a Perl, az xargs-os mókoláshoz képest "csak" 50-100-szoros különbségre emlékszem.

Apró különbség még a Perl kontra find témában az, hogy Perl-ben az opendir() után a fájlnebekre megy a mintaillesztés, és csak ami egyezik, arra csinálok stat()-ot, és nézem meg, hogy az mtime hogyan áll a lejárathoz képest.

"az "rm aaa" nem csak egy szimpla unlink() hívást csinál:"

Az u/gid-et egy futtatás során csak egyszer kérdezi le (miért tenné többször?), csak a stat-os dolgokat kérdezi le külön minden file-ra.

"A beégetett cucc, amit ki kell váltani, "-exec rm {} \;"-mel megy, azzal szemben több százszor gyorsabb a Perl"

Az "-exec rm {} \;" minden egyes file-ra külön futtatja az rm parancsot, nem csoda, hogy lassú. 

$ sok=$(for i in {1..10000} ; do echo _delete.$i ; done)
$ touch $sok
$ time find . -name '_delete.*' -exec rm '{}' ';'

real	0m13.602s
user	0m0.156s
sys	0m1.836s
$ touch $sok
$ time find . -name '_delete.*' -exec rm '{}' '+'

real	0m0.120s
user	0m0.024s
sys	0m0.092s

xargs gyakorlatilag ugyanezt csinálja, így az is kb. ugyanígy teljesít (±5%).

Nem. Az rm (RHEL5) minden fájlnál csinál euid/egid/uid/gid lekérdezést, de szerintem elsődlegesen a find helyett perl-ben megvalósított mintaillesztés és stat()-ból kapott mtime vizsgálat az, ami nagyon sokat jelent. És az sem mindegy (nálad nincs "mtime" feltétel), hogy milyen feltételekkel keres a find. 


13:01:07.115954 lstat("aaa", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
13:01:07.116171 stat("aaa", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
13:01:07.116237 geteuid()               = 0
13:01:07.116275 getegid()               = 0
13:01:07.116320 getuid()                = 0
13:01:07.116360 getgid()                = 0
13:01:07.116425 access("aaa", W_OK)     = 0
13:01:07.116470 unlink("aaa")           = 0
13:01:07.116588 lstat("bbb", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
13:01:07.116650 stat("bbb", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
13:01:07.116717 geteuid()               = 0
13:01:07.116754 getegid()               = 0
13:01:07.116791 getuid()                = 0
13:01:07.116844 getgid()                = 0
13:01:07.116887 access("bbb", W_OK)     = 0
13:01:07.116930 unlink("bbb")           = 0
13:01:07.117008 lstat("ccc", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
13:01:07.117084 stat("ccc", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
13:01:07.117144 geteuid()               = 0
13:01:07.117181 getegid()               = 0
13:01:07.117217 getuid()                = 0
13:01:07.117252 getgid()                = 0
13:01:07.117290 access("ccc", W_OK)     = 0
13:01:07.117332 unlink("ccc")           = 0
13:01:07.117419 close(1)                = 0
13:01:07.117516 exit_group(0)           = ?

"Az rm (RHEL5) minden fájlnál csinál euid/egid/uid/gid lekérdezést"

Ezekszerint az ubuntu rm-je okosabb.

"de szerintem elsődlegesen a find helyett perl-ben megvalósított mintaillesztés és stat()-ból kapott mtime vizsgálat az, ami nagyon sokat jelent"

Hogy mi számít jobban, az attól függ, hogy mennyire bonyolult a mintaillesztés, és hogy a vizsgált file-ok számához képest mennyit kell belőlük törölni: 

$ touch $sok
$ time find . -mtime +30 -name '_delete.*' -exec rm '{}' ';'

real	0m0.056s
user	0m0.008s
sys	0m0.044s

Az nem mindegy, hány alkönyvtárról beszélünk.

100000 fájllal, a te példáddal:

root@ubserv:~/teszt# time find . -mtime +30 -name 'bla.*' -exec rm '{}' ';'

real 0m0.292s
user 0m0.076s
sys 0m0.212s

(Ez így nem ír, csak olvas)

root@ubserv:~/teszt# time find . -mtime -1 -name 'bla.*' -exec rm '{}' ';'

real 1m1.254s
user 0m0.908s
sys 0m10.913s

(Lassú)

root@ubserv:~/teszt# time find . -name 'bla.*' -exec rm '{}' ';'

real 1m1.811s
user 0m0.904s
sys 0m10.821s

(Ez ua.)

root@ubserv:~/teszt# time rm bla*

real 0m1.266s
user 0m0.564s
sys 0m0.688s

(Gyors)

root@ubserv:~/teszt# time find . -name 'bla.*' -exec rm '{}' '+'

real 0m1.098s
user 0m0.116s
sys 0m0.940s

(Még gyorsabb)

root@ubserv:~/teszt# time find . -name 'bla.*' -delete

real 0m0.925s
user 0m0.112s
sys 0m0.796s

(Leggyorsabb)

"Apró különbség még a Perl kontra find témában az, hogy Perl-ben az opendir() után a fájlnebekre megy a mintaillesztés, és csak ami egyezik, arra csinálok stat()-ot, és nézem meg, hogy az mtime hogyan áll a lejárathoz képest."

strace kimenetet elnézve a find ugyanígy csinálja.

Ha nem adsz meg cmd_rm-et, akkor a configfile kommentje szerint egy beépített rutin végzi a törlést. Lehet, hogy az is megérne egy próbát.

Hja, cmd_rm = /bin/true után az rsnapshot-nak azt kellene hinnie, hogy a törlés sikeres volt. De szerintem az teljesne mindegy, hogy az rsnapshot mit hisz. A lényeg, hogy mivel te magad gondoskodz a törlésről, ezért te tudod, hogy egy másik parancs visszajelzésétől függ, hogy a (tényleges) törlés sikeres volt-e, és azt ellenőrzöd.

Mondjuk annyi gond lehet, legalábbis elméletileg, hogy mivel törlendő könyvtár a _delete.$PID nevet kapja, ezért lehetséges, hogy ha ez a könyvtár kellően sokáig nem kerül törlésre, akkor egy későbbi rsnapshot jobnak ugyanez a pid jut, ezért ugyanezt a könyvtárnevet használná, de az már létezik. Nem tudom, hogy ennek a gyakorlatban van-e akkora valószínűsége, hogy aggódni kelljen miatta, mindenesetre kétlem, hogy az rsnapshot mv-je erre fel van készítve.

( rts | 2013. 06. 04., k – 08:56 )

Akárhogy is forgatod a témát, ebben a konkrét helyzetben a problémádra az SSD-n kívül nincs más megoldás.
Illetve még a netre felhőbe mentés ami meggondolandó, bár ha így megtolod a 100Mbps-en, a szervered elérése nyilván be fog lassulni.

Rakj össze belőle 1TB-ot, a backup mondjuk onnan indul szerintem.

Amin amúgy érdemes lehet elgondolkozni az a flashcache, egy néhány TB-os diszk tömb elé berakni mondjuk egy 64-es vagy 128-as SSD-t, sokat dob rajta, ugyanakkor a kapacitást a diszkek adják.

Én használom, nem backup hanem Virtualbox vm-ek futnak rajta, teljesen frankó és állat gyors.

--
Gábriel Ákos
http://i-logic.hu

Én arra a problémára ajánlottam, hogy a mentések ne fussanak egymásra. Eredeti szöveg: vannak "kis mennyiségű adatok" "nagy mennyiségű adatok" és 16 giga sql. Előbbi és utóbbi úgy saccoltam ráfér 50-100 gigára. Persze ez mentendő tovább egy következő sok terás disk tömbre, long-term tárolásra. Azaz igen, nevezhetjük cache-nek is, csak nem mentem bele ebbe részletes magyarázatba először. My bad.

Először is szeretném mindenkinek megköszönni a segítséget, amelyek alapján sikerült egy áthidaló megoldást találni, az alábbiak szerint:

- az összes mentést sorba állítottam, véletlenül sincs egymásra futás,
- korábbra tettem a mentés indítását
- mysql mentés nem mysqldumpal, hanem innobackupex-el történik
- rsnapshot-ból kilőttem a felesleges verziók törlését
- exclude-ként felvettem a cache kulcsszót
- nem mentem le a mysql data könyvtárt (mármint a /var/lib/mysql-t)
- a törlésre betettem egy egyszerű python programot, egy amolyan csináld magad rm, lényege az, hogy jelentős erőforrás foglalás nélkül törli a kijelölt könyvtárt (és tartalmát),
így egész nap elfuthat senki nem veszi észre

Csodálatos módon a mentés időben lefut, és fele annyi terhelése sincs a rendszernek, mint korábban volt.
Úgy gondolom, hogy a verziók törlésének kihagyása az egyik momentum, ami nagyot lökött, a másik pedig az, hogy nem engedem egymásra futni a jobokat. A harmadik az innobackup mentés, ami 35 perc alatt végez 2 óra helyett.

Persze így is van terhelése a rendszernek, de teljesen vállalható. Az ÁSZF-be fel fogom venni a cache kulcsszó lényegét, és persze erről értesítem is az ügyfeleket (mint minden ÁSZF változásról).

Más.
A kis mennyiség - nagy mennyiség szétválasztása azért volt fontos, hogy a jobokat párhuzamosan tudjam futtatni, a két csoport pedig fájlmennyiségre nagyjából megegyezik. Ez az Én agyam szüleménye, lényeg a két csoport volt, a fejemből pedig ez a fajta csoportosítás pattant ki. Lehet, hogy másnak más módszer jut eszébe csoportosításnak, nekem anno ez jutott.
Amúgy régen az rdiff-backupot használtam, azzal a két csoportot két külön szerverre is mentettem, de az rdiff belebukott, és maradt a lokális mentés.

Az is igaz, hogy ha minden szépen megy, felesleges is a csoportosítás.

Amit még megemlítenék az a duplicity. Kipróbáltam. Dettó rdiff-backup, már ezért nem tetszett, de szerintem lassú volt és sok processzort evett. Amúgy az még talán belefért volna, de egy fájl visszaállítása olyan mennyiségű időt vett igénybe, hogy inkább hagytam a fenébe. Azt még ki sem próbáltam, hogyan kezeli azt, ha tönkre teszek egy mentési folyamatot, de az rdiff-backup nagyon szarul érte meg, így gondolom ez sem túl jól. Az rdiff mentést olyankor gyakorlatilag kilehetett dobni.

Az rsync kiváló eszköz, fapados az igaz, de pont ezért jó. Hálát adok annak, aki anno megalkotta és fejlesztette (és a könyvtárait).

( siposa v | 2013. 06. 04., k – 13:20 )

Az rsnapshotot így használom, hogy ne szaladjanak egymásra a mentések:
a doksiban javasolt négy cron bejegyzés helyett csak egy, naponta lefutó hivatkozás van egy hasonló scriptre: 


#!/bin/bash

rsc=/usr/bin/rsnapshot
# %u 1-7 7
# %d 01-31 01
dw=`date +%u`
dm=`date +%d`

echo -n 'START ' ; date

$rsc sync
[ "$dm" = "01" -o $dm = "1"  ] && $rsc monthly
[ "$dw" = "7"  ] && $rsc weekly
$rsc daily
$rsc du

echo -n 'END ' ; date
#eof

Ehhez az rsnapshotot "sync" módba kell rakni, konfigfájlba: 


sync_first<TAB>1

Cron naponta küldi a levelet a mentés folyamatáról, érdemes figyelni.

( handler | 2013. 06. 04., k – 20:55 )

Egy gepen belul tul sok metaadat lesz a filerendszeren - a sok metaadat miatt a diskek semmi mast nem fognak csinalni, mint seekelni. Nezd meg a mentes ideje alatt mennyire vannak a diskek kihasznalva (iops, queue length, stb.)

1TB disket egeszen gyorsan vegigolvasol szekvencialisan (100MB/sec ~3ora), ha kizarolag az a thread dolgozik. Ugyanezt a teruletet 512byte-os darabokban mar seekenkent 15ms-et szamolva mar ~17+ napig tart vegigolvasni...

A filerendszer nem adatbazis - hagyomanyos diskeken nem fog hatekonyan mukodni egyetlen file alapu linkes buveszkedes sem sok (100+) millio file eseten.

Annál azért jóval kevésbé hatékony :-P Bár az egész azon _is_ múlik, hogy a tényleges használathoz mennyire jól van kitalálva a tárolási struktúra... Ha pl. keletkezési időpont alapján kell a fájlokkal nagy tömegben műveletet végezni, akkor a keletkezés idejét célszerű az útvonalban felhasználni, hiszen így fájlonként egy stat() hívást, meg a visszaadott adatstruktúra feldolgozását meg lehet spórolni. Pár millió fájl esetén ez nagyon sokat jelenthet.

az ironport nevu spamszuro cucc alatt allitolag egy sajat fs (nevezzuk most mailfs-nek) tarolja a leveleket, ami nyilvan erre van kihegyezve. De a hagyomanyos fs-ek sem azonos hatekonysaggal kezelnek pl. egy vagon kis file-t egy konyvtarban. Mindenesetre az egyszeruseg es (kb.) agyonverhetetlenseg mellettuk szol.

Diktatorok kezikonyve