Emailek archiválása külön szerverre

 ( Ritter | 2014. szeptember 4., csütörtök - 11:18 )

Nagyon sok email összegyűlt már a jelenlegi Zentyal szerverünkön. Több mint egy millió és közel fél terabyte.
Van aki webmail felületről használja de a többség Thunderbirddel ami elég nagy local cache fájlokat jelent. Régebbi gépeken néha érezhetően lassul a Thunderbird.
Érdemes átrakni a mostani Zentyal szervert egy külön virtuális gépre és csinálni egy másikat az aktuális emaileknek?
A régi leveleket továbbra is be kell állítani a Thunderbirdökbe, de így külön accountként lenne felvéve a régi archív levelezés. Gyorsabb lesz így valamivel?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

eloszor azt kene tisztazni, hogy valoban a TB lassu (mert csillio email van mar a mailbox:// file-okban) vagy a zentyal a lassu, mert az imap(?) demonnak csillio file-t kell kiszolgalni a meghizott mailbox-okbol?

Lehet, hogy meg kell baratkozni az email kvotaval, pl. 2 GB / user, vagy megvizsgalni, hogy egy atlag level ugyan miert 500 kB?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nem lehet kvótázni. A cégvezető a csúcstartó a maga 160GB levelezésével és persze kell neki az elérhetőség az elmúlt 15 év összes emailjére.
A Zentyal webfelülete sem hoz Gmail sebességet de ennek oka lehet az, hogy pusztán az email fejléceknek akkora a mérete ami nem fér be a ram-ba ezért folyamatosan merevlemezről kell olvasni MySQL ide vagy oda.
A Zentyal server cpu idle általában 80% felett van, tehát valószínű tényleg csak a merevlemezműveletek lassítanak be.
Meg talán nem a legoptimálisabb weblevelező a Zarafa (de ez csak a weben levelezőkre vonatkozik). Sogo jobb valamivel?

A TB féle Mork gyakorlatilag egy feltupírozott mbox, így aktívan pörgetnie kell a merevlemezt a kliensnek. Thunderbird sebességén nagyon meg is érződik, természetesen ott ahol hatalmas levelezés van.
SSD bevezetése biztosan segítene valamit. De ettől függetlenül kérdés, hogy érdemes-e szétszedni külön szerverre az archív és aktív levelezést? Gyorsabb lesz úgy?
Mert Thudnerbirdben továbbra is ott lesz minden csak szétszedve két accountra.

B-kérdés: Lehetne olyan másolatot készíteni a levelezés tartalmáról amiben ki van vágva minden csatolt fájl?
Mert ha lenne egy olyan archív amiben csak az email szövegtörzsek vannak csatolmányok nélkül, már azzal jelentősen csökkenne az összméret. A régi levelek átnézésénél általában elég a szövegtörzs.

> Lehetne olyan másolatot készíteni a
> levelezés tartalmáról amiben ki van vágva
> minden csatolt fájl?

Es a csatolt fajlt lecserelni egy url-re a csatolmany meg kimenteni kulon mappaba....

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Van erre bejáratott stabil megoldás? Nem kísérletezhetek a céges levelezéssel.

A Zenthyal az fix, vagy más megoldás is jó?


Linux üzemeltetési, rendszergazdai szolgáltatások

A Zentyal fix.

stubbing a megoldas neve.

Jellemzoen egy imperszonalizaciozott (a micorosoft ezt account impersonation-nek hivja) imap acc segitsegevel (ne kerdezd, hogy a zentyal tamogat-e ilyet) mukodik ugy, hogy a egy program bemegy azzal az acc-cal az egyes userek neveben a mailbox-ba, szepen vegignyalazza a leveleket, majd a mellekleteket kiteszi egy kulon file-ba mondjuk egy file szerverre, whatever, es a mellekletet kicsereli egy html mime part-tal, amiben egy oda mutato link van. Majd a modositott levellel felulcsapja a mar tarolt levelet az imap szerveren.

Nyilvan ezt nem feltetlenul esz nelkul kell csinalni, egy par kB-os gpg alairast pl. szerintem folosleges kivenni a levelbol. Az igazi nyereseg mail szerver oldalon keletkezik, foleg ha mondjuk a 100 cimzettnek elkuldott 15 MB-os excelt deduplikalva tarolod - ami a mail szerveren bizony 100 * 20 MB helyet foglal el. Bar azt is hozza kell tenni, hogy ez azert ad terhelest a mail szervernek, igy ezt jobbara ejszaka szoktak futtatni.

Hogy ezt melyik termek tudja, azt ne kerdezd, a lentebb ajanlott piler (meg) nem...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

http://packages.ubuntu.com/trusty/claws-mail-attach-remover
Ez használható erre? (azt leszámítva, hogy a csatolmányt nem rakja szerverre belinkelve)
A Claws elsősorban email kliens ezért kérdés, hogy visszaszinkronizálja-e a csatolmány nélküli emaileket vagy csak magánál tárolja őket így?

Migralas MS Exchange -re... ott az archivum rendesen meg van oldva.

Az archivum lehetséges, de sajnos sok minden más nem. Kösz de nem élnék a lehetőséggel. :-)

amennyire en tudom az archivumban nem lehet normalisan keresni.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

rosszul tudod

A környezetről lehet pontos infót kapni ?
hw konfig ? sw komponensek ?

Fedora 20, Thinkpad x220

Email szerver Zentyal. Egyelőre a Zarafaval, update tervbe van véve. Azzal Zarafa le lesz cserélve OpenChange & Sogo-ra.
Kliens os: Ubuntu levelező: Thunderbird, illetve egyeseknél a Zentyal Zarafa webmailje.

HW-re lettem volna kiváncsi, mekkora memória, mekkora diskek stb.

Fedora 20, Thinkpad x220

A szerver két Xeon 2.66Ghz összesen 8 maggal, 32GB ram. Ebből a levelező virtuális gépe 6GBram-ot kap és két CPU magot. 1TB-os merevlemez WD RE3 SATA.
A kliensek nagyon változatosak. 4GB ram a legtöbben van. Vannak Core2 duo processzorosak, van Pentium dual-core és van Core i5.

Nem, viszont az email szerver virtuális gépe erről a merevlemezről megy. De nincsenek raidbe kötve a merevlemezek.

Ez egy hatalmas probléma, nagyon-nagyon hatalmas.


Linux üzemeltetési, rendszergazdai szolgáltatások

Lemezt kicseréled ssd-re, és lőn csoda. Persze, ezt úgy kell érteni, h 2db ssd raid1-ben. Esetleg 4db fél terás ssd raid10-ben. És azért megnézném, hogy mennyi memóriát használ a levelező vm, mert lehet kevés neki a 6G memória is.

Jelenleg 270MB a szabad ram, swap használat csak 16MB. De épp most fut a napi autobackup.

SSD tervbe van véve. Szükség van raid-re még ssd mellett is?

Inkább azt nézd meg, h a zentyal mennyit használ. A többi a lemez cache, ami nem rossz dolog, de a hdd-k iops értéke elég gyászos, levelezés pedig tipikusan csillió kis file, ami nem fekszik neki.

Csak ha fontosak az adataid. :) Azaz természetesen igen. Nézz utána, lehet a 4db 512 gigás ugyanannyi, vagy olcsóbb, mint a 2db 1 terás, és akkor már inkább raid10 legyen sata3-on.

1 nagyobb SSD vs. raidbe kötött több HDD kérdésben melyik jobb teljesítményben?

Folyamatos felhős backup van, az adatbiztonság önmagában nem indokolja raidet. Inkább teljesítmény a kérdés.

Folyamatos felhős backup van, az adatbiztonság önmagában nem indokolja raidet. Inkább teljesítmény a kérdés.

es ezt igy hogy? Egyreszt ha meghal az egy szem diszked, akkor a legutolso mentes ota jott leveleidnek annyi. Masreszt ne csak azt nezd, hogy az adataid (nagyja) megvan valahol, hanem azt is, hogy ha a windows telepitesetol kezdve kell a helyreallitast elkezdened, akkor a juzereid also hangon orakat anyaznak, mire az exchange-ed egyaltalan elindul. Aztan mire a felhobol lejon az 500 GB leveled, az sem 2 ora lesz.

Szoval az uzletfolytonossagot (is) szem elott tartva jobb, ha hw raid-ed van. Aztan ha meghal az egyik hdd, akkor kihuzod, majd ugyanazzal a lendulettel tolod be a helyere az ujat. Zero down time, max. egy darabig eltart, amig osszeszinkronizal a 2 diszk.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Majd lobbizok az ügyben.
Raid 1 elég két SSD-vel? Vagy jobb Raid 5 normál merevlemezekkel?

Jelenleg az van, ha meghalna a mail szerver merevlemeze akkor elindul egy ideiglenes email szerver ami fogadja a leveleket.
Mentés bőven van mert napi bakcup mellett szinkronmentés is van a felhőben. Valamint a kliens gépek is szinkron-backupolva vannak felhőbe, amiken a Thunderbirdök is tartalmazzák együtt a teljes levelezést.

Raid5-öt ha lehetőséged van rá SOHA ne használj. Raid6 helyette.
Esetedben jelenleg ssd raid1-ben, lemezeket felejtsd el. Raid5 amúgy sem teljesít valami fényesen, teljesítmény szempontjából sem.
Raid1 pedig azért kell, h ha meghal az egyik ssd, akkor ne tartson napokig egy helyreállítás, hanem menjen szinte folyamatosan, és ne b@szogassanak az userek.
Hw raid az hitvita, nekem eddíg tökéletesen megfelelt a soft. raid, plö mdadm-al. Ekkor nincs az, h megmakkan a vezérlő, és ott álsz egy peches esetben használhatatlan tömbbel.

raid6 is felejtos, szerintem raid10. Nekunk bevalt sok millio mail filehoz.

Fedora 20, Thinkpad x220

Ezt a ha a hw vezérlő megmakkan dolgot jellemzően azok mantrázzák akik életükben nem láttak még rendes RAID (nem ilyen szoftveresen driverből emulált) vezérlőt...


Linux üzemeltetési, rendszergazdai szolgáltatások

+1 a hw raid-re. En jobban szeretem, ha nem nekem kell birizgalni a raid kezelest, hanem a hw eleve egy redundans diszk tombot ad elem, mondjuk egy /dev/sda kepeben.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Arról nem is beszélve, hogy a RAID vezérlőn lévő 1-2 GBájtnyi cache bizony nagyon sokat tud lendíteni a write performancián...


Linux üzemeltetési, rendszergazdai szolgáltatások

bbu-t mindenképpen:) anélkül életveszély

Rendszerben van sok memória. Az kb ugyanazt hozza, mintha egy hw bezérlőn lenne. :)

Ahham, mert a rendszerben lévő memória meg tudja azt csinálni, hogy a sok random írást összevárja, hogy azokat lineárisan tudja kiírni, pl.?

Akkor kérlek magyarázd meg ezt, hogy miért is hoz jobb eredményt egy nem is mai darab p410 a szoftvered raiddal szemben, ha "ugyanazt hozza". főleg mikor nem egy szálú írásról van szó, hanem nagyon sok szálról?


Linux üzemeltetési, rendszergazdai szolgáltatások

Visszakérdezek. Egy sata raid vezérlő meg tudja csinálni?
A mai merevlemezek elektronikája már semmilyen hozzáférést nem ad a lemeztányérokon folyó tényleges folyamatokhoz. SSD-nél meg eleve értelmezhetetlen a lineáris írás.

Hogyan tudná megcsinálni ha nincs memóriája+bbu-ja, hova tárolná az adatokat?

Az összeillő komponensek szépen megbeszélik egymással a dolgokat, persze ha az akvába megveszed a sata vinyot, meg valami kártyát azok nem fognak. Nem véletlenül használnak saját FW-eket a brand gyártók, amik passzolnak a saját raid vagy storage megoldásaikhoz...

De miattam azt használsz amit akarsz, engem más mit használ nem érdekel.

Amúgymeg hogyna számítana SSD-nél is, hiába gyors az SSD, nem végtelen annak se a teljesítménye, memóriába lehet pufferelni, hogy egyenletesebbé tegyük a dolgot.


Linux üzemeltetési, rendszergazdai szolgáltatások

"Az összeillő komponensek szépen megbeszélik egymással a dolgokat"

Erre van valamilyen 5 évesnél nem régebbi hiteles forrásod?
Nincs HP merevlemezgyártás, pláne sata. HP szerverek manualjában pedig nem láttam semmilyen utalást egyedi for HP merevlemeztípusokra vagy speciális HP raidhez való szériaszámokra ami oda ajánlott lenne. Normál merevlemezek mennek HP szerverekbe is. Persze jobb minőség, enterprise széria de azon túl semmi extra.

Minden HP cimkés merevlemez (függetlenül, hogy ténylegesen ki gyártotta) HP-s firmware-el érkezik. Van olyan funkció amit ennek hiányában a HP RAID vezérlő letilt, pl. a legtriviálisabb, nincs SSD wear status, vagy sima hdd esetén pre-failure detection.

Meg miért akarnál random cuccokat berakni, amivel ugrik a support? Nem véletlenül van az a nyavajás lista, hogy mit rakhatsz be...


Linux üzemeltetési, rendszergazdai szolgáltatások

Jellemzően... de nem mindig. Hallottam személyes tapasztalatot komoly admintól, komoly raid vezérlő meghalásáról (típust nem tudok mondani, de megkérdezhetem). Amikor megpróbálták a tömböt életre kelteni egy ugyanolyan típusú vezérlőn, aminek a verziószámának a harmadik tagja tért csak el, nem volt hajlandó észlelni a tömböt.

Többszáz szerveres merítésből (HP és LSI kártyák) megmakkant HW kontroller se sűrűn fordult elő, de, hogy átrakva másik gépbe ne ismerte volna fel aztán végképp. HP-nál oda vissza mindegyik vezérlő tudja mindegyik configját.


Linux üzemeltetési, rendszergazdai szolgáltatások

Aham. Pubikám, én már optam be ezt, nem volt szép történet, igaz volt vagy 15 évvel ezelött. Egy mákom volt, megvolt a levelezés amiben felhívtam a tisztelt vezetőség figyelmét arra, h kellene spare lemez, tartalék egzotikus vezérlő a polcra, valamint rendszeres backup. Mostanában rengeteg kis raides kis szervert adminolok, nem nagy történetek, mind mdadm ssd-kkel. Köszönik, jól vannak, a mai cpu észre sem veszi a plusz terhelést.
No offense, de ma is kiráz a hideg tőle. Egy szint fölött biztos jó a hw vezérlő (8-10 lemeztől felett), de ilyen 2-4 lemezes dolgokhoz halál felesleges szerintem.

Brand szerverrel és brand hw vezérlővel szívtam nemrégen pár hetet. Boot gondok. Illetve nem megy az USB rendesen, leszakad az eszköz. NIC driver egzotikus, nem volt stabil. A drága pénzért kapunk gyárliag 2 PCI-X vezérlőt meg 1 árva NIC-et a szerverbe :D Ezért a pénzért egy teletömött alaplapot veszek a drágább kommersz kategóriából.

Én kizárólag kommersz gépek SOHO cuccokkal soft-RAID-el a jövőben! :)

Ahol az a téma, hogy legyen spare lemez, vagy se, gondolom a legótvarabb vezérlőt veszi meg. Én a HP vonalát ismerem, ott még soha nem láttam meghalt RAID kártyát, ahol cserélve lett ott bővítés miatt lett cserélve (pl. p2xx-es szériáról 4xx-re, vagy volt ahol a G4-ből átraktuk a diszkeket G6-ba, simán ment, pedig a kettő között volt vagy egy évtized...)

Nem hinném, hogy relaváns tapasztalat, hogy te annyiért veszel egy egész szervert amennyi egy rendes raid kártya...


Linux üzemeltetési, rendszergazdai szolgáltatások

Sata helyett van értelme PCI Express SSD-t használni?

Gyorsabb, de jóval drágább. Egy sata3-on levő raid10 is tud 1000-1100Mbyte-ot másodpercenként...

Az a VPS karcsú és valszeg az I/O is gyenge. SSD ahogy írták vagy min 4disk raid10ben sok mag és sok ram. Bár nem tudom mi van a zentyalban, de a courier sürgősen cseréld dovecot-ra csodákra képes.

Fedora 20, Thinkpad x220

Zarafa felelős az IMAP-ért is.

Hogyne segítene, de rossz úton jársz!

Egy külön mail archiváló szoftver (egy külön helyen/szerveren) bevezetése lenne a legjobb, személy szerint a pilert ajánlanám, jó tapasztalatom van vele, fejlesztése és community supportja is jó.

Egy millió körüli archívum (igaz, mérete csak 150GB körül volt) vígan és gyorsan ment egy átlagos 2GB RAM-os VPS-ben, 5-6 egyidejű aktív felhasználóval.

Ekkora levélmennyiség beimportálása eltartana egy darabig, de utána valós időbe lehetne beküldeni az érkező és küldött leveleket, a zentyalban pedig (ha tud ilyet) beállítani, hogy törölje az x időnél régebbi leveleket.

A pilerből IMAP-on keresztül is lehet autholni, így külön a usereket se kéne kezelni, valamint így rögtön IMAP-on keresztül vissza tudja állítani akár a leveleket ha mégis kéne egy régebbi.


Linux üzemeltetési, rendszergazdai szolgáltatások

Ennek a pilernek utána fogok olvasni.

én is

Én is

+1 a hozzászólónak az elméletet tekintve. Én a Mailarchiva (Community edition) rendszert használom több helyen megelégedéssel. Egyszerűen telepíthető, konfigurálható. Dinamikusan konfigurálható store-okat hozhatsz létre, stb... Van saját web-es felülete, illetve el lehet érni saját API-n és egyéb protokollokon keresztül is (ezt a részét még nem használtam) így integrálható más rendszerekkel.

--

kincza

mennyire vagy elegedett a free verzio lebutitott kepessegeivel? Bar a mostani, megujult mailarchiva (download) oldalon mar nem is talalni a community edition-t, hanem azt mondjak, hogy hasznald az enterprise editiont, aztan ha nem kap licencet, akkor 45 nap mulva atvalt 'reduced feature set'-re.

Egy korabbi gyujtesem alapjan par fajo pont, ami hianyozhat: attachment dedup, search query-k mentese, bulk muveletek hianya (pl. egyszerre csak 1 levelet enged visszaallitani, exportalni, etc), levelek cimkezese, integritas ellenorzes, audit(!), ill. ami a legfajobb: nem tudod a mar meglevo leveleidet importalni.

Viszont erdekesseg, hogy 20 mailboxig ingyenes lett az enterprise edition (ill. a 45 napos trial alatt megis importalhatod a meglevo leveleidet). Ez akar boknak is felfoghato. Gondolom, az erosodo open source cuccok fele valo tendalast probaljak meg lassitani... ;-)

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Azért olyan bődületesen sok opensource alternatíva nincsen, ami ilyen kulcsra kész lenne.


Linux üzemeltetési, rendszergazdai szolgáltatások

az is igaz. Az utobbi verziokhoz azert is csinaltam OVA-kat, hogy egy 5 perces beallitas utan mar hasznalhato is legyen. Lehet meg ennel is kulcsrakeszebb?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Egyáltalán mennyi opensource alternatíva van?

nehany egyeb implementacio a mailarchiva (ez igazabol nem open source, csak free of charge) es a piler mellett:

- http://www.openarchive.net/
- http://www.enkive.org/
- http://www.openkm.com/

probald ki mindegyik online demojat is!

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nem fogalmaztam teljesen pontosan :-) Korábban a community edition-t használtam és nem volt vele probléma. Az ügyfelekkel közöltem, hogy ez ingyen ennyit tud, ha több kell, akkor vegyenek teljes változatot.
Mostanában viszont már a gyártó oldaláról elérhető free változatot használom. Abban már van pl. attachment dedup is. Tulajdonképp egyetlen célunk szokott vele lenni, hogy utólag, ha valamilyen mail-re esetleg szükség van (pl.: bizonyítás céljából), akkor azt vissza tudjuk keresni. A felhasználók felé nincs is kiajánlva, legtöbb esetben a cégvezető kap auditor jogot, ha meg kell keresni valamit. Ha valami fontos, akkor az úgyis bekerül az ügyviteli rendszerbe és ott dolgoznak vele tovább. Policy szerint nem is nagyon engedünk néhány GB-nél nagyobb postafiókot, mert nem életszerű felhasználás több éves leveleket kincsként eltárolni és utána a rendszergazdát cseszegetni, ha a levelező kliens döglődik.
--

kincza

"mert nem életszerű felhasználás több éves leveleket kincsként eltárolni és utána a rendszergazdát cseszegetni, ha a levelező kliens döglődik."

Hát igen! :-)
Magyar cégvezetők körében sajnos jellemző ez a 'minden legyen meg hátha később szükség lesz rá' hozzáállás. Javukra legyen mondva, hogy ilyen gyorsan változó szabályozások mellett igazuk lehet.
Ami viszont roppant utálatos dolog, hogy szeretik chatként használni az emailt.

Policy szerint nem is nagyon engedünk néhány GB-nél nagyobb postafiókot, mert nem életszerű felhasználás több éves leveleket kincsként eltárolni és utána a rendszergazdát cseszegetni, ha a levelező kliens döglődik.

Gmail ota ez nagyonis eletszeru...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Mail Server/s

Microsoft Exchange 2000/2003/, Postfix, Sendmail, Qmail, iMail, Lotus Notes, AXIGen, Communigate Pro, Neon Insight, Zimbra and others

Bár nincs nevesítve de remélem az and othersben a Zarafa is benne van.

ha meg tudod azt csinalni, hogy egy kulso email cimre copy-zod az osszes levelet, akkor tuti

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Általánosságban miben jobb ezeknek az email archiválóknak az alkalmazása egy normál inaktivált levelezővel szemben?
Gyorsabb a működése? Levelezőkliensnek kevesebb terhelést jelent?
Úgy értem leklónozzuk a jelenlegi levelezőt, kikapcsoljuk az smtp-t, a bejövő emailek pedig természetesen nem ide lesznek irányítva. Az eredetin pedig töröljük a régi leveleket.

Integritás biztosítása.

Ez így elég általános.

az email archivum mas jellegu szolgaltatasokat biztosit. Egy mail szerver csak tarolja a leveleket, es ennyi. Csak izelitokent: az archivum indexeli azokat, kereshetove teszi, auditra kepes, gazdasagosabban banik a diszkkel a deduplikacio miatt (mondjuk a free mailarchiva pont nem).

OK, egy imap klienssel is tudsz keresni keresni a zarafaban, de egyreszt probalj meg mondjuk az osszes mailboxban keresni, masreszt talalj meg valamit a body-ban mondjuk a fonok 160 GB-os mailboxaban. Beszarik a geped tole, mig az archivum par sec alatt kikopi akar egy komplex kereses eredmenyet. Arrol nem is beszelve, hogy igy a leveleid 2 helyen vannak, amibe bele van kodolva a szivas, ha meg kell talalni valamit.

Ha pedig egy user (valamiert) torol egy fontos levelet, akkor azt buktad. Az archivumbol nem tudnak a userek torolni.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

A levéltörlés elleni védelem most is meg van oldva az éles levelezőn snapshotolással. A keresés valóban elég tetű, bár lehet keresni a bodyban is de csak userenként.
Szóval ezek szerint mindenképp érdemes lesz bevezetni valamelyik archiválót.
A fent írtak közül te melyiket ajánlanád?

nekem a piler-rel van nagyobb tapasztalatom, igy azt ajanlom. Ha virtualizalt kornyezeted van, akkor egy thin provisioned OVA importalasa utan 5 perccel mar mukodo archivumod lehet.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Konkrétan te fejleszted nem? No, azért az más tapasztalat :)


Linux üzemeltetési, rendszergazdai szolgáltatások

jo, hat konkretan en fejlesztem, de nem akartam ezzel befolyasolni a kerdezot :-)

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Az nem hátrány ha első kézből lehet választ kapni a felmerülő kérdésekre :-)

Es csatolmanykiemelest tervezel valaha is?

Mert baromi jo lenne,hogyha ki tudna emelni kicserelni, es nem csak egy linket a fajl nevere dobna be, hanem minimalis infokat is, amire lehetne keresni

(pl. fotoknal exif infokbol kiemelni a fenykep idejet, gps-et ha volt. .zip-nel a benne talalhato fajlneveket, .doc(x)/.odt-nel az elso oldalt zanzasitva, .xls(x)-nel pedig a tablazat fuleinek a neveit, es az elso ful tablazat elso sorat)

Egyebkent van olyan kereses, aminel az embert nem erdekli ha egy ejszakat is igenybevesz.... (pont ezt nem szeretem a gmail-nel)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

a valamikori jovoben tervezett feature a stubbing, de valoszinuleg nem mostanaban lesz, es nagyon ki kell tesztelni.

Btw. tegnap importaltam egy francia cegnel egy 70 GB-os gyujto mailboxot, es ebbol csak az attachment deduplikacio 12 GB-ot sporolt meg pluszban, igy ~43%-on elfertek a levelek. Bar ebben a sphinx indexek nincsenek benne, azzal egyutt tan 50% is kellett...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Hogy csinálod a dedup-ot?

a kiollozott mellekletre szamolok egy sha256-ot, aztan ha legkozelebb is latom ezt a szamot, akkor az egy masolat, es eldobom.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

A hash szerintem önmagában kevés. Pár éve amikor hasonló módszerrel (md5-tel) deduplikáltam egy párgigás képgyűjteményt akkor volt hogy teljesen különböző file-okra jött ki azonos hash.

egy bizonyos meret felett (ami most nem jut eszembe) valoban elofordul hogy azonos md5 kluonbozo file-oknal jon ki.
sha1-et kell hasznalni.

biztos lehetseges sha256-tal is collision-t gyartani, de azert imho nem olyan egyszeruen, mint md5-tel...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nyilván nehezebb, ezt nem is vitatom, viszont lehetséges. És ha a mail archívumodból épp egy fontos csatolmányt szelektálsz ki collision miatt, akkor szopó van.

ez igaz, bar kisebb az eselye, mint hogy egymas utan 10x megnyerd a lotto otost. Lehet, annyiban finomitom a dolgot, hogy az sha256 sum mellett a meretnek is meg kelljen egyeznie a dedupolashoz. Igy mar ok?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Nem nekem kell, hogy ok legyen. A Te terméked és a Te ügyfeleid adatairól van szó.
És ne érts félre: nem fikázni akarok (sőt!), csak felhívtam a figyelmed egy potenciális hibalehetőségre, ami adott esetben súlyos következményekkel járhat.

Kicsit utánaolvastam, a zfs-ről írták: "SHA256 has only a 2^-256 probability of producing the same output given two different inputs, then it is reasonable to assume that when two blocks have the same checksum, they are in fact the same block. You can trust the hash. An enormous amount of the world's commerce operates on this assumption, including your daily credit card transactions. However, if this makes you uneasy, that's OK: ZFS provies a 'verify' option that performs a full comparison of every incoming block with any alleged duplicate to ensure that they really are the same, and ZFS resolves the conflict if not.
...
Given the ability to detect hash collisions as described above, it is possible to use much weaker (but faster) hash functions in combination with the 'verify' option to provide faster dedup. ZFS offers this option for the fletcher4 checksum, which is quite fast"

Nem nekem kell, hogy ok legyen.

elmondtad a velemenyed, figyelembe vettem, de erdekel, hogy a javasolt modositas szerinted koser-e? Bar en is ugy gondolom, hogy az sha256 eseten az utkozes sokkal kevesbe sanszos, mint az md5-nel, de nyilvan megvan a maga valoszinusege.

Btw. en ezt az ervelest talaltam a temaban (http://stackoverflow.com/questions/4014090/is-it-safe-to-ignore-the-possibility-of-sha-collisions-in-practice):

The usual answer goes thus: what is the probability that a rogue asteroid crashes on Earth within the next second, obliterating civilization-as-we-know-it, and killing off a few billion people ? It can be argued that any unlucky event with a probability lower than that is not actually very important.

If we have a "perfect" hash function with output size n, and we have p messages to hash (individual message length is not important), then probability of collision is about p2/2n+1 (this is an approximation which is valid for "small" p, i.e. substantially smaller than 2n/2). For instance, with SHA-256 (n=256) and one billion messages (p=109) then the probability is about 4.3*10-60.

A mass-murderer space rock happens about once every 30 million years on average. This leads to a probability of such an event occurring in the next second to about 10-15. That's 45 orders of magnitude more probable than the SHA-256 collision. Briefly stated, if you find SHA-256 collisions scary then your priorities are wrong.

In a security setup, where an attacker gets to choose the messages which will be hashed, then the attacker may use substantially more than a billion messages; however, you will find that the attacker's success probability will still be vanishingly small. That's the whole point of using a hash function with a 256-bit output: so that risks of collision can be neglected.

Of course, all of the above assumes that SHA-256 is a "perfect" hash function, which is far from being proven. Still, SHA-256 seems quite robust.

De a legaszabb az egyik kommentelo sommas velemenye:

"I can now rest easy knowing that I'll likely be wiped out by an asteroid long before I live to experience an SHA-256 collision"

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

A javasolt módosítás szerintem jelentősen csökkenti a collision amúgy is kicsi esélyét, és az erőforrásigénye gyakorlatilag nulla, szóval szerintem érdemes implementálni.

Viszont én mindenkép javasolnék egy verify opciót is, amivel binárisan összehasonlítja a file-okat purgálás előtt. Ez lehet default off, de jól jöhet olyan esetben, ha a megbízónak ilyen elvárása van.

Ha ezt 10 millio file-al csinaltad, akkor ennek valoszinusege kb. 1.47*10^-25. Ennel picit valoszinubbnek tunik hogy elneztel valamit.

--
"You're NOT paranoid, we really are out to get you!"

Jóval kevesebb file-lal csináltam, volt egy nagyobbacska "pics/unsorted" nevű mappám, amiben volt minden: kirándulós képek, vicces képek, repülős képek, stb., pár év termése. Valami script-tel gyártottam md5-öt mindhez, aztán nekiálltam azt a párszáz duplikációt kézzel purgálni, és erősen elcsodálkoztam hogy a két file mérete eltér egymástól. Szóval ellenőriztem még egyszer, és tényleg ugyanaz volt a hash-e két eltérő képnek.
Egyszer futottam bele, de azóta nem bízok a kizárólag hash-alapú azonosításban.

Szerk.: utánéztem kicsit, ezt találtam: http://www.mathstat.dal.ca/~selinger/md5collision/
Letöltöttem a 2 exe file-t és ez az eredmény:

$ ls -l *.exe
-rw-rw-r-- 1 tamas tamas 6144 Sep 9 16:03 erase.exe
-rw-rw-r-- 1 tamas tamas 6144 Sep 9 16:03 hello.exe
$ md5sum *.exe
cdc47d670159eef60916ca03a9d4a007 erase.exe
cdc47d670159eef60916ca03a9d4a007 hello.exe
$ sha256sum *.exe
1316543942a8c6cd754855500cd37068edbbd8b31c4979d2825a4e799fed6102 erase.exe
60d13913155644883f130b85eb24d778314014c9479aedb5f6323bf38ad3a451 hello.exe

Mondom mashogy: az, hogy 2 random fenykeppel md5 collisiont csinaltal, gyakorlatilag lehetetlen. Ennel sokkal valoszinubb, hogy:
- elrontottad a scriptet es elnezted az eredmenyt
- elrontottad a scriptet es az eredmenyt 30 ember elnezi egymas utan
- talaltal egy hibat a filerendszerben/md5 libben, stb
- betalalta a memoriat a kozmikus sugarzas
- valaki felnyomta a gepedet es szorakozik

A link nem relevans, mert itt ket random file-rol van szo es nem szandekos collision-rol. Pl. CRC64 utkozest generalni szandekosan nem bonyolult, de hogy random kijojjon, az nem tul valoszinu.

De ha megis igazad van, tedd fel azt a ket kepet valahova, hires leszel. :)

--
"You're NOT paranoid, we really are out to get you!"

A script gondolom valami olyasmi lehetett, hogy:
find ... md5sum ... >hashfile
sort hashfile | uniq c | grep ... >dupes

Azért nem egy rocket science. Aztán lehet hogy elrontottam, de utána a két file-ra egyenként is toltam md5sum-ot, és ugyanazt adta. Persze lehet hw hiba meg minden más is, de a benézést szinte kizártnak tartom. Annyira nagyon nem is lepett meg, mégiscsak egy hash függvény.

A két kép meg fingom nincs hogy hol van, valszeg valamelyik DVD-n a sokszázból, tervbe van véve a feldolgozása, már évek óta tervbe van véve. Ha egyszer megint megtalálom ígérem értesítelek :)

En amikor ilyet implementaltam akkor md5sum+meret volt a feltetel.

Van nekem is par fajlom aminek az md5sum osszege egyezik. (vagy 3 osszesen). De olyan egy sincs aminek az md5sum+merete is egyezzen.

A meret egyebkent is nulla eroforrasigeny. Szerintem veszteni nem vesztesz vele semmit se.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Maildir alapú levéltárolás kevésbé viseli meg a HDD-t a szerveren, hiszen minden email külön fájl és csak az első 1..2 kB-ja lesz alapból felolvasva (és a szerveren a memóriában bufferelve) a csatolmányos MB-nyi tartalom átnyálazása helyett.

Ellenben kliens oldalon a Thunderbird tudtommal mbox formában tárolja a levelet (alapból letölti offline munka képesség miatt) ami miatt végig kell nyálaznia és ez igen lassú. Kivéve ha letiltod a levéltörzsek letöltését.

Mork formátumban tárolja a Thunderbird, mbox plusz segédfájlok. Szóval ugyan nem kell végignyálaznia több GB adatot a mail fejlécek után de a levelek tartalma sajnos mbox-ban van.

en egyik cegnel thunderbirdot maildir formatumba allitottam be, es a maildir pedig halozati megosztason van.

3 geprol hasznaljak a thunderbirdot, egy megosztassal. Tipikusan nem egyszerre. Mar 2 eve igy megy (vagy 4?), es semmi gond.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Mennyire stabil és támogatott a maildir Thunderbirdön? Mennyi levelezést kezel egy Thunderbird kliens?

Stabilnak stabil. A támogatottat hogy is kellene érteni? Szerintem nem tudsz kereskedelmi támogatást venni Thunderbirdhoz.

Szerintem probald ki, ha bejon, hasznald, ha talalsz benne bugot felejtsd el, ugyse tudod oket ravenni, hogy javitsak a te piti kis hibadat:-|

Hat van ugye gmail mogotte, ott allandoan torolni kell, mivel 15GB-ot mindig surolja.
Napi sztem 100 level jon arra az egy accountra.

En pont azert tertem at, mert valahogy a 4GB-os hatarba beleutkoztem anno.

De megy azota is, nagyon nem szoktam bokodni. Azt se tudom, hogy vegulis a thunderbird epp melyik verzioja van fenn ott(eredetileg a csirketojasost kellett feltenni:).

Multkor jartam arra, lattam, hogy hasznaljak egeszseggel.

Ha gond lenne vele, akkor biztos tudnek rola...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Update. Sajnos nem eléggé stabil a maildir Thunderbirös implementációja. Nem véletlenül experimental. Kicsi levelezések mellett jól teljesít, de negyvenezer emailes mappáknál rosszabb és lassabb mint a jó öreg Mork.

sub

sub

Gondolom ismeritek azt a szitut mikor az ember egyre tobb es tobb infot olvas egy temaban es mar ott tart, hogy amit az elejen tudott mar az se biztos, bekavarodott.

Keresgelek itt a hup-on is megpedig imap, sok kicsi fajl es raid10 4 diszkel stripe meret ugyeben.
Mint irtam is, mar ugy bekavarodtam, hogy magam is azt mondom borzalmas. :)
Egyik iranybol az az info jon, hogy imap eseten sok kis fajl van ami random olvasas/irasahoz vezet ezert kis stripe jo, pl 64k mashol meg azt javasoljak hogy akkor inkabb legyen minel nagyobb a stripe meret.

Mar neztem a particiok rendesen alignolva vannak-e, neztem a filerendszer blokk meretet, stb.

Olvasva ezt a topikot lattam komolyabban hozzaertok is szoltak. Kerhetnek nemi iranymutatast, hogy kibogozodjon az agyam?

A legjobb teljesitmeny eleres erdekeben, amit egy adott hw vezerlo tud szeretnem atlatni, hogy a raid stripe merete milyen kapcsolatban kell legyen a filerendszer blokkmeret es a formazaskor megadott egyeb parameterekkel, mire kell odafigyelni, szamolni, kell-e egyaltalan ezen agyalni vagy "default" ertek az adott fajlrendszerhez elegendo (aktualisan ext4). A felhasznalas modja szerint (most epp mail server) raid10 eseten milyen stripe meretet erdemes valasztani es azt mi befolyasolja? Pl. Diszkek szama

Kell erre masik topikot nyitnom, vagy van mar csak en nem latom?

Nem akarok marketingelni, de lehet itt az ideje valami értelmes mail szervert betolni a megoldás alá, ami képes támogatni pl. a rendes online archiválást is. Tekintve h. az a kérés h. neki márpedig kell a 160G-s postafiókja, az offsite archívum itt nem működik, pedig én is annak a pártján vagyok.
Helyedben megnézném pl. a Zarafa és a Zarafa Archiver megoldásokat, mert nagyon korrektül működik. Van egy éles szervered, és egy archív szervered. A postafiókot meg úgy látja az user, mintha egyben lenne, olyasmi mint az Exchange megoldás, csak azért olcsóbb a hollandok terméke :)
Láttam h. a zentyalos megoldást üzemelteted Zarafa-val, de valahogy nekem azzal nincsenek jó tapasztalataim. Van egy 200+ mailboxos, 1TB-ot kajáló Zarafa szerverem és teljesen jó. Persze ez a Professional verzió, ami egyébként is kellene az archiváló megoldáshoz.
Lehet bűvészkedni ilyen attachement kivakaró cuccokkal, de sosem lesz olyan mint az Exchange / Zarafa archiváló megoldása. Ráadásul Outlook és mobileszköz támogatást is kapsz rögtön.

Z

Te milyen disztribúcióra telepítetted a Zarafat?

Debian Wheezy 64bit.
ZCP Professional + Archiver Server.
Teljesítménnyel és tudással teljesen meg vagyunk elégedve (mondom ezt úgy h. egy nagyon háklis vezetőségnek riportolok :))

@khiraly: Hogy állítottad be ? Nagyon rég téma a TB-nél, hogy legyen de tudtommal a pluggable sem tökéletes még. Pár éve meg pláne nem volt.
https://wiki.mozilla.org/Thunderbird/Maildir

A desktop-okon keresnék másik klienst.