DDUMBFS tapasztalatok érdekelnek

Napi 1G? Akkor megy az üzlet. Új vas.

alternativ megoldas: dobj ossze egy email archivalo gepet, ami a mindenkinek elkuldott 10 MB-os excelbol 1 peldanyt tart meg. A szerveren meg eleg az utolso x nap/honap/ev leveleit meghagyni, igy nem no a diszk kihasznaltsaga (a mail szervernek), az archivum meg birja a strapat.

--
"Tudom én hogy nem biztonságos, de le van szarva az egész [...] A WoW jelszavam maradjon titokban csak az a lényeg!" (BlinTux)

Alkalmaztam már olyan megoldást, amikor a postfix automatikusan duplikált minden levelet egy archivumba. (Van egy ilyen opció, csak már régen volt.) Az archiv user - megfelelő jogosultsággal - szintén megosztható imap alatt, így a kimenő levelek helyi és egyéb mentése felesleges.
Szerintem a rendszert abszolút felesleges tovább bonyolítani, hanem szabályokat kell felállítani és oktatni:
- A postfix levélméretet le kell venni egy ésszerű értékre.
- Az xls, doc stb.,- azaz text állományokat - tömörítve kell küldeni. Ekkor rögtön 60-70% hely felszabadul!
- A vezetőkkel szövetségre lépve fel kell szólítani a dolgozókat, hogy a videók/fotók továbbítását máshol végezzék! Ezeket a mentett levelk közül is el kell távolítani!
- Mindenképpen meg kell vizsgálni a közös munkaterületeket! Pl. a főnök távolítsa el a közös mentett területről a saját zeneletöltéseit, amelyek a mentett adatok 70%-át teszik ki! :)
- A duplikátumok gyakran úgy keletkeznek, hogy a dolgozó hozzá nem értő módon, vagy figyelmetlenségből a 100 oldalas szerződésre válaszolva "elfelejt lecsatolni". Így az "Ok" válasz mellett visszamegy a 100 oldalas dokumentum is.

Dedupnál, főleg leveleknél eredményt 4-8KB-os blokk méretnél tudnál talán elérni, ehhez pedig mérettől függően szükség lesz memóriára, és várható valamekkora teljesítmény csökkenés. Mivel a használt adatok alatt a partíciót szeretnéd módosítani, így leállásra mindenképp számolhatsz. Ahogy már jelezve lett, érdemes lehet kiszámolni, hogy kb. mennyi időd mehet rá az új megoldásra, és mennyibe kerülne egy új szerver, ami képes bőven kiszolgálni a napi 1GB helyet, ami azért annyira nem vészes, ha azt vesszük. 3 évnyi teljes levelezése is kb. 1.3TB...

Nem tudom miért épp a ddumbfs-t nézted ki, érdemes átolvasni az opendedup.org -ot is.

Ha sok az ilyen mindenki-mindenkinek levélküldés, akkor lehet, hogy céges policy-t érdemes kicsit módosítani, és oktatni a dolgozókat az új hasznos dolgokról. Ha sok xls, doc készül, akkor lehetne egy NFS, vagy SMB megosztást felcsatolni a kliensekre, hogy oda mentsék, és csak a linket küldjék el. Egy plusz lépés a dokumentum kezelő, amit webdav-on keresztül akár közvetlenül meghajtóként is akár csatolhatsz, vagy szinkronizálhatsz. Van pl. owncloud, amit szintén telepítve saját környezetben üzemeltethetsz szinkronizációs megoldást, amivel elkerülheted az NFS/SMB megosztást, és még a fájljaikról is tudsz mentést készíteni a szerverre.

Szerintem vagy rengeteg idő + pénz befektetéssel izomból lehet megoldani a problémát, vagy némi munkaidővel és oktatással.

Én nem próbálkoznék semmi olyannal, amiben nem vagyok 100%-ig biztos, mert ha valami probléma lesz belőle, akkor azért Te leszel a felelős.

Szóval röviden leírnám a jelenlegi helyzetet és a megoldási lehetőségeket is, mindegyikhez odaírva a költségeket és a potenciális következményeket is.
- kb. mikor fog elfogyni a hely ha minden így marad?
- kb. mennyivel lehet a napi 1 gigát csökkenteni ha a user-ek ésszel használnák a levelezőt?
- mennyibe kerülne a hdd bővítés a szerverben, már ha lehetséges?
- ha nem lehetséges, akkor mennyibe kerülne a cseréje?
- ha a sw-es dedup szétcsesz valamit akkor az milyen károkat okozhat a cég üzletmenetében (eltűnt szerződések, kötbérek, hibás teljesítés, stb.)?

Ezt az egészet írásban eljuttatnám a döntéshozónak, és ő döntse el hogy mi legyen. Ha nem tesz semmi az is egy döntés.