Adatmentés 3TB körül

Red Hat, Fedora, CentOS

Sziasztok,

3TB körüli mail adatot kellene lementeni, és rendszeresíteni a mentést napi szinten. Eddig dirvish-t használtam, de 3TB úgy gondolom már egy kis átgondolásra szorul. Jöhetnek az ötletek.......

Köszi

  • 12076 megtekintés

( Fisher v | 2014. 05. 28., sze – 21:23 )

Először kéne még pár adat:

- mbox, maildir, exchange, egyéb
- napi delta
- os?
- megőrzés, archiválás időtartama
- meglévő hw/sw környezet, úgy a hálózatra mint a meglévő(?) backup tárra
- mentési időablak
- mennyi idő lesz visszaállni

Ezek amik így hirtelen eszembe jutnak, de tuti lesz még pár, amit azok tesznek fel, akik otthon vannak a témában.

Lassan olyan kérdések lesznek, hogy "Van egy problémám, ötletek?" Csak központozás nélkül.

- maildir, dovecot
- napi delta ?? jó kérdés, legyen 3GB
- Fedora 20
- megörzésnek 1 hét elég
- jelenleg synology nas van, iscsi. De ide is jöhet ötlet.....
- mentési időablak, nem tudom mit jelent....
- ezt sem......

--
r@g3
jáTék0s l1NuX [http://www.youtube.com/user/gerig0d]>

köszi a helpet

- az első mentésre max. 12 óra, amíg le lehet lőni az smtp-t, de lehet 30 óra is, de akkor mennie kell az smtp-nek.
- 1 éjszaka (kb. 23-06-ig) a napi mentés
- nincs jelentősége, csak legyen meg

--
r@g3
jáTék0s l1NuX [http://www.youtube.com/user/gerig0d]>

Ha az MTA-t queue-only módba teszi, akkor a bejövő levelek az MTA queue-ban fognak állni, nem továbbítódnak az user felé. Tekintve, hogy az user úgy sem tudja használni a szolgáltatást, ez nem extra probléma. A helyreállás után visszaáll az MTA is normál módba és kap egy flush queue utasítást, így az összes, a restore művelet ideje alatt beesett levél ekkor kerül kézbesítésre...
Mit is kéne mivel összemergelni? ;-)

( Tassadar v | 2014. 05. 29., cs – 08:07 )

Az nem opció, hogy az smtp-n keresztül menő leveleket két helyre is tárolod?
Az az érzésem, hogy 3TB-nyi maildir átnyálazása nem lesz egyszerű feladat.

továbbá --backup --backup-dir=
És már van a téves törlésre is akár hetekkel később észrevéve is megoldás.

Sok millió mail listázása: igen, listázni kell. Beleolvasni csak akkor, ha a mappa listázása során az látszik, hogy a méret vagy módosítási idő megváltozott volna. Legalábbis az rsync alapból ezt teszi.

( igor | 2014. 05. 29., cs – 08:53 )

backupninja-ban van egy maildir modul ami domain/maildir alapon végzi az rsync-et, így egy csomó időt megspórol azzal, hogy a file list összeállítása gyorsan lefut. Párhuzamosan több fiókot ment. Hardlinkeket használ.

Évek óta használom, van ahol több száz domain többezer fiókját menti, stabil, nem hibázik, 5 perc beállítani.

( Fisher v | 2014. 05. 29., cs – 10:00 )

Azzal kezdeném, hogy csinálnék egy rsync dry-run-t, hogy lássam, hogy a mentési ablakba belefér-e az, ha fájlonként történik a mentés, mert a 3T maildir az jó eséllyel sok-sok fájlt jelent. Ha a dry-run épeszű időn belül lefut, akkor az már valami, mert valószínű, hogy nem a 3G adat átmásolása lesz a sok, hanem a megkeresése.

Nálam a 150G maildir kb. 600,000 inode, ami vagy jelent valamit, vagy nem, de kb. jó lehet alapnak.

Összességében nem tudom az rsync hogyan kezeli a dolgait.
a) helyben megkeresi az összes állományt, azok adataival majd átküldi -> egyszeri, nagyobb hálózati terhelés, de nagy memóriahasználat szükséges
b) folyamatos a keresés és a talált állományok adatainak átküldése -> kisebb memóriahasználat és hálózati terhelés, de valószínűleg jobban elnyújtva

Ha az a) eset van, akkor több részre szétszedett rsync parancsokkal memóriahasználatot nyer.

Közben ezt találtam: http://dovecot.org/list/dovecot/2012-July/084576.html , igazolja azt hogy az a) eset van és jobb szétszedni több rsync-re az egészet. Pláne Dovecot-hoz tanácsolták, mint ami a kérdés feltevőjének is van.

Ohm, hat ez igy ebben a formaban nem igaz, hogy az a) eset lenne. Az rsync mukodese ugyanis a parametereitol fugg.

Alapesetben, ha nincs hasznalva a --delete-before / --delete-after kapcsolok egyike, akkor parhuzamosan fut a kereses es az adatok atkuldese, altalaban a kereses joval elorebb jar, puffereli a fajllistat. Ha valamelyik a fenti kapcsolok kozul hasznalva van, akkor eloszor van egy baromi nagy lookup, felszivja a memoriaba a komplett fajllistat, atkuldi, a masik oldal hasonlokeppen atnyalazza a sajat rendszeret, toprengenek egy sort, majd szinkron.
-- 

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

Igazabol ezt vagy kivaltja egy rsync, vagy nem alkalmas a feladatra. Feleslegesnek erzem meg egy kort futni a dovecoton keresztul is, mivel maga a fajllista felolvasasa a timeconsuming taszk, nem a tenyleges mentes. Raadasul 3T levelezesnel eleg sok user is lehet, felesleges darabonkent vegigiteralni (a dsync darabonkent kepes foglalkozni csak userekkel, egyszerre az osszessel nem, es a helpje alapjan keptelen vegigiteralni a fiokokon, mint a doveadm).
-- 

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

Nem kell dovecot:
"dsync can be run completely standalone. It doesn't require any Dovecot server processes to be running, except when using -u parameter to do a userdb lookup from auth process."

Nem kell fájlistát olvasni:
"dsync can access Dovecot's index logs that keep track of changes."

Az egyszerre egy user valós probléma, kérdés hogy mekkora.

Az igazi problémát ott látom, hogy a dsync nem backupra való.

A következők miatt nem alkalmas (szerintem):

- Nem lehet visszaállítani a törölt leveleket. Nem azokat, amiket a kukába tettek, hanem azokat amiket véletlenül vagy szándékosan töröltek.
- Nem figyeli(?) a fájlok tartalmának változását, mivel az indexet figyeli csak(?). Ezzel talán együtt lehet élni, feltételezve, hogy mindig minden remekül fog működni, de épp ezért írtam, hogy emellett azért kéne egy olyan mentés is, ami nem ilyen okos.
- Nincsenek meg a korábbi verziók (pl. draftból), sőt egyáltalán nincsenek verziók, nem lehet bizonyítani, hogy egy levél három héttel korábban még tartalmazott valamit - vagy nem.
- Ha a mentési oldalon valami sérül, akkor az sérült is marad ("Any changes done in destination are discarded"), és sose veszi észre senki(?).

Talán még volt valami a fejembe, de reggelizés közben elfelejtettem.

Amúgy lehet hogy tévedek, csak a manpage-t néztem át.

Höhö... azért egy törölt levél visszaállítása ne legyen már az archiválás feladata. Az se csak az archiválás feladata hogy több verziót tároljon (sőt).

Ha az indexek alapján dolgozik, akkor ugye az általam említett probléma fennál: ha a mentett adat megsérül, akkor az sose derül ki, és nem lehet visszaállítani (ami amúgy ugye célja a backupnak).

Meg szerintem a többi se az archiválás dolga. De persze kérdés ki mit nevez backupnak és mit archiválásnak.

Megsérül az éles levelezés, vissza kell állítanod a backup-ot.
Csak az összes törölt levéllel együtt fogod tudni, jó lesz ez így?

Az éles rendszeren levő index-el dolgozik, ha az megsérül, azt észre fogod venni (legalábbis, gondolom a dovecot ellenőrzi, ha már azzal dolgozik).

"Nem azokat, amiket a kukába tettek, hanem azokat amiket véletlenül vagy szándékosan töröltek."

Tehát törölték a kukából is. Véletlenül. Kéne. Hol a mentés?

Ha az index sérül meg, akkor igen. De ha nem az index sérül meg? 


o# du -sh *
5.8G    cur
2.2M    dovecot.index
18M     dovecot.index.cache
4.0K    dovecot.index.log
19M     dovecot.index.search
100M    dovecot.index.search.uids
4.0K    dovecot-keywords
4.0M    dovecot-uidlist
0       maildirfolder
288K    new
1.7M    tmp

Az adatterület jóval nagyobb, nagyobb az esélye, hogy ott történjen gonosz dolog (ami persze nem így igaz, de demagóg kijelentésnek épp jó).

Szerintem itt eltérő fogalmakat használunk. Számomra a mentés rendszeres, rövid időközönként lefut (naponta vagy akár óránként), megőriz valamennyi verziót, valamennyi, de véges időre, hogy egy valamilyen időpillanatra vissza lehessen állni. Lehet teljes, inkrementális vagy differential (mi a magyar megfelelője?).

Az archiválás ezzel szemben ritkán (havonta, évente és/vagy amikor szükség van rá) fut le, egy (végleges?) állapotot rögzít, úgymond "örökre" megőrzésre kerül. És ide már kb. minimum elvárás a rendszeres integritásellenőrzés.

A mail (smtp) archiválás, ami a bejövő és kimenő levelek egy halomba gyűjtését jelentheti pompás dolog, de ugye nem véd az imap folderben létrejövő draftok véletlen törlése ellen, se az imapon keresztül fekerült leveleket nem tárolja. Hacsak nem imapon keresztül készül folyamatos archívum, amiből sose törlődik semmi.

Szerintem.

"A mail (smtp) archiválás, ami a bejövő és kimenő levelek egy halomba gyűjtését jelentheti pompás dolog, de ugye nem véd az imap folderben létrejövő draftok véletlen törlése ellen, se az imapon keresztül fekerült leveleket nem tárolja. Hacsak nem imapon keresztül készül folyamatos archívum, amiből sose törlődik semmi."

Amikor létrejön egy új elem bármelyik mappában, vagy törlésre kerül, azt az imap loggolja.
Mivel maildir-ről beszélünk, az adott elemet (fájlt) simán tudjuk másolni/mozgatni.

Tokeletesen mindegy, hogy a dovecot serveren vagy a dovecot liben keresztul banyaszkodja le a user adatokat, nem a dovecotos kor a draga benne, hanem az userdb lookup, ami 3T-s levelezesnel feltetelezhetoen LDAP/SQL-ben van tarolva.
-- 

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

( gthomas | 2014. 05. 29., cs – 13:37 )

btrfs snap, aztán send ?
Ő tudja a legjobban, hogy adott pont óta mi változott.

( Szenti v | 2014. 05. 29., cs – 20:17 )

Bár közel sem mentek ekkora adatmennyiséget, de én a DAR-t használom Maidir formátumú postafiókok mentésére. Hónap első napján full mentés, majd napi inkrementális mentés az előző napihoz viszonyítva.

( uid_4656 v | 2014. 05. 30., p – 15:30 )

Ha működik, akkor maradj a dirvish-nél, miért váltanál?

Ha nem működik, akkor meg kell találni az indokot, hogy miért. Erre az lenne a tippem, hogy a dirvish (meg az összes többi hasonló program, amelyek mögött rsync van valahol) úgy működik, hogy végig kell olvasnia a szinkronizálandó részt a fájlrendszeren. Ez sok pici fájl esetén elég vacakul tud működni. Ha ebbe ütköztél, akkor azzal érdemes próbálkozni, hogy nem a fájlokat, fájlrendszer szinten mented, hanem a mögöttes block device-t. Nagy lehet a különbség, mert nem kismillió fájlra kell egyesével rá-seek-elni, hanem a block device-t olvashatod végig szekvenciálisan.

A gyakorlati kivitelezésre működik pl. az LVM vagy a storage szintű snapshot, majd a snapshotolt device másolása valami jó gyors módon (pl. dd-vel, vagy ha a másoláskor a hálózat a szűk, akkor akár rsync-kel is).

Másik jó megoldás lehet 3 diszk RAID1-ben, amiből az egyiket kirúgod a mentés idejére, és a kirúgott diszket dd-zed máshova.

Ha van alatta VMware-ed vagy Hyper-V-d és még pénzed is van egy kevés, akkor meg Veeam a jó megoldás erre.

Ez csak a fájlrendszer épségét próbálja garantálni, de azt, hogy adat nem vész el, azt egyáltalán nem. És mivel a disk offline a mirrorból, a mentőszoftvernek esélye nincs arra, hogy észrevegye hogy mentés közben a fájl megváltozott és újramentse vagy naplózza és majd a humán eldönti hogy wtf. Szóval minimum felvet pár kérdést, bár lehet hogy van olyan spéci eset, amikor bevállalható, pl. DRBD, egymástól valamilyen szempontból messze lévő gépek között.

Ez az egyik gond, a másik, hogy a visszarakás után nem igazán hiszem, hogy "okosan" szinkronizálna vissza a raid, és csak a módosult blokkokkal foglalkozna, de cáfoljatok meg. Ekkora diszknél meg egy raid rebuild jó sokáig eltart, jó kérdés, hogy a rebuild meg a tömbből kivett diszkről való másolás ideje belefér-e egy napba (feltéve, hogy napi mentést kell csinálni)? Ha nem, akkor a dolog azonnal okafogyottá válik.

> nem igazán hiszem, hogy "okosan" szinkronizálna vissza a raid

Mire alapozod a feltevesed?

> belefér-e egy napba

Inkabb egy ejszakaba, nem? Amugy mekkora diszk? Ezen kivul ha akkora(?), akkor deltat masol csak, ahogy irta is.

Teljesen mas problemak vannak reszemrol ezzel a mentessel, de mar lattam mashol is ilyet egyebkent, igy gondolom biztos kielegito.

Amikor "visszateszed" a diszket, akkor arra a teljes 3 TB-ot vissza kell másolni. Ez még 100 MB/s sebesség mellett is bő 8 óra...
Ennél már sokkal jobb, ha a 3. lemezt eleve nem tartod a tömbben, hanem oda teszel egy snapshotot az eredetiről (feltéve, ha az eredeti LVM-en van).

Honnan tudja a raid szoftver, hogy a frissen betolt diszk melyik blokkját kell felülcsapni a futó tömb adataival? A visszaszinkronizálás i/o igényét úgy tudod minimalizálni, ha az újonnan érkezett diszket nem olvasod, csak írod. Persze ha tudsz úgy kivenni tükörből diszket, hogy a megmaradó diszkeken jegyzi, hogy melyik blokk változott, _és_ tudod garantálni azt, hogy a kivett diszken egy bitnyi infó sem módosul, akkor lehet esélyed arra, hogy ne legyen szükség a teljes diszk nulláról újraszinkronizálására.

Tudod garantálni, hogy a kivett diszken egy bit se változzon meg? Vagy ha változik, akkor azt a blokkot a raid szoftver majd, amikor visszateszed a diszket a helyére felismeri "dirty"-nek, és attól függetlenül, hogy a másik diszken változott vagy sem, visszamásolja a tartalmát? Szerintem arra, hogy kiveszem majd visszarakom ugyanazt a diszket khm. igencsak kevés raid megoldás van ilyen szinten felkészítve, úgyhogy 3TB esetén egész pontosan 3TB read és 3TB write következik a (re)sync miatt.

De cáfolj meg, mutass egy olyan raid megoldást, ami képes felismerni, hogy "csak kicsit" tér el a két diszk tartalma egymástól,és emiatt csak az eltéréseket kalapálja ki,nem pedig bután, blokkról blokkra másol a friss diszkre mindent...

Elvileg működhet, de arra nincs garancia, hogy a kivett, majd visszarakott diszken nem változott meg semmi. Ha ezt garantáltan szeretnéd biztosítani, akkor a kivett diszket csak raw device-ként lehet menteni, ami egy elég nehezen használható, rugalmatlan "mentés"-t fog eredményezni... Éles rendszer alatt ilyet nem biztos, hogy csinálnék...

Atyaeg, te komolyan meg akarsz most gyozni?
Ezt csinaljak, a francokat erdekli, mennyire nehez dolguk van. Biztos megvan a jo okuk ra.
Ha Piripocson Kati neni beteszi a penzet a takarekba, akkor abbol pedig feltehetoleg telik ra, abbol lecsippentik a szuksegest a koltsegekre.

Egyebkent en arra gondoltam, hogy van vmi tool, ami segitsegevel csak a deltat kell atkuldeni, de 1 perc alatt nem talaltam. Igazabol nem is erdekel, hujeseg az egesz. De _evileg_ mukodhet.

Az mdraid esetében igen. Ami egy plusz réteg az lvm alatt, egy fölösleges réteg a hw-es raid fölött.

Ráadásul a biztonságos/helyes működéséhez egy marha kritikus feltételt is teljesíteni kell: a kivett, majd visszarakott diszken egy bit sem változhat meg a kiszedés/visszarakás között.

Pedig ezt csináltuk, működött, és a célnak tökéletesen megfelelt. Igazából a 3. lemez fizikailag is átkerült egy másik gépbe, ahonnan a tényleges mentés készült. Aztán visszakerült a két diszk mellé és valami 16 órán át szinkronizált újra, ami speciel tökéletesen megfelelt.

Ehhez _garantálni_ kell, hogy a tömbből kivett diszken semmilyen változás ne történjen. Az mdraid jó dolog. Jó régi - és plusz egy réteg az lvm alatt, ami szintén képes raid-et csinálni, hogy a hw-raid kontrollereket már ne is emlegessem. A raid szétszed/összerak tehát csak speciális esetekben, szigorú feltételek teljesítése esetén alkalmas valamilyen "mentés" készítésére - ha komolyan gondolja valaki a mentéseket, akkor erre a mókolásra maximum az utolsó utáni lehetőségként gondol.

Folyamatosan az porog az agyamban, hogy en nem gondolom azt, hogy csak az mdadm fejlesztoi lennenek olyan marha okosok, hogy ilyen bitmap cuccot kitalaljanak. En persze nem ertek a RAID-ekhez azon felul, amit a BIOS feluleten latok, de ezek nem olyan elvetemult dolgok, hogy csak egy cegnek jusson eszebe. Raadasul az mdadm (kernel oldali resze es a userspace is) open source...
-- 

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

Ha direktbe ir a diskre, akkor rettento dolgok tortenhetnek, de ez igaz kb minden volume manager / filerendszer eseteben.

Ha normal modon mountolja, a raid superblockot is irni fogja:
Time of last superblock update
Event Count for the Array
Checksum of this superblock up to devs[max_dev]

https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

Hacsak úgy nem... őszintén szóval nem emlékszem, hogy amikor ilyet csináltam, akkor a kivett diskből csináltam egy degraded array-t, mert nem volt cél visszarakni a régi helyére, és lehet hogy csak a rajta lévő fs-t mountoltam.

Ha degraded array lesz belőle és használja, akkor van esély rá, hogy a bitmap alapján spóroljon az IO-val. De nekem olyan emlékeim vannak hogy a Linux kernel mindig teljes összehasonlítást csinál egy setfaulty-remove-pöckölés-add után, ezt megcáfolhatná valaki aki nemrég csinált ilyet, most lusta vagyok kipróbálni. Illetve a fene se tudja, hogy úgy általában a raid vezérlők hogy szeretik, mivel itt most épp arról van szó, hogy ha a Linux tudja, akkor mások mért nem?

Ha az alkalmazás nem biztosít saját backup megoldást (ez esetben nem), akkor még mindig a snapshot a legbiztosabb módja a konzisztencia megtartásának.

> mentés közben a fájl megváltozott
A lényegre tapintottál rá, de ez nem érv a snapshot ellen, hanem érv mellette.

Maildir-nél simán előfordulhat, hogy a juzer mozgat egyik mappájából a másikba, miközben épp fut az rsync vagy a cp. A célmappán már végzett, a forrásmappa még azután jönne, hogy a juzer mozgatott. A backupból ekkor hiányzik a mail, elveszett. Még számtalan hasonló gond lehet abból, hogy ez nem snapshoton dolgozik.

A snapshot kiszámítható: ha az alkalmazás figyel arra, hogy az adatai konzisztensek legyenek a diszken, akkor a snapshottal se lesz gond.

Mast nem is kell garantalnia. Azt az alkalmazasoknak kell garantalnia, hogy az adatok barmely idopillanatban konzisztensek.

Tegyuk fel van n darab folyamatosan valtozo file, amely egy vagy tobb alkalmazas resze, legyen file1, file2,...fileN. Adatvesztes nincs, ha adott T1, T2...Tk idopillanatban (jelolje fileX[TY] a fileX TY beli allapotat) idoben a filek globalisan is konzisztensek.
Konzisztens allapot1: file1[T1],file2[T1],...file3[T1]
Konzisztens allapot4: file1[T4],file2[T4],...file3[T4]

Tehat nem lehet olyan, hogy visszaalitaskor file1-bol van egy peldanyod T1 idopillanatbol, file2-bol T4-bol (es file2[T1] <> file2[T4]), stb.

Persze, meg meg kell adni az elsőbbséget a zebránál meg világbéke meg minden.

Először is, ne találjunk ki alkalmazásokat, amik tegyük fel, hogy csinálnak valamit, mert így azt találok ki amit akarok és így bármilyen érvet lehet kalapálni.

Amit te írsz az mondjuk egy oracle DB, az fel van készítve erre. És nem, nem lesz konzisztens a mentés, ordibálni fog, hogy ez meg az a tablespace úgy szar ahogy van, tessék helyrekalapálni archivelogból (mondjuk oracle DB-t lehet pár módszerrel menteni, nem mindig ez a nyerő).

A dovecot (ha az van a maildir felett) bizony nem tud ilyet, az egyik levelet T1, a másik levelet T2 időpontban fogj menteni még a dsync is. Ha ez nem elviselhető (többnyire, nagyonsokkilences esetben az), akkor leállításos mentést kell csinálni, ami leállás időtartama snapshottal másodpercekre csökkenthető. És igen, ha fontos, akkor ilyenkor is meg lehet őrizni az FS integritását, akár úgy, hogy a snapshot idejére umount.

Aztán kitalálhatunk még feltételeket, de lehetőleg legyenek életszerűek.

Ez igaz kozel minden adatbazisrendszerhez hasonlo mukodesre, ami azert manapsag is meglehetosen gyakran elofordul. Egy sima mysql+innodb parost sem tudsz menteni menet kozben valtozo tartalom masolasaval, csak a mysql/innodb egyuttmukodesevel.

Vagy konzisztens snapshotot keszitessz es azt mented, vagy az alkalmazas keszit snapshotot es keszit neked redo logot.

Bizonyos feltetelek fennalasakor lehet valtozas kozben is menteni az fileket, ahol file1blokk1[T1] jeloli a file1 elso blokkjanak T1 idopontban. A lementett adatkupac valami ilyesmi lesz file1blokk1[T1];file1blokk2[T1];file1blokk3[T2];file1blokk3[T];file2blokk1[T2];file2blokk2[T2];..

Konzisztens mentesed lesz a filekrol akkor is, ha T1 idopontban megjelolod az egesz snapshotot, a fileket valtozas kozben mented (T1..T4 idopont valamelyikeben) ES redo logkent alkalmazod a lementett adatkupacra a T4-T1 valtozasokat (pl.:a file1blokk3 valtozott a mentese utan T3 idopontban = redofile1blokk3[T3]; file2blokk1 valtozott T3 idopontban redofile2blokk1[T3];...)

A konzisztens mentes redo logot alkalmazva: file1blokk1[T1];file1blokk2[T1];redofile1blokk3[T3];file1blokk3[T];redofile2blokk1[T3];file2blokk2[T2];..

Az FS-nek minden idopillanatban konzisztensnek kell lennie. Ha nem konzisztens, hogy elne tul egy aramszunetet / crash? A valtozas kozben masolgatunk jellegu mentesek mindent fognak csinalni, csak epp konzisztens mentest nem. Email-nal ez konnyen lehet, hogy nem feltuno, a mailboxok tobbsege valoszinuleg append only.

A mersekelten egyuttmukodo (es / vagy fsync/fdatasync/msync/stb muveleteket hirbol sem ismero) alkalmazasokra tenyleg nincs nagyon mas hasznalhato es konzisztens, mint a (vm) leallitas, egy snapshot idejere. Adatvesztes itt viszont varhato lesz, egy varatlan aramszunet / crash alkalmaval.

Őszintén szólva elvesztem a sok minden között, de mintha én is ezt írtam volna.

Az FS konzisztencia meg olyan, hogy igen, nincs vele gond pl. snapshotkor, de ez csak akkor igaz, amikor minden hibátlanul működik. Ha tényleg szükség van arra, hogy az adott fájlrendszer mentése az adott pillanatban fs és logikai szinten konzisztens legyen, azaz a jelen példánál maradva, benne legyen a mentésben a maildirben lévő email és az 1-2-35 másodperccel korábban/később mentett indexben is, amihez le kell állítani az alkalmazást, akkor én már - mivel úgyis leállunk - umountolnám a fájlrendszert, és arról csinálnék snapshotot, majd indulhat a verkli megint. Persze igen, lehetne építeni az fs hibatűrő képességeire, de miért, ha nem muszáj?

Attól, hogy más megoldásoknak hasonló nyomorai vannak, ez még nem lesz jó. Sőt, ugye ez még annyival rosszabb, hogy a szétrángatott tömböt újra kell szinkronizálni.

Egy előnye van ennek a megoldásnak, mégpedig hogy a mentési ablak áttolható az amúgy terheltebb időszakra, amikor a mentőeszközök jellemzően pihennek (vagy nem, mert archivál és/vagy fésülgeti magát, offsite backupot tol, egyéb), és a tömb szinkronizálása meg fut a nyugalmasabb időszakban (éjszaka, hajnal, vagy ki tudja).

> Attól, hogy más megoldásoknak hasonló nyomorai vannak, ez még nem lesz jó. Sőt, ugye ez még annyival rosszabb, hogy a szétrángatott tömböt újra kell szinkronizálni.

De talan rosszabb sem.

> Egy előnye van ennek a megoldásnak, mégpedig hogy a mentési ablak áttolható az amúgy terheltebb időszakra, amikor a mentőeszközök jellemzően pihennek (vagy nem, mert archivál és/vagy fésülgeti magát, offsite backupot tol, egyéb), és a tömb szinkronizálása meg fut a nyugalmasabb időszakban (éjszaka, hajnal, vagy ki tudja).

Kizartnak tartom, h ez lehet a szempont naluk, vagy ha igen, extra benak. Feltetelezem azert igy csinaljak az adott esetben, mert erre kenyszerulnek, egyedi eset.
Persze majd elmondja, ha akarja. En igazabol mas vilagban elek es az effele gany megoldasokat igenylo cuccokat nem engedem meg es inkabb a tokenel kapom el.

t

A nyitott/iras alatt levo filek allapota soha nem garantalt, es nem is kell garantalni.
Annyit kell garantalnia, hogy az szinkron muveletek pl.: fsync / fdatasync / msync / sync_file_range csak akkor terjenek vissza, ha tenylesen kiirta stabil tarolora (pl.: diskre) az adatokat.

https://brad.livejournal.com/2116715.html

( tompos v | 2014. 06. 10., k – 12:21 )

Ahogy Zizi irta, ha mukodik es nem utkoztel problemaba, ne bantsd.
Ahogy gthomas irta, hasznalj btrfs-t majd snapshot es send/recv. Bar nekem a btrfs-sel meg mindig vannak problemaim. Ezert hasznalj inkabb zfs-t. Bar annak meg mindig a legujabb fedora kernel lesz a problemas. Ja igen, ne hasznalj fedorat szerveren.
Ezen kivul meg nezd meg a burp-ot, annak is a 2-es verziojat.
Ahogy Zizi irta, ha VM-en van, mentsd az egeszet.

A osszes tobbi bullshit.

> megörzésnek 1 hét elég

Azt csak hiszed, de persze ez politikai dontes. Ha technikai, akkor viszont rosszul gondolod.

> mentési időablak, nem tudom mit jelent....

Minel elobb olvass utana a backup-olas alapjainak.

tompos

nemtom, nekem a dirvish ennél kisebb mennyiségeknél is feladta.
illetve egész pontosan az alatta levő fs nem bírta jól (reiserfs, ext3, ext4 mind volt, mind szétesett egy idő után valami rebootkor).
áttérve duplyra ugyanaz a feladat töredék erőforrásból kisebb helyen, nulla fs konzisztencia problémával megy már hónapok óta.

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

Tudnál linket, hogy hol lehet az "alapoknak" utánaolvasni? Már úgy értem, ami szerinted megbízható...
(Elég sokat játszadoztam ilyesmivel élesben, de én a munkatársaktól és az épp használt rendszer doksijából tanultam, talán Solaris tanfolyamon esett pár szó általánosságban alapokról)

Ezzel tökéletesen egyet értek (mármint hogy a többi komoly és hasznos így összegyűjtve és hogy a gyakorlatban valszeg az "a 7-ből válassz 5-öt" elv érvényesül [jó esetben]), de ez akkor is egy nagyon jó reklám :) (mondjuk magát a reklámozott software-t nem találtam meg, a domain-jén futó oldal "Under construction")

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)