I disse år bliver flere og flere applikationer flyttet ud i skyen. Det sker af et væld af årsager, men i langt de fleste tilfælde er det for at konsolidere flere forskellige services eller for at simplificere driften.
Der findes tre store aktører på markedet: Microsoft med Azure Public Cloud, Amazon med Amazon Web Services samt Google med Google Cloud. I Danmark har markedet primært koncentreret sig om de to førstnævnte.
Cloud transformationen stiller ændrede krav til det omkringliggende driftsmiljø, og backup er naturligvis en del af dette. Hvis vi for en stund glemmer alle vitserne om at rigtige mænd ikke tager backup, så kan vi nok godt blive enige om at backup er et sundt valg i langt de fleste tilfælde.
Men hvad er egentligt vigtigt i forhold til backup af en applikation i public cloud? Lad os tage et kig på de 6 vigtigste overvejelser, du bør gå igennem, inden du vælger backup løsning til din MS Azure applikation.
1. Strategi
Den vigtigste strategiske overvejelse, I kommer til at foretage jer, er overvejelsen om, hvor backup’en skal placeres. Alle public cloud leverandører har backup som en del af deres servicekatalog, og i princippet er det meget hurtigt at komme i gang. Et par klik til at bestille backup, og dernæst lidt flere klik, hvor der bestilles compute og storage – så er man faktisk i gang.
Men ønsker man overhovedet at lægge backup’en i samme cloud infrastruktur som applikationen driftes i? For de fleste applikationer kan dette være udmærket, men der findes applikationer, der er så kritiske at den løsning simpelthen ikke er god nok. Ønsker man så backup’en i en private cloud? Eller måske on-premise?
Her er man nødt til at gøre sit forarbejde, og du kan med fordel inddrage jeres CISO i disse overvejelser. Hvis I allerede har en business continuity plan, er det sandsynligvis den, der skal angive retningslinjerne for hvilken model I bør gå med.
2. Backup-management
Langt de fleste virksomheder kommer i mange år til at befinde sig en i hybrid model, med on-premise, private cloud og public cloud applikationer. Desuden er applikationerne i clouden også meget forskellige. Nogle befinder sig i en IaaS-model, hvor man selv håndterer OS. Andre driftes på Azure PaaS-komponenter og andre igen befinder sig på en ren SaaS-model, som eksempelvis Office 365.
Hvis man har forskellige backup-løsninger til flere af disse – hvilket i forhold til den enkelte applikation måske kan give god mening – ender man hurtigt med at management-mareridt, hvor det er svært at have en ensrettet administration af backup på tværs af applikationerne.
3. Agilitet
Hvem skal håndtere backup på daglig basis? Giver det mening at applikations-ejeren skal igennem en centralt administreret IT-servicefunktion for at provisionere backup eller bestille restore af specifikke komponenter? Hvor høj en grad af agilitet, man ønsker, er en vigtig overvejelse.
Hvis I gør jer disse tanker inden løsningen tages i drift, kan det spare jer for en del hovedpiner efterfølgende. Helt generelt er bevægelsen indenfor rigtig mange grene af IT, at self-service bliver et større ønske. I den kontekst er det måske et skridt tilbage, hvis de personer, der har ansvaret for applikationen, ikke selv kan håndtere backup’en.
4. TCO
Hvis du vælger at placere backup’en som en del af jeres Azure driftsmiljø, drager du naturligvis fordel af en fleksibel Pay-As-You-Grow model, der kan skalere både ind og ud. Hvis ikke, bør du måske foretage en udregning af forventet Total Cost of Ownership for backup-løsningen, og sammenholde denne forventede omkostning med den forventede omkostning ved et komplet datatab.
Det kan lyde simpelt, men undertegnede har faktisk set eksempler på backup-løsninger, der kostede mere i drift end værdien af de data, det var hensigten at beskytte.
Desuden hører det også med til overvejelserne at en on-premise backup-løsning faktisk kan have et stort aftryk i virksomhedens samlede IT-miljø. Storage, compute, licenser, almindelig drift & vedligeholdelse, vedligeholdelse af kompetencer etc. Hvorvidt man vil acceptere dette aftryk eller man ønsker at konsolidere i skyen er en vigtig overvejelse.
5. Sikkerhed
Jamen backup er da sikkerhed? Ja, og netop derfor er jeres samlede sikkerheds- og business continuity -politik meget vigtig for jeres overvejelser. Hvis data er ekstremt kritisk for forretningen, er det langt fra sikkert at en cloud-baseret back up er nok for jer, og sandsynligvis skal en fysisk backup være en del af jeres løsning.
Pointen er at sikkerhedsovervejelser, der er funderet i en god risikovurdering og en velformuleret business continuity plan er ret vigtige for at jeres backup kan fungere som det, den er tænkt til: Et sikkerhedsnet I kan anvende, hvis uheldet er ude.
6. Restore test
Lad os for en stund vende tilbage til vitsen: Rigtige mænd og så videre. Stort set alle virksomheder har efterhånden accepteret, at de ikke er rigtige mænd, men snarere nervøse teenagere, før deres første date. Eller sagt så det kan forstås: Næsten alle virksomheder tager backup.
Det rejser bare et par yderligere spørgsmål:
- Hvis uheldet er ude, vil jeg så være i stand til at genskabe data?
- Hvor lang tid vil det tage mig at genskabe data?
I en verden hvor næsten alle virksomheder tager backup af deres data, er det til gengæld meget få virksomheder, der tester restore af data. Det kan undre, for det er faktisk en praksis, som diverse sikkerhedsfirmaer har anbefalet i årevis.
Der er flere ting, der potentielt kan gå galt, og den første er naturligvis at restore simpelthen ikke virker. Altså at den backup, man troede, man havde, reelt er værdiløs.
Et andet problem kan være, at restore vil tage så lang tid, at man lige så godt kan lade være med at have backup’en. Hvis virksomheden har en så høj risiko forbundet med et givent system, at virksomheden kun kan tåle at systemet er nede i eksempelvis 8 timer, så nytter det ikke så meget at restore af data i det pågældende system vil tage et døgn.
På trods af det faktum er der ikke mange virksomheder, der har en procedure for test af restore af data. Fra Netics side vil vi gerne opfordre til at restore test bliver en del af jeres overvejelser.
Hvis man gør brug af de indbyggede backup-services i Azure, har man faktisk adgang til Restore-as-a-Service. Det vil sige at man kan mounte et cloud recovery point som et volume, og derefter i et point-and-click interface browse i det og vælge præcis de filer, man ønsker at genskabe.
Alt i alt
Der er ingen tvivl om at det er let at håndtere backup i MS Azure. I parentes, er stort set alle operationer lette i Azure. Fra Netics side ønsker vi blot at gøre opmærksom på, at overvejelserne om backup starter et helt andet sted. Nemlig – som de fleste andre IT-sikkerhedsovervejelser – med vurderinger af, hvor høj en risiko virksomheden har på den pågældende applikation.
Den vurdering kan så danne grundlag for de nødvendige beslutninger:
- Kan vi ”nøjes” med at have backup’en i Azure?
- Hvad skal retention time være?
- Skal vi bevare vores on-premise backup?
- Skal vi have fysisk backup?
…og så videre.
Hvis du har spørgsmål til strategi, teknologivalg eller blot ønsker lidt praktisk hjælp til at komme i mål med en backup-strategi for dine public cloud applikationer, så er du velkommen til at tage fat i os.