Tag Archives: backup

PST, datahanteringens mardröm.

Först och främst kanske en förklaring om vad PST-filer är för något. enligt whatis.com så betyder PST “Personal Store” och används främst av outlook för att hantera objekt som exemeplvis epost, kontaktinformation, kalenderobjekt, etc.

Och varför skulle detta vara en mardröm att hantera?

Det är så att de flesta företag faktiskt använder Microsoft Exchange som mail-server, och då oftast outlook som mailklient. Jag personligen nyttjar denna kombination hos min nuvarande arbetsgivare och har inget att klaga på som användare, den gör sitt jobb och kombinationen exchange-outlook ger många bra och fungerande funktioner. Det är inte det som är problemet för många, problemet ligger i hur vi väljer att hantera data. Vi arkiverar inte, och i de tillfällen vi gör det så har vi oftast inte koll på varför eller hur vi skall arkivera. Utan defacto standard på epostanvändarna är att man inte tar bort några mail från sin inkorg eller skickat-mapp för att vi tror/misstänker att vi någongång i framtiden behöver använda detta mail igen. Resultatet blir att exchange-serverns databaser blir allt större och svårare att säkerhetskopiera eller återställa. Dessutom sjunker prestandan desto större databaserna blir.

Administratörernas botemedel heter Quota

Det blir betydligt enklare att hantera en exchangeserver när quota är satt, och tvingar användarna att antingen radera gamla object eller arkivera dessa på andra sätt. Och det är nu det dåliga beteendet som vi användare har gör sig påmint. Vi väljer att arkivera dessa mail på det sätt som outlook rekommenderar, nämligen i PST-filer. Så vi skapar en PST-fil och monterar den i outlook och drar över de objekten vi vill arkivera i vår PST-Fil. I vissa fall väljer outlook att rekommendera användarna att arkivera automatiskt, fantastiskt. Problemet kvarligger dock eftersom anledningen till att vi raderar objekten är för att vi tror/misstänker att vi skall använda dem igen, så lägga PST-filen på C:\ eller någon annan lokal disk går ju inte, det saknas oftasst backup på de lokala diskarna. Nej, de skall givetvis ligga på en nätverksresurs, där har vi ju fått lära oss att arbetsrelaterad data skall ligga eftersom vi tar backup på dessa. Fel nummer 1. Microsoft supporterar inte att placera PST-filer på nätverksresurser (kb297019).

Men de hamnar på nätverksresurser likförbannat, och tur är väl det? Tänk om viktigt företagsinformation som ligger i en PST-fil på en lokaldator skulle komma på drift eller försvinna för att datorn krashar, blir stulen eller infekterad av virus.

Men nu skapar dessa PST-filer ytterligare ett problem, nämligen backup/restore. Problematiken som vi ny flyttat från exchange-servern till filservern. Anledningen till detta är att outlook på något mysko sätt hanterar PST-Filen. Eftersom detta inte är öppen källkod eller ett öppet format så kan jag bara gissa vad som händer. För att demonstrera detta så gör jag ett exempel på min PST-fil som jag har på min hemkatalog på jobbet (ja, jag vet.. jag är en sån användare. Anledningen är att vi saknar alternativ till PST idag).

Först och främst så tittar vi på min PST fil på min hemkatalog (H:\)

H:\>dir
Volymen i enhet H har etiketten Shared Files
Volymens serienummer är A03A-E3BB

Innehåll i katalogen H:\

2010-06-23  10:38    <KAT>          .
2010-06-23  10:38    <KAT>          ..
2009-08-24  15:05                59 .bash_history
2009-08-10  11:26                 0 .Xauthority
2010-06-23  10:38     1 146 864 640 arkiv.pst
2010-06-22  08:20    <KAT>          MyDocuments
2009-09-02  15:48    <KAT>          WebEx

Där ligger den, en arkiv.pst på drygt 1GB

tittar vi på attributen på den filen så ser det ut så här

H:\>attrib
             H:\.bash_history
             H:\.Xauthority
        I    H:\arkiv.pst

arkiv.pst har enbart I attributet satt

Nu monterar jag arkiv.pst i outlook och kör attrib igen

H:\>attrib
             H:\.bash_history
             H:\.Xauthority
        I    H:\arkiv.pst
A   H        H:\~arkiv.pst.tmp

det har skapats en temporär dold fil som hör till arkiv.pst
Nu avmonterar jag min PST-fil, och observera: jag har inte lagt till några objekt eller raderat. Bara monterat och avmonterat PST-filen i outlook, den bör alltså vara oförändrad.

H:\>attrib
             H:\.bash_history
             H:\.Xauthority
A       I    H:\arkiv.pst
A   H        H:\~arkiv.pst.tmp

Men vad nu… arkivflaggan på arkiv.pst är satt. Det innebär att filen är flaggad som förändrad och kommer att inkluderas i nästa inkrementella/diffrentiella backup!!!! fast vi inte gjort några förändringar.

efter att vi stänger outlook så försvinner tempfilen

H:\>attrib
             H:\.bash_history
             H:\.Xauthority
A       I    H:\arkiv.pst

Ponera att det sitter 100-tals outlookanvändare som blir “utstängda” från exchange-servern av administratörerna p.g.a. quota, och har sina PST-filer automatiskt monterade i outlook. Jösses va många kopior det blir

Så, jag tror att den där tempfilen används som någonform av “kö” mot PST-Filen och när vi avmonterar och stänger outlook så “flushas” förändringarna in i PST-Filen, oavsätt om vi adderat några objekt eller inte. FAIL!

Lösningen på detta är enligt mig en bättre hantering av företagsinformation i kombination med en aktiv HSM/Arkiverings-produkt samtidigt som quota försvinner.

En liten “rolig” detalj var när jag ködre attrib /? i windows 7

H:\>attrib /?
Visar eller ändrar filattribut.

ATTRIB [+R | -R] [+A | -A ] [+S | -S] [+H | -H] [+I | -I]
       [enhet:][sökväg][filnamn] [/S [/D] [/L]]

  +   Anger ett attribut.
  +   Rensar ett attribut.
  R   Filattributet Skrivskyddad.
  A   Filattributet Arkiv.
  S   Filattributet System.
  H   Filattributet Dold.
  I   Ej innehållsindexerat filattribut.
  [enhet:][sökväg][filnamn]
      Anger en eller flera filer som ska bearbetas av ATTRIB.
  /S  Bearbetar matchande filer i den aktuella mappen
      och alla undermappar.
  /D  Bearbetar även mappar.
  /L  Fungerar på attributen för den symboliska länken
      i motsats till målet för den symboliska länken.

+ som parameter betyder vadå? :)

Läs även andra bloggares åsikter om , , , , ,

FTP får nytt liv (för mig)

Daniel rapporterar om att FTP-Protokollet har fått en ny “draft” om en utökning av kommandon, denna gång föreslås “HASH“.

Det innebär att ftp-klienten skall kunna fråga ftp-servern om en HASH-beräkning på filen för att dubbelkolla att filöverföringen verkligen gått bra. Och för mig är detta helt underbart. Jag har tidigare varit låst till HTTP(s), en enkel web-snurra och cURL för att kunna nyttja HTTP-PUT och låta web-sidan beräkna en HASH summa och ge den som HTTP-response. På så sätt kan mitt skript vara säker på att filkopieringen varit OK.

Om nu denna nya “draft” går igenom så innebär det att jag/vi får ytterligare ett protokoll att nyttja vid t.ex arkiveringsimplementationer.

Läs även andra bloggares åsikter om , ,

Ytterligare en “tillverkare” med “the holy grail”

Jag jobbar primärt med datalagring och pratar konstant med tillverkare om deras nya produkter som skall lösa allt.

En missuppfattning som många gör är att ha en övertro på teknik, att en viss teknik löser alla behov. Men allt har en baksida, frågan handlar bara om de negativa effekterna av en viss teknik är väger mindre än de positiva.

Några av de självklara aspekterna att ta hänsyn till är:

  • Kostnad
  • Tillgänglighet
  • Komplexitet
  • Prestanda

Men det finns också en del andra aspekter som ibland väger in, några av gånger vi investerar så är dessa “mjuka” värden otroligt viktiga och ibland avgörande. Hur fel eller rätt det än må vara (ur ett företagsperspektiv). Men dessa punkter är inte de primära anledningarna till investeringar

  • Märke / Tillverkare
  • Cool teknik
  • Grön-IT
  • Ideologi

(Jag vet att det är kontroversiellt att sätta Grön-IT här, och jag skulle vara väldig glad om upphandlingar och investeringar vägde in Grön-IT på samma sätt som prestanda, pris, tillgänglighet)

Så… Varför detta inlägg?

Jo, jag är så otroligt trött på tillverkare som lyfter fram sina positiva sidor av sina produkter till det absurdum att de inte längre ser sina egna svagheter. De tror så innerligt på sin teknik att de faktiskt tror själva på vad de säger.

Nu senast läste jag en artikel  av Henrik Jalsborn, Sales Director Scandinavia, Acronis i en debatt artikel på IDG.SE.

Jag har en Draft på bloggen om min syn på datadeduplicering, men jag har inte orkat skriva klart den. Anledningen är att jag måste beskriva hur dedupliceringstekniken fungerar för att man skall förstå vad vi har att vinna genom att deduplicera, men också för att man skall förstå vilka eventuella problem som kan uppstå och vilka kostnader (kanske inte direkt komersiella kostnader, men tekniska) som tillkommer i en deduplicerad miljö.

Ett citat som skrämmer mig i artikeln är:

Datadedupliceringens enorma potential är att datalagringen kan skäras ned med ända upp till 90 procent.

Han ljuger inte när han säger detta, faktiskt så anser jag att han i egenskap av “Sales Director Scandinavia” på Acronis kan drämma till med ytterligare några procentenheter… Varför inte 99%? Det är nämligen fullt möjligt. Men är det troligt i en produktionsmiljö?

Låt oss säga att jag väljer att göra backup av en 1MB stor fil mot en deduplicerad lagring. Denna 1MB stora fil är statisk och förändras inte. Sen gör jag 10.0000 kopior av denna fil till min deduplicerade lagring… och OJ vilk fin deduplicerings ration jag fick!

Fråga också tillverkaren varför de rekommenderar att inte komprimera sin data, och varför kryptering av informationen inte är att rekommendera. Det förstår vi allihop att det är bara för att deras dedupliceringsration blir sämre.

En annan risk med deduplicering är restore. Det kommer att krävas en enorm beräkning för att återbygga orginalfilerna vid en eventuell restore från alla dessa pekare. En del implementationer av dedupliceringsmotorer visar en sämre prestanda vid större volymer, detta går givetvis att “rädda” till viss del genom mer CPU  och RAM. Men det är en baksida.

Slutligen vill jag citera ytterligare en mening:

Varje organisation kan, oavsett storlek eller bransch, dra fördelar av datadeduplicering genom dess teknik för säkerhetskopiering och återställning.

Här håller jag med Henrik Jalsborn, men bara om ordet kan följs av “kanske“, och inte “alltid” (som jag misstänker att han menar).

Det finns många fördelar med deduplicering, både prestanda, ekonomiskt, Grön-IT, cool teknik och tillgänglighet. Det kan också vara så att rätt dimensionerad och med rätt föväntningar av tekniken så kan det “the holy grail” för er backupsituation. Men ta vad tillverkarna säger med en nypa salt och en näve peppar.

90% my ass….  fast det beror ju i.o.f.s från vilket håll man räknar… det finns ju tre sorters lögner enligt Mark Twain:  Lögn, förbaskad lögn och statistik.

Läs även andra bloggares åsikter om , , , ,

RTO & RPO

För att fortsätta mina anteckningar och funderingar kring backup & restore tänkte jag nu gå igenom två viktiga begrepp i sin backupstrategi. Nämligen “Recovery Point Objective” (RPO) och “Recovery Time Objective” (RTO).

Vad är då RPO och RTO, om du tänker dig en tidslinje och något händer med vår applikation, server, filesystem, fil.. ja vad vi nu än vill sätta en säkerhetskopieringsstrategi för.

rpo1

Recovery Point Objective (RPO)

Den röda “explosionen” på vår tidslinje symboliserar en händelse, något som orsakar att vi förlorar data och måste förlita oss på vår säkerhetskopieringsstrategi för att komma tillbaka till ett “normalläge”. Recovery Point Objective (RPO) handlar om till vilket känt läge vi skall återställa vårt system.

rpo2

RPO handlar om hur mycket data som är OK att förlora, och om hur ofta det allstå är nödvändigt att göra en säkerhetskopia. Allt för ofta faller samtliga system och applikationer in i en slentrial “default” strategi på 24 timmar RPO. Detta för att det oftast görs en säkerhetskopia en gång per dygn. Detta är kanske ok, men min erfarhenhet talar för att det oftast är ett beslut som görs av IT-avdelningar och inte förankras i verksamheten och applikationsägarna. Oftast tror applikationsägarna att säkerheten är bättre än den är, men också att vissa system får en bättre säkerhetskopieringsstrategi än nödvändigt. Detta gör att vi slösar med pengar i onödan.

Recovery Time Objective (RTO)

Detta är den andra parametern som avgör vår säkerhetskopieringsstrategi. Det är tiden det tar att återställa systemet eller applikaionen till vårt kända läge (RPO).

rpo3

RTO avgör alltså hur länge systemet får vara otillgängligt innan vi återställt systetemet till det kända läget och kan åter igen börja nyttja det. Här är det tyvärr alldeles för få som tar RTO på allvar, jag jag misstänker att det är bristen på kommunikaiton mellan IT-Avdelningar och verksamhet som är det enkillt största anledningen. Det är också väldigt svårt att sätta en RTO när vi implementerar en ny applikaion och bibehålla den under applikationens livstid. Detta för att data är som gas och fyller det utrymme som finns. När applikationen implementeras och driftsätts är det oftast svårt att veta hur datavolmerna kommer att växa under applikationens livstid, och därav svårt att bygga en arkitektur som kan uppfylla återläsningskraven som ställs av RTO.

I RTO är det inte bara återläsningstiden som anges, utan även “recovery” tiden (på engelska restore and recovery). Om vi tillexempel sätter ett RTO krav på 2 timmar på en databas, så är det alltså både återläsningstiden av databasen samt tiden för att rulla tillbaka loggarna som skall återspeglas i RTO.

Den tredje dimensionen

Nu är det inte så enkelt som att RPO och RTO är de enda parametrarna, den tredje dimensionen i denna ekvation är vad som orsakade dataförlusten. I ovanstående bilder är det min fina “explosion” som symboliserar detta. Varför är det viktigt att beakta händelsen också? Jo, det är som sagt skillnad på vad vi måste ta hänsyn till för RPO och RTO och vilken typ av händelse. Ett exempel är en vanlig filserver och följande händelser:

Användare raderar en fil.
Det enda vi behöver göra är att återläsa filen från säkerhetskopian, detta kan vara ett snap-shot som användaren själv kan återläsa ifrån. RPO kan vara låg vid ett snap-shot förfarande, låt oss säga att varje timme görs ett snap-shot vilket ger oss n RPO på 1 timme. Och användaren själv kan återläsa filen vilket ger oss en RTO på några få minuter.

Filsystemet blir korrupt och måste återläsas
Nu måste vi förlita oss på en kopia som inte är snap-shot baserat. Antingen från band eller från annad disk. Mediat kommer att ge olika RTO p.g.a. olika typer av hastighet. Men här kanske vi tar backup engång per dygn, vilket ger oss en RPO på 24 timmar och återläsningen är som sagt beroende på volymensstorlek och vilken typ av media som säkerhetskopian ligger på. Men i detta exempel antar vi en RTO på 6-8 timmar.

Servern “briner upp”.
Att servern brinner upp är kanske inte troligt, men det jag vill ge exempel på i detta exempel är att hela systemet blir obrukbart. Vi måste alltså återställa hela systemet och återläsa samtliga volymer på hela servern, Eftersom vi hade en strategi att ta backup en gång per dygn är även här RPO 24 timmar men RTO är betydligt längre eftersom vi måste återläsa flera volymer. Dessutom måste vi återställa servern, ny hårdvara och ny infrastruktur. Nu måste vi ta hänsyn till leveranser av ny hårdvara och implementation av ny infrastruktur så RTO kanske blir flera dagar eller tilloch med veckor.

Datahallen “försvinner”.
Nu pratar vi “Disaster Tolerance / Disater Recovery (DR)” och jag kommer inte ta med det i detta exempel, ämnet är för stort och komplext. Har vi inte kontroll och koll på vår vanliga säkerhetskopiering så är DR lite overkill..

Det finns mänder med tekniker som kan hjälpa oss att vid olika typer av “händelser” få ner RPO och RTO så nära 0 som möjligt, och få en “Business Continuance”. Alltså oavsätt vilken typ av händelse som inträffar kan vi fortsätta att arbeta mot våra system. Typer av tekniker är kluster, snap-shot, clones, replication, o.s.v.

Men det jag vill understryka, oavsätt om vi pratar backup/restore, Disaster Recovery eller Business Continuance, är att dessa strategier inte är teknikdrivna strategier. Det är verksamhetsdrivna, affärsdrivna strategier som med hjälp av teknik införlivas. En backup-strategi måste invälvera verksamheten och applikationsägarna. Samtliga inblandade i verksamheten måste vara införstådda i vad som händer och vad som måste göras vid eventuell dataförlust. Vår säkerhetsstrategi är vår “data-försäkring”, slarvar vi får vi inte ersättning…….