Artikel IT-infrastruktur
Hur utför vi restore tester?
Vi som jobbar inom IT är ju väldigt bra på att göra första delen, nämligen köra backuper.
Vi har schemalagt alla backuper och har rutiner för att hålla koll.
Vi tränar på det varje dag och kollar status och kör om jobben som inte gått bra.
Vi är bra på backup.
Men egentligen får vi inte betalt för att göra alla dessa backuper. Det är restore som är det viktiga. Det är restore som vår uppdragsgivare vill ha hjälp med. Att vi levererar proffesionellt och effektivt när det verkligen gäller.
Ändå görs det förvånansvärt få restoretester. Vi tränar inte, framförallt inte de svåra scenarierna. Vi borde ha samma regelbundna schemaläggning av restorer som vi har för backuper.
Så att vi tränar på det.
Så att vi redan har sprungit på fallgroparna.
Så att vi redan har hittat lösningarna.
Så att vi redan har anpassat våra system.
Så att vi vet hur man gör när det verkligen gäller.
Så att vi är förberedda.
Buggar och problem vid restore – varför backup inte alltid är garanterad att fungera
Oavsett vilken backupprogramvara du använder så är programkoden garanterat testad för backup fler gånger än restore. Det kan finnas buggar och udda saker som händer vid restore. Inte säkert att en backup som står som success går att läsa tillbaks. Och går det bra tar det säkert längre tid. Programvaran är optimerad för backup och använder smarta funktioner för att minska resurskraven i it-miljön. Vi tar inkrementella backuper. Smart!
Vi använder parallella dataströmmar, deduplicering och tar bara med ändrade block och bygger syntetiska fullbackuper. Produkten är bra på backup. Ändå tar fullbackuperna en stor del av helgen…
Tänk igenom restore-processen innan olyckan är framme
Infrastrukturen räcker till för produktionen och vår optimerade backup.
Men vid restore ska ofta allt data, alla block tillbaks. Och är det ett totalhaveri ställs det stora krav som vi kanske inte dimensionerat för. Servrar o nätverk ska plötsligt skyffla 2, 10 eller 100 ggr så mycket data, beroende på hur smart backupen var. Vid restore behöver du massor av bandbredd och lagring. Du behöver namnstandard, flera virtuella nät och ip adresser. Ordning o reda helt enkelt! Det är bra att ha tänkt igenom det innan.
Hotet från ransomware
enklare hot som en borttappad fil eller en kraschad server kan du säkert få till men svårare fall som en smygande korruption, en ransomware attack eller personal som blivit osams med firman är inte lika enkelt.
Vi är förskonade mot många naturkatastrofer i Sverige och duckar lite när leverantörerna pratar om tornados och tsunamin. Men ransomware är en hel industri, ett helt ekosystem med organisationer som bygger ransomware as a service. De omsätter mer än drogkartellerna Och Sverige är lika utsatt som andra.
Tips på att komma igång med återläsningstester
Nu nosade vi på utmaningar med disaster recovery, men i alla fall här kommer några tips för att komma igång.
Börja med att rutinmässigt göra enklare restoretester. Gör olika scenarier varje gång.
Återställ en fil, en server, en databas, en tabell, en användare i AD:t. Återställ från disk, från moln, från tape, från immutable storage.
Hur länge sparar du backupen? Flera månader? Läs tillbaks en gammal kopia av en server, fundera på hur man loggar in. Behövs lösen till local administrator? Använder jag LAPS eller Kerberos, behöver jag en domänkontrollant eller andra komponenter från samma tidpunkt för att komma in?
Definiera vad som är en godkänd återläsning, räcker det med att servern bootar upp eller behöver databasen svara på ett speciellt sätt.
Skapa namnstandard för återlästa objekt, det blir lätt rörigt när många versioner behöver kontrolleras om de tex innehåller virus.
Skapa separata nätverk för återlästa virtuella maskiner. Utnyttja funktioner i backupprogrammet för att automatisera tester som du redan har koll på och lägg till antiviruskontroll.
Så småningom kan du återställa ett sammanhängande system med flera servrar och databaser med inböres beroenden. Och när du kommit så långt…
Börja prioritera systemen. Väck frågan internt och bearbeta organisationen. Alla ska vara överens om i vilken ordning systemen ska återläsas vid större haverier. Vilken bas behövs. Vilka affärssystem måste igång först. Systemägarna ska vara överens, skriftligen, om prioritetsordningen.
Sammanfattningsvis
Börja träna, schemalägg, variera, automatisera, bygg infrastruktur efter förväntningar, få med alla på tåget
Vi på Zitac hjälper gärna till.
