IBM´s CommonStore for Exchange är ett starkt alternativ till ovan nämnda Arkiv lösningar..
Framförallt har ni valmöjligheten att lagra Exchange data i ett par olika stores som är lite mer intelligenta än simpel disk..
Nämligen TSM eller IBM Content Manager

Synd, annars var det en bra artikel som tog upp kända som okända prod.

Känns lite 1900-tal om du frågar mig.

Arkivering till billigare (och långsammare) media är väl bra för kostnadskontroll, men det bör vara fullständigt transparent för slutanvändaren.

Genom indexering och intelligenta algoritmer som kontinuerligt analyserar användandet av information på individnivå och kontinuerligt flyttar data till olika typer av lagring beroende på hur sannolikt det är att det kommer efterfrågas borde detta vara tämligen enkelt att genomföra med dagens teknik,

Det är givande med en e-post relaterad artikel men jag måste komma med lite synpunkter. Som konsult med fokus på Exchange får jag (eller kanske snarare fick jag) ofta frågor kring arkivering. Problemet med dessa är att jag sällan eller aldrig förstår syftet med frågan. Jodå jag förstår att man ser att brevlådor växer och att det tar tid att ta backup på Exchange databaser MEN… Jag förstår inte varför man tycker det är bättre att gå från två kopior (databasen plus en sannolik backup av den) till betydligt fler när man vill få ner volymen. I de flesta fall då det arkiveras så skapas det en eller två ytterligare kopior av mailet, den som arkiveras och en eventuell backup av arkivet. Den absoluta lejonparten av kunder vill nämligen behålla sökbarheten från Outlook och därmed så lämnas "spår" av mailet kvar i Exchange, så kallade "stub" files. Detta gör att databaserna i Exchange inte krymper speciellt mycket och att man i realiteten bara får en mer komplex miljö som kostar mer och förbrukar mer disk. I ett läge där Exchange dessutom kan använda sig av den absolut billigaste formen av lagring känns då arkivering oftast rätt och slätt dumt.
En annan sak som många kunder numera, när de insett ovanstående och vill bli av med sina arkivlösningar, frågar om är hur man går från ett tredjeparts arkiv tillbaka till Exchange. Här skiljer naturligtvis de flesta produkter sig åt men de har det gemensamt att ingen leverantör är speciellt intresserad av att det är enkelt att trycka tillbaka allt till Exchange och sedan avveckla deras produkt. Högst försåtligt eftersom de lever på att den ska vara kvar men ett problem för den kund som vill använda sig av tex Exchange’s inbyggda arkivfunktionalitet.
För att kommentera lite detaljer i artikeln så tycker jag att just sökbarhet av arkiverade mail är en av de viktigaste funktionerna, det nämns knappt i artikeln och det är en av de stora fördelarna med Exchange Personal Archive.
Och det går att importera PST-filer, det är inte svårare än att dra en PST-fil till arkivet eller så kan en administratör göra det åt användaren via PowerShell (New-MailboxImportRequest ). Dessutom så har Microsoft annonserat att ytterligare funktionalitet på detta område är på väg (http://blogs.technet.com/b/exchange/archive/2011/07/05/coming-soon-pst-capture-tool.aspx)
Jag vill i ärlighetens namn också säga att det finns helt okej skäl till arkivering! I de fall företag har juridiska krav på sig att förvara e-post på annat medium än Exchange eller legala krav på arkivering så kan det vara ända utvägen men dessa är relativt unika.
Tack för en intressant artikel Henrik, jag ser gärna uppföljning!

Du får ursäkta, men du påstår att du är Exchange-konsult så då måste jag bara fråga:

Är det din rekommendation att lägga en lösning på säg 12000-15000 användare av Exchange på billig SATA disk? Har du sett vilken prestandaeffekt det ger?

Om du inte förstår varför folk vill arkivera kan du inte ha fått många frågor om det.

Och att sökbarheten skulle göra att Exchangedatabasen i praktiken inte skulle krympa är dravel. De allra flesta som använder en arkiveringstjänst för Exchange börjar med att arkivera bifogade filer, eftersom användarna i de allra flesta fall redan gjort en detach av filen. Jag har gjort flera analyser av mailstores och kunnat konstatera att bifogade filer äldre än 30 dagar i praktiken aldrig används.

Dock utgör de bifogade filerna ca 65-70% av hela Exchange, så om du väljer att arkivera dessa har du i praktiken flyttat bort 65-70% av datamängden. Så maildatabasen krymper inte särskilt mycket?

Med t.ex. Commonstore for Exchange som någon nämnde här ovan kan du flytta informationen via Content Manager (för indexering och sökbarhet) till TSM. TSM används för säkerhetskopiering och har inbyggda funktioner för att säkerställa sin egen lagring, så det blir inga "2 kopior" av informationen eftersom den arkiverade informationen redan lagras i ditt backupsystem.

Om du ska uttala dig om den här typen av frågor är det bra om du har läst på, och inte kommer med påståenden som är osanna.

Jodå, jag ser dagligen vad det ger för effekter, framför allt i minskade kostnader. Men eftersom jag inte tror att du är ensam om att ha en lucka på området så förklarar jag gärna.
I Exchange 2010 (som artikeln handlar om) är en av de stora nyheterna att kraven på diskprestanda, IOPS, minskats med ca 70 % jämfört med Exchange 2007 (90 % jämfört med 2003). Detta möjliggör just användandet av billig disk för databaser. En "normal" användare förbrukar 0,05 - 0,1 IOPS och en SATA-disk kan prestera ca 60 IOPS när det gäller "slumpmässig" (random) läsning. Dvs det finns ledigt prestanda för 600 användare i en ända SATA-disk. Validera gärna detta genom att använda den kalkylator för lagring som Microsoft rekommenderar, http://gallery.technet.microsoft.com/v144-of-the-Exchange-2010-1912958d. Så högst förenklat så kräver 12 000 användare ca 20 diskar för att uppnå den prestanda som krävs. För att vara ytterligare tydlig så rekommenderas lagring baserat på denna typ av disk endast i fallet då man replikerar databasen i minst tre kopior så det faktiska antalet skulle bli 60 diskar totalt men detta är fortfarande extremt mycket billigare än att använda sig att dyra SAN-lösningar.
Som jag sa, jag kan ha förståelse för en del av de frågeställningar som finns men precis som ovan så bygger önskan om att flytta det till något annan plattform än Exchange ofta på okunskap. Eftersom data kan lagras på så pass enkel disk (med bibehållen prestanda) blir det sällan eller aldrig billigare att flytta bort det från Exchange.
Jag är högst beredd att hålla med dig om två saker. Att databasen krymper när data tas bort ur den är naturligtvis sant! Men eftersom Exchange 2010 också komprimerar innehållet i databasen är det mycket unikt att få siffror som ens är nära 70 % minskning.
Att bilagor som är äldre än 30 dagar sällan eller aldrig används håller jag också fullständigt med om, dock gäller samma sak, det blir inte billigare att flytta bort dem.
Naturligtvis finns det fall där arkivering kan vara på sin plats, precis som jag sagt tidigare, men när kostnaden för dessa ställs mot kostnaden att de finns kvar inom Exchange kommer många att inse att arkivering tillhör gårdagen.
Jag tackar för att du tog dig tid att kommentera, ser gärna att vi fortsätter diskussionen!

Diskussionen handlar inte om varken IOPS eller hur stor disk du kan koppla till Exchange-servern. Den handlar om vad som händer när du behöver återställa Exchange efter en krasch t.ex. och dina användare sitter i korridoren och stirrar argt på dig. Det vanligaste resonemanget i det här fallet brukar vara olika form av hårdvaruspegling / snapshots. Dessa förbrukar ju i själva verket lagringsyta de också, och skyddar inte mot logiska fel (eftersom speglingen sker på HW nivå). Därför kommer det alltid finns ett behov av att kunna göra restore av Exchange databasen, något jag knappast tror att du vill göra med en 8-10TB stor Exchange miljö.

Resonemanget att disk är billigt är inget nytt resonemang, men det är fortfarande lika fel, eftersom du fortfarande bygger upp gigantiska informationsvolymer på primär lagring, som ingen användare använder och som därför inte borde vara information som servern hanterar (du kanske inte håller med mig om att Exchange faktiskt gör maintenance på lagrad informationsvolym, men jag presenterar i så fall gärna information både från Microsoft själva och från oberoende analytiker att så är fallet).

Och du vill inte lagra en "extra kopia" av informationen i ett arkiv eller backup, men du ser gärna att man replikerar databasen i 3 kopior? Talar inte det emot ditt resonemang att dra ner på lagringsvolymen?

Arkivering av information, oavsett om det är från Exchange, Domino, SAP R/3, filservers eller andra system har alltid följande positiva effekter:

* Snabbare återställning från ditt backupsystem
* Mindre informationsvolym att hantera för din applikation (något som i 99% av fallen betyder att applikationen mår avseevärt bättre)
* Sänkta kostnader. Att lagra information i en VTL eller bandrobot kommer alltid att vara billigare än att lagra på disk. Varför? En VTL använder precis den SATA-standard du föreslår för primär lagring. Skillnaden? En VTL har hårdvarukompression, men den har framförallt deduplicering. Detta reducerar behovet av lagring enormt. Och du påstår väl inte att lagring på band är dyrare än på disk? Det är inte bara S-ATA disken som kostar pengar, i många fall behöver du betala för kontrollers, licenser m.m.

Om du inte tror mig har Gartner Group åtminstone 2 rapporter där man jämför kostnaderna. Inte minst den administrativa kostnaden (du vet, du som administratör :)) utgör en mycket större kostnad vid lagring på primär disk.

Jag föreslår ett besök på:

http://www.gartnergroup.com

Jag köper delar av vad du säger men tycker du vänder upp och ner på saker. Snabba återställningstider är naturligtvis önskvärt men det är mer önskvärt att slippa återställa och därför används replikering. I fallet att en disk går sönder (vilket de oundvikligen gör) flyttas driften till en av de återstående kopiorna i det tänkta scenariot jag presenterade. Detta tar mellan 10 och 30 sekunder, en tid som få andra lösningar kan slå.

Exchange använder sig inte av spegling på HW nivå utan mjukvarunivå, det är detta som skiljer denna applikation radikalt från de flesta andra. Logiska fel kan dock fortfarande uppstå och metoden för att skydda sig mot detta är en så kallad laggad kopia, dvs den släpar i tid och kan därmed användas för point in time restore (återigen utan att läsa tillbaka något från andra system).

Jag håller fullständigt med dig om att Exchange gör underhåll på sin data, faktum är att den gör det 24/7 och helt automatiskt.

Att jag föreslår att data ska replikeras inom Exchange är naturligtvis för att ge hög tillgänglighet, jag tror att få organisationer är beredda att köra helt utan redundans och förlita sig till återläsning. I princip alla vill ha någon form av clustrad lösning. Det viktiga enligt mig är inte antalet kopior av samma data i sig eller volymen data, det är att kostnaden för detta inte ska skena iväg.

Att administration kostar är jag mycket medveten om! Jag tror dessutom att administration av flera system kostar mer än administration av ett system. Att ha personal som driftar två system torde därför bli dyrare än ett, dvs att behålla data i Exchange är troligen ett bra sätt att hålla kostnader nere.

För att vara tydlig, jag välkomnar alla kommentarer och uppskattar diskussionen.

Jag är absolut ingen Exchange expert men mina kollegor är det dock. Som du vet har ju 2010 har en enorm förbättring av diskutnyttjandet och vi räknar just nu på SATA DAS med 64 diskar i ett fyra (möjligen att det blir åtta men troligtvis inte) noders DAG och kör jetstress tester på lånat HP kit och det ser lovande ut. Dock kommer vi nog få skippa idéerna på att ha allt virtualiserat, VMDirectPath I/O funkade helt enkelt inte med den storage kontroller vi testar med och VMWares storage drivare klarar inte av kapaciteten. Kapaciteten ligger just runt 14-18k per DAG (2 per speglat data center). Vi kommer också designa en mindre lösning för de mindre kontoren i Asien med kapacitet runt 5-7k.

Vad det gäller arkiveringen kan jag dock hålla med. Vi kör 2007 men arkiveringen är microsofts egna i 2010, vi brukade köra EV och kör det dock fortfarande på viss del av miljön.

Sedan gå inte så hårt åt killen vad det gäller hans inlägg. Det är inte ofta man få ha vettiga diskussioner om teknik här utan att det skall resultera i datorkrig av alla foss-troll. Du vill väl inte ha hit dom istället där dom hävdar att man kan ersätta exchange med postfix i vansinnediskussioner? :)

Låter som ni kommer få en riktigt bra Exchangelösning. Nej Postfix vill jag verkligen inte ha i stället, dock har den också absolut sitt berättigande enligt mig.

Utan att avvika från ämnet som dessa kommentarer syftar på så är just virtualisering av Exchange inte helt enkelt. Dels på grund av de saker ni snubblat på och sen en hel del kring vad som är supportat och inte. Jag tror ni gör klokt i att hålla mailboxsevrar fysiska. HUB och CAS är två roller som kan lämpa sig för att köras virtuellt.

Jo, vi gör allt för att den skall bli bra.

Visst är postfix berättigat men oftast inte i de miljöer där du idag ser exchange.

Sedan tror jag dock allt att exchange virtualisering kommer ordentligt inom ett eller så. Bara en sådan sak som att vi har 40 core maskiner och max rekommenderat är 24 core för multi roll, tolv core för mbx... Virtualisering kan ju lösa denna idag inbyggda ineffektivitet i exchange.

Som vanligt så är första frågan, vad man vill uppnå?
Känner själv bäst till Enterprise Vault och gjort ett antal installationer etc.
Givetvis vid en viss storlek på bolag eller mängden mail så finns egentligen ingen anledning att skaffa något annat än det som följer med i Exchange.
Så tillvida man inte vill komma åt vissa funktioner, ex. att kunna delete'a en mailbox men behålla arkivet, komma åt arkivet offline m.m.
En annan del som man inte ser så mycket i Europa och Sverige än är Journaling. Ex. om man behöver ha spårbarhet av mailen över lång tid, ex. vad skickade X till Y 20:e mars 2009.
Sen hände endel saker i Exchange 2010 som inte är snällt för disk (disk kanske är billigt men inte storage system), det är att man tog bort single instance storage. Så här får man då investera i ett lagringsystem som genomför deduplisering alt. mer disk alt. arkivering. Lägg till DAG och du behöver än mer disk.
Andra frågeställningar som fanns innan Exchange 2010 (alt. Exchange 2010 utan DAG) så var det ex. backup/restore tider. Nu finns det en uppsjö sätt att göra detta på men det är delar som kommer/kom in i ekvationen.

Framförallt så är frågan att arkivera eller inte arkivera mycket större än vad man först tänker sig att det är. Hur integreras användarna, vad har man för legala krav m.m.
Att flytta mailen till något annat storage är den enkla delen.

Vi kör med journaling. Journaling har varit enormt bra redan. Vi har haft två data läckor sedan det infördes. En där alla kontrakterares arvoden skickades ut till en lista av 800 personer. Alla som vidarebeodrade detta mail internt blev sedan uppringda och tillplattade. Nummer två var en utvecklare som skickade hem massa kod.

är väl ett bra alternativ.