Mail archiválás és tárhely felszabadítás

Linux-kezdő

Sziasztok,

a cégnél van vagy 50 user.Maildir formátumot használunk.Sajnos a mailszerveren (debian) elég kevés már a hely.
Arra gondoltunk, hogy lementjük mindenki maildirjét, majd ezután töröljük mindenkinek a pl. 2006 július előtti leveleiket.Van valakinek ötlete, hogy ez hogy oldható meg legegyszerűbben?
Köszi,
sutyee

( coder | 2007. 01. 09., k – 16:01 )

arhíválás pl. tar -al, gondolom ez nem igényel különösebb magyarázatot,
a törlést meg pl egy rekurziv find exec paraméterrel vagy | xargs rm pipeolással és pl hogy be tudd határolni a miket kell törölni nézd meg a -mtime paraméterét a find -nek.

persze ha millió törlésről van szó, akkor keress még picit itt a topicok között, mert folyt nemrég vita arról, h ilyenkor mi a jobb... find és exec v. pipe merthogy nem mindegy hogy hányszor és hogyan van meghívva és indítva pl az rm

( dotnetlinux | 2016. 02. 23., k – 13:48 )

Közel 9 év után nem találtam jobb témát, ezért ezt folytatom:

Adott egy bérelt, 20GB-os tárhely, amit betöltenek a levelek lassan. A tárhely növelhető lenne a végtelenségig, de _megoldást_ keresek, nem a jelenség elfedését. :)

Saját, irodai, kis sávszélességű (5-10Mbit) szerverünkre szednénk le a 2015. január 1 előtti leveleket, amelyeket a jelenlegi helyről törölnénk, csak a saját szerveren lenne meg. Itt van RAID, meg minden, kellő biztonságban vannak (a fontosságuk és koruk arányában). Maildir formátum tökéletes, utána egy RoundCube mellérakható nézegetni.

Milyen megoldás felé induljak el?
- POP3 fetcher?
- Célcsomag?

Jó lenne valami CentOS beépített csomag + script, nem egy telepítendő valami.

Ezt én értem, csak kérdeztem, hogy biztos anyagilag az-e a legjobb megoldás?

Behúzol egy csomó humán lépést (beleértve egy csomó potenciálisan elkövetett hibát és azok megkeresését), amikor is x időnként át kell tenni innen oda leveleket illetve két mailbox-ot kezelni meg ilyesmi... $1/10GB/hó áron vehető storage árak mellett (én most például 8 eurót fizetek havonta 500GB tárhelyért) ez meggondolandó.

Nekem a build szerver van rajta (Jenkins, Sonar, Nexus és Fisheye), CPU teljesítményben nagyjából ott van, mint a DO, néha vannak hálózati lassulások, de egyébként nincs rá panaszom. Használom online mentésre is. Szerintem az árát megéri.

Az OVH is jó lenne, de ott fényt kaptak, amikor az angol cégem nevében próbáltam gépet bérelni magyarországi lakcímkártyával, mert az is kértek...

Es ez nem zavar?: http://hup.hu/node/145533

Ott pont a contabo-t ekeztek... nincs igazan savszele, csomot all, nincs rendelkezesre allas.

Mondjuk egy buildservernel nem igazan lenyeges, hogyha van napi 1 ora allas...

En ekozott hezitalok eppen:
https://www.online.net/en/dedicated-server/dedibox-xc
http://www.euserv.com/en/dedicated-server/misurfi-rootserver/v7/misurfi…

Az ikoula-t nem ajanlom, ott epp fut egy paypal perem veluk (1 honapos procedura).

---
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....

"Ott pont a contabo-t ekeztek... nincs igazan savszele, csomot all, nincs rendelkezesre allas."

Hát... mindenhol szoktak lenni problémák, mert száz százalékos rendelkezésre állás nincs... és persze ár-érték arány ugye... :)

Ma hajnalban például a Vultr lepett meg ezzel: http://www.netdiag.hu/wdFull_daily_HU.asp?i=1481

"Mondjuk egy buildservernel nem igazan lenyeges, hogyha van napi 1 ora allas..."

Ahja, egyébként meg architektúra függő ez a dolog.

Én a saját online játékom alá egy elosztott adatbázis rendszert tettem, ami többnyire érzéketlen arra, ha néhány node nem érhető el, kiesik hosszabb időre vagy meg is döglik az adattal együtt. Felette lazán csatolt middleware van, ami többnyire stateless, a stateful állapotát pedig replikálja. A load balancer pedig a kliens oldalán van megvalósítva.

http://prezi.javaforum.hu/gacivs-devop/

Ezt az eloadast mar parszor elolvastam. Lehetne benne abra:)

Apropo, a load balancing mit takar nalad pontosan?
A weboldal (.info) is resze mar ennek?

---
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....

En az ilyen fizikai szerverekre vagy docker-t teszek (mint egy VPS-re), vagy pedig lxc/lxd kontenert. (lxc-en belul nem megy a docker).

Mas virtualizaciot, vagy windows-t nem futtatok ilyenen. Szoval 5letem sincs, hogy mi van kvm, vmware, etc ugyben. De ha tisztan linuxon maradsz akkor ezekre nincs is szukseged...

Update:
> Ez az euserv nem is rossz ha majd lesz tapasztalat irhatnal rola.

Nem lesz tapasztalat rola. Itt a felhasznalasi felteteluk:
http://www.euserv.com/en/company-info/tac/Specific_Terms_and_Conditions…

Nem tervezem, hogy elkuldjem barmelyik hosting szolgaltatonak a szemelyes irataimat szkennelve.

---
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....

"Nem tervezem, hogy elkuldjem barmelyik hosting szolgaltatonak a szemelyes irataimat szkennelve."

Némelyik tárhelyszolgáltató komolyabb ellenőrzéseket végez, mint egy bank... az OVH-nál azzal pattantam le, hogy az angliai céggel nem tudtam a cég székhelyére szóló "utility bill"-t és/vagy bankszámlakivonatot prezentálni...

Mérlegeltem, köszönöm a javaslatokat.
- Sajnos macerás áttenni az MX-et máshova, főleg a kollégák gépén átállítani az IMAP-okat.
- cron futtatja majd a scriptet (mono-s c# kód lesz a vége), egy nap alatt megcsinálom hobby-ként
- a másik nem lesz mailbox, elég ha megvannak a levelek, amiben keresni lehet és vissza lehet másolni 1-1-et a maildir-be.

meg a vegen ok gondoljak jol: tobb kiegeszito is -
de az iCloud kiegeszito a legelterjedtebb - osszeakad,
hogyha .pst fajl halozati megosztason van.

---
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....

meg szerencse, hogy csak nem is hasonlot mondtam. Az email archivalas jellemzoen dedikalt gepen megvalositott szolgaltatas, ami egy masolatot eltesz minden a mail szervert erinto levelbol, azokat indexeli, tomoriti, titkositja, deduplikalja, ill. egy feluleten elerhetove teszi read-only modon a usereknek.

Ilyen termek pl. a lentebb emlitett mailstore vagy a symantec vault, amit szekelyk emlitett. De ilyen a piler is, ami open source es Linuxon fut.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( Robika88 | 2016. 02. 23., k – 19:45 )

A problémátok megoldása a MAILSTORE!

Lementem vele, visszakeresem stb. Keress rá.

( szekelyk | 2016. 02. 24., sze – 09:14 )

Kereskedelmi termék Symantec Enterprise Vault és EMC SourceOne is tud SMTP szerverről journaling módszerrel archiválni. A postaládákból való törlésről neked kell gondoskodnod, ezt a funkct csak az Exchange/Outlook és Notes/Notes kliens esetén tudják. Maildir formátumhoz hozzá sem szagolnak. Mindegyik Windows-os alkalmazás és SQL szervert is használnak. Mindegyiknek van webes keresője amin a userek elérik az archívumot. 50 felhasználóra nem horror a licensz költség.

( freeoli v | 2016. 02. 24., sze – 11:23 )

Lemezbővítés. Semmi törölgetés.

( Swifty v | 2016. 02. 24., sze – 14:02 )

Csak egy kis infó: dovecot tudja a leveleket tömörítve tárolni... :)
--
Debian Linux rulez... :D
RIP Ian Murdock

ha mar dovecot, akkor az is tud emaileket archivalni. Bar szerintem melegen ajanlott ezt a funkciot el/levalasztani egy mail szerverrol

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Szerintem meg üzletileg nem elfogadható a levelek összevissza tárolása, elkülönítése, local archive meg stb bohóckodás.

Elegendő erőforrás kell alá mert üzletileg kritikus információk találhatóak ott amiket ráadásul gyorsan kell tudni elérni. Ha egy cégnek 2 hdd meg egy napnyi munka megterhelő akkor a tulajdonos síeléséből kell elvenni, nincs mese.

mintha egy kicsit fogalmatlan lennel a temaban. Az email archivalas olyannyira nem 'osszevissza tarolas' (el-o-el, btw), hogy tolunk nyugatabbra konkretan jogszabaly irja elo, hogy az adott iparagi szereploknek hogyan es meddig kell igy tarolniuk a leveleket, hogy meglegyen a compliance.

Ha pedig majd egyszer megborul egy fel oracskara a mail szervered, vagy ha pl. egy picit is komolyabban keresni kell egy nagyobb email halmazban, esetleg tobb mailboxban, akkor majd tudod ertekelni az email archivalast.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ahogy az általad is idézett dokumentáció írja:

zlib_save = gz # or bz2, xz or lz4

Azaz többféle tömörítési eljárás létezik. És ha már csak azt figyelembe veszed, hogy a simán eltárolt levelek alapvetően 7 bit-esek, akkor már a legegyszerűbb/leggyorsabb tömörítés is fog rajta cca. 10%-ot spórolni. Nálam ez az arány 30% környékére adódik.

A mozgatás esetén nincs ki- betömörítés... (Ha a szerveren belül mozgatunk.)
Keresés az esetek túlnyomó többségében a levél feladója, ideje, tárgya alapján történik... Itt sem számottevő a tömörítés hátránya...

Ha neked nem tetszik a megoldás, akkor az a te bajod... :) Nálam nagyon jól működik és egy ügyfelem sem panaszkodott arra, hogy lassú lenne a leveleinek elérése...
--
Debian Linux rulez... :D
RIP Ian Murdock

nyilvan barmelyik csak kicsit is ertelmesebb megoldas egy indexet epit ezekbol a metaadatokbol, es abban keres, nem pedig a gzip -dc * | grep whatever-t implementalja...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( szekelyk | 2016. 02. 24., sze – 21:03 )

Esetleg Zimbra annak beépített archiváló része, azt meg nem mondom, hogy az ingyenesben is benne van-e.