Lär dig SQL Server Disaster Recovery
Förord
Disaster recovery är något som finns i huvuden på alla DBAs. Här får du chansen att lära dig något om grunderna till SQL Server Disaster Recovery från den ledande experten i detta område, Greg Robidoux i Innehåll
»»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
Lär dig om SQL Server Disaster Recovery
av Brad M. McGee
Berätta om dig själv, din bakgrund, din utbildning, samt din erfarenhet av SQL Server
Jag har arbetat i IT industrin nu i närmare 15 år. Jag började med att hantera nätverk, men jag flyttade över till databassystem relativt tidigt i min karriär. Under min karriär så har jag arbetat med SyBase, Oracle och relativt nyligen även SQL Server. Jag har arbetat med små klienter med en enda SQL Server upp till klienter med över 100 SQL Servers. Några av de områden som jag har arbetat inom SQL Server med inkluderar uppgraderingar, planering för Disaster Recovery, Change Management kontroller, projekthantering, SAN integreringar, produktval, centraliserad hantering samt applikationsutveckling på SQL Server 6.5, 7.0 och 2000 plattformer.
Berätta om din konsultfirma
EdgeWood Solutions grundades i januari 2002 med affärsidén att förbättra Microsoft SQL Server plattformen. Det gör vi genom att implementera lämpliga och nödvändiga komponenter i SQL Server som oftast glöms bort. Det finns komponenter, såsom Disaster Recovery, som sällan nämns vid namn, men som vi känner är en mycket viktig del i en förnuftig databasimplementering.EdgeWood har som fokusering att utveckla nyckelkomponenter till SQL Server som de flesta DBAs vet att de borde ha, men inte har eftersom den största delen av deras tid går till att hantera omedelbara databasproblem. Så istället för att erbjuda lösningar för alla aspekter av SQL Server så namnger vi sådana saker som sällan namnges, men som borde finnas där. Och dessa områden inkluderar:
- Change Management
- Säkerhetspolicies
- Planering för Disaster Recovery
- Projekthantering för SQL Server projekt
- SQL Server uppgraderingar
- Underhållsplanering
- Prestandaanalys och optimering
Vi undersöker och rekommenderar också mjukvaruprodukter som har utvecklats specifikt för SQL Server. Vi letar efter de bästa produkterna och erbjuder dessa lösningar till våra klienter. Än så länge så har vi ett partnerskap med SQL LiteSpeed (se hänvisning till artikel ovan), Lumigent (se artikel ovan) samt Precise Software Solutions. Var och en av dessa lösningar erhåller en unik fördel till SQL Server industrin samt ekonomi för DBAs som måste hantera många olika projekt med en kort deadline.
SQL Server Disaster Recovery har blivit ett stort ämne, och vi vet allihopa de uppenbara orsakerna till att förbereda för en Disaster Recovery plan. Men vilka är de mindre uppenbara orsakerna till varför en Disaster Recovery plan är en kritisk del i en organisation?
När de flesta människorna talar om en Disaster Recovery så tänker de oftast på en hel site som har förstörts. Trots att det är möjligt så är det inte särskilt troligt att en hel site går till spillo, såtillvida att inte siten råkar ut för en naturkatastrof, som t ex översvämning, storm eller en tornado.När jag tänker Disaster Recovery så tänker jag på att eliminera någon oplanerad downtime, vilket kan skada ett företag rejält. Det kan orsakas av otillräcklig strömförsörjning, inkorrekt kodning som har implementerats i produktion, eller hårdvarufel. De flesta företag som har SQL Server installationer förlitar sig på att SQL Servern ska vara tillgänglig dygnet runt, sju dagar i veckan, för att kunna driva företaget. Och då fler och fler företag börjar gå globalt med sina produkterbjudanden (tack vare Internet) så minskar den tillgängliga ytan för oplanerad downtime, och man vill helst att downtime inte ska uppstå överhuvudtaget.
En av de saker som måste nämnas, men som ofta glöms bort, är faktiskt att avgöra hur mycket downtime som är acceptabelt för ett företag, vilket leder till att man måste skapa en grundlig plan som möter dessa behov. Men det är ofta svårt att få fram en realistisk tid där systemet måste vara tillgängligt för användarna och underhåll. Och eftersom det kan vara en snäv tidsrymd så är det ofta svårt för alla DBAs att planera för något som inte verkar realistiskt.
Vad exakt täcker en Disaster Recovery plan?
En Disaster Recovery plan är invecklad, man måste kunna täcka både företaget och det tekniska. Min rekommendation är att planen ska täcka alla sorters downtime för systemet, oavsett om det är så litet som en enda tabell eller så stort som en hel site. Planen bör lämpligen baseras på företagets behov, och inte bara genom att implementera teknologier som inte löser omedelbara och långvariga behov.De planer och procedurer som skrivs och implementeras måste ha med alla möjliga sorters hot av oplanerad downtime i sina beräkningar. Om vi t ex tittar på hot som virus, hackers, misstag från DBAs samt andra katastrofer, så är en Disaster Recovery plan bara en komponent i en fullt funktionell samling processer som måste implementeras. DBAs måste dessutom ta en titt på Change Management, säkerhet samt några generella övningar för att förhindra downtime.
Vilka steg bör man gå igenom för att skapa en Disaster Recovery plan?
Baserat på min erfarenhet så är det bäst att börja med en mindre plan, och påbörja processen med framtida mål som är testade och implementerade i ett fördefinierat schema. Som t ex:- Bestäm företagets behov av tillgänglighet likväl som den aktuella budgeten för lösningen.
- Avgör vilka katastrofer som man måste förhindra, men även återhämta sig från, inklusive misstag, hackers, hårdvarufel samt databasfördärv.
- Planera processen för datainsamlingens Disaster Recovery.
- Dokumentera din miljö enligt standardiserade dokument, med avseende för hårdvara, mjukvara, applikationer samt personal.
- Utveckla en kontaktlista samt utökningsnivåer
- Utveckla ett mediakit som innehåller alla nödvändiga mjukvaruversioner och servericepacks.
- Standardisera alla Servers konfigurationer.
- Ha backups enkelt och tillgängliga på hårddisken (se artikeln om LiteSpeed för information om mindre och snabbare backups).
- Ha hårdvara till Servrarna tillgängligt.
- Skapa en kommunikationsplan för återhämtningsprocessen.
- Testa planen för att försäkra dig om att det lyckas.
- Implementera lösningen.
- Ta en titt på en tredjepartens verktyg som kan hjälpa till att samla in Serverinformation (BindView för SQL Server samt NetIQ ConfigurationManager för SQL Server).
- Titta på en tredjepartens verktyg som kan restaurera förlorade data (Lumigent Log Explorer).
- Och slutligen så är det viktigt att man håller dokumenteringen uppdaterad!
Hur stor del utgör dokumentationen i en Disaster Recovery plan?
Dokumentationen är en av huvudkomponenterna till att ha en framgångsrik Disaster Recovery process. Utan dokumentationen så är det väldigt svårt att utföra en välplanerad återhämtning. Vad som händer i de flesta instanser är att återhämtningsprocessen fungerar som vid brandsläckning. Det är flera olika åtgärder som är i agerande för att hantera problemet, utan att man egentligen vet vad som orsakade det, eller om det har orsakat något kvarstående problem. Det har hänt alltför ofta att inte dokumentationen har haft första prioritet, eller att den inte är i ett förståeligt format för DBAn. Oftast så förlitar sig DBAs på personlig erfarenhet, tidigare e-mails eller en snabb Internetsökning för att kunna lösa problemet.En läslig DR dokumentation innefattar följande:
- Kontakt- och utökningslista
- Listor på softwareversioner och servicepacks
- Hårdvarukonfigurationer
- Servrarnas namn och IP-adresser
- Utsatta personer
- Utsatta applikationer
- Prioriteringsordning för Servrar och applikationer vid återhämtning
- Återhämtningsscenarion; tabell, databas, Server, datacenter
Hur identifierar du de mest sårbara delarna i SQL Server?
SQL Server användes tidigare till avdelningsapplikationer, vilka inte fick så mycket support från IT avdelningen. Det gjorde att downtime eller omflyttning av data blev en acceptabel process. Men nu när SQL Server har flyttats ut till storföretagen så är det väldigt viktigt att företagen implementerar en fullt förståelig återhämtningsplan till sina SQL Servers.Många företag har spenderat otroligt mycket pengar på redundant hårdvara, ström samt aircondition, men sen går det sällan mycket längre. Jag antar att de känner att så länge som inte hårdvaran fallerar så finns det inget annat att oroa sig över. Om inte företagen planerar att implementera en komplett återhämtningsplan så skulle jag nämna Change Management processen till dem. Förutom hårdvaran så beror ett fallerande ofta på felkodning eller mänskliga misstag. Med en sund Change Management process så skulle den här sortens fallerande vara i stort sett eliminerad.
Hur föreslår du att DBAs ska testa sina återhämtningsplaner?
Ett hot av total katastrof, vilket skulle innebära att hela siten går ner, är inte särskilt vanlig. Det verkliga hotet som man bör akta sig för är isolerade katastrofer och återhämtning från dessa missöden. Det kan vara tabeller som försvunnit, enorma uppdateringar som inte kan ångras, dålig kodning som implementerades i produktionsmiljö, osv. Eftersom den här sortens katastrofer inträffar allt oftare så bör DBAs (utan något tillgänglig DR plan) börja med saker som de kan återställa själva. När sedan dessa problem väl är lokaliserade och dokumenterade så kan DBAn börja arbeta med andra IT och företagsavdelningar, för att kunna fastställa en mer förståelig lösning som gäller för hela företaget.Man bör testa så ofta man bara kan. Desto fler tester som genomförs och desto fler övningar som utförs, ju bättre kommer planen att bli när man behöver den på riktigt. Man bör basera scenarion på tidigare inträffade problem, och man ska skriva planen enligt dessa hanteringar. Gällande utrustning så vore det bra om man kunde simulera produktionsmiljön, men då budgeten kan komma emellan så går det lika bra att sätta upp en desktop PC som testmaskin. Det är inte särskilt dyrt att implementera en liten testserver, och om ett företag är beroende av tillgängligheten av databasservern så måste DBAn hantera alltihop genom testservrar.
Vad kan du ge för tips till DBAs när de kör en backup på sina data, för att försäkra sig om att de kan återhämta alla data?
Tillsammans med exekverande backups så måste DBAs utföra en databasåterhämtning för att försäkra sig om att alla backups är giltiga. Jag publicerade nyligen en artikel som heter ”Backup and Restore – to Basics with SQL LiteSpeed” som går att finna på våran webbsida - Man bör först köra en backup på hårddisken, för att få en snabbare backup och återhämtning
- Verifiera backups
- Testa återhämtningar
- Använd full återhämtning för att förhindra att data förloras
- Använd en kombination av full, delvis och transakionsbackup
- Exekvera regelbundet en full återhämtning av systemet för att se till att planen är framgångsrik
Kan du rekommendera någon specifik hårdvarukonfiguration (Cluster, Hot Server, RAID, osv) för SQL Server för att förhindra potentiella sårbarheter?
Ju mer redundant en miljö är desto bättre kan man peka ut sårbarheterna. I de flesta hårdvarukonfigurationerna så har den tekniska personalen spenderad tillräckligt med resurser på att ha redundanta hårddiskar, kontroller, strömförsörjning, nätverkskort, osv. De har dessutom spenderat en massa tid på att konfigurera replikeringar, Cluster och standby Servers. Men den aspekten som de flesta företag glömmer bort att implementera är Change Management processen som borde hanteras i samband med investeringen av hårdvaran. Tyvärr så kan inte den mest perfekta hårdvaran förhindra att någon med lämpliga privilegier går in och ändrar konfigurationen eller lägger in ny kod till produktion. Dessa processer är minst lika viktiga som hårdvarumiljön när det gäller tillgängligheten. Den idealiska hårdvarukonfigurationen beror faktiskt på typen av miljö samt behovet av tillgänglighet. Det finns flera olika alternativ som skulle kunna appliceras för den här ideala setupen, men här är kostnaden ofta den förebyggande faktorn. DBAs måste bestämma vilken som är den acceptabla tiden för downtime, och sen ska hårdvaran konfigureras enligt detta behov. Det mest idealiska är att ha en standardiserad hårdvaru- och SQL Serverkonfiguration över alla Servrar.
Om det värsta skulle inträffa och den fysiska utrustningen skulle försvinna, hur förhindrar man bäst att sådant sker? Och hur återhämtar man sig från något sådant?
I just det scenario som du förklarade för mig så är det viktigt att man tar med sådana saker i upptäckten och planerandet av återhämtningsprocessen. Det är alltid bäst att planera för alla möjliga typer av fallerande, hellre än att ta upp saken när det verkligen händer. Baserat på hur kritiska alla data är så kan det vara nödvändigt att skapa en hot site på et annat geografiskt ställe, där det sitter anställda. Om en site har förstörts så är det vanligt att personalen på det utsatta stället inte känner till företagets behov med avseende på transportfrågor eller extra prioritet. I så fall kan det vara bäst att ha en separat anordning med personal. Om en hel site har förstörts så kan man inte återhämta allt samtidigt. Det är därför väldigt viktigt att man har planerat en Disaster Rocovery process med en prioriteringslista av Servers och applikationer, så att dessa kan tas om hand först. Det kan dessutom finnas andra Servrar som kräver samma resurser, så för ett sådant här scenario så är det väldigt viktigt att man har en bred planering och god dokumentation.
0 Kommentarer