Kom godt i gang med backup af Azure SQL Databaser

Backup. Suk. Vi skal tage backup - og vi gør det også. Men det er dyrt og besværligt, og vi er ikke helt sikre på, at vores backup er brugbar den dag vi virkeligt mangler den.

Nogenlunde sådan kan mange IT-folks holdning til backup beskrives.

I tilfældet Public Cloud er backup faktisk ret let at have med at gøre. Altså på en hands-on dag til dag måde. Ud fra eksemplet Microsoft Azure, viser Netic her hvor let det er, at tage backup i en Public Cloud PaaS verden.

Hvad er Azure SQL Databases?

Microsoft har forskellige muligheder, hvis vi ønsker at have en vores databaser kørende på Azure platformen. Azure SQL Databases er hvad vi kalder en ”fully managed” løsning.

Med Azure SQL Databases behøver vi altså ikke bekymre os om operative systemer, patch management og udbygning af hardware infrastruktur, og backups i denne løsning er, tildels, automatisk. Azure SQLs backup løsning giver desuden mulighed for at restore en database til et bestemt tidspunkt og til den samme database-server.

Azure SQL Databases er som udgangspunkt fuldt ud kompatibel med Microsoft SQL Server. Du kan eventuelt læse mere om hvornår du bør vælge SQL Server eller Azure SQL Databases her.

Før vi gennemgår de forskellige backupmuligheder i Azure SQL Databases, skal der være oprettet en database og en database server i Azure portalen.

Oprettelse af database og database server

I vores eksempler benytter vi Azure portalen til oprettelse og konfiguration, men al funktionalitet er også tilgængelig via Azure CLI og PowerShell.

1. Vi starter med at oprette en database og en database server. Azure portalen tilbyder at oprette en server, hvis vi ikke allerede har en instans der kan indeholde vores database.
2. Vi opretter databasen ”backup-demo” og serveren ”backupdemo1.database.windows.net”, som vist i nedenstående eksempel:
3. Efter et lille stykke tid kan vi se vores nyoprettede database og database server under ”All ressources”.

Backup-mulighed 1: Point-in-time recovery (PITR)

Alle databaser i Azure portalen oprettes som standard med point-in-time recovery (PITR) backup slået til. Denne backup type fungerer ved at Azure laver en backup af transaktionsloggen hvert 5 – 10 minut (frekvensen er baseret på performance niveauet og database aktiviteten). Ved at bruge backup muligheden PITR giver det os mulighed for, at vælge hvilket tidspunkt vi ønsker at gå tilbage til indenfor retention perioden, hvis vi skulle få behov for vores backup.

Retentionperioden for PITR afhænger af service tier og vil derfor være forskellig:

Restore

Hvis vi ser nærmere på vores backup-demo database, kan vi se information omkring vores ældste restore point, og vi har mulighed for at restore databasen fra en backup.

Hvis vi vælger ”restore” vil vi se at vi har muligheden for at vælge mellem to kilder, vi vælger Point-in-time.

Bemærk at vi ikke kan rulle vores kørende database tilbage. Får vi behov for vores backup, er vi altid nødsaget til at oprette en ny database på baggrund af backuppen. Dette sker for at sikre at vi ikke ved et uheld overskriver vores produktionsdatabase med en backup.

Backup mulighed 2: Long-term backup retention (LTR)

Hvis vi har brug for at beholde vores backup i længere tid end 7-35 dage som PITR tilbyder, kan vi definere en long-term backup politik, der gør det muligt at opbevare backups i op til 10 år. Afhængigt af applikationen kan der være forskellige årsager til at man evt. ønsker en højere retentionperiode, end de 35 dage. Det kan f.eks. være regler i forbindelse med regnskabsloven, eller et behov for at kunne teste en opgradering fra en gammel version af et databaseskema til sidste nye. Long-term backup retention kan gøres på følgende måde:

1. Vi klikker os ind på ”SQL Server” bladet i Azure portalen. Bemærk at vi her skal have fat i SQL Serveren vi oprettede sammen med databasen, og ikke databasen i sig selv.
2. Vælg den eller de databaser du ønsker at konfigurere en long-term retention politik for.
3. Her er det muligt at justere hvor længe vi ønsker at kunne gå tilbage med PITR, der vil typisk ikke være et behov for at reducere perioden fra standarden. Hvor længe vi ønsker vores long-term retention at strække sig over vil naturligvis være afhængig af vores data, og hvordan vi benytter dem. Et fornuftigt udgangspunkt for mange kunne være at have en ugentlig backup til rådighed et år tilbage og herefter have en månedlig backup for de næste fem år. En årlig backup giver sjældent mening, især ikke hvis vi har de månedlige backups fem år tilbage.

Backups fra long-term retention genskabes på samme måde som vores PITR tidligere, vi vælger blot long-term backup retention som kilde i stedet, og herefter den specifikke backup vi ønsker at genskabe.

Selvom Azure SQL Database generer backups automatisk, er vi ikke beskyttet mod sikkerhedshuller i vores applikationer og brugere der sletter/redigerer forkert data.

Vi er altså stadig afhængig af en god backup strategi, også selvom man har en Cloud-baseret infrastruktur. I dette indlæg kan du læse om de 6 vigtigste overvejelser du bør gå igennem inden du vælger backup løsning til din MS azure applikation.

Hvis du har spørgsmål til strategi, teknologivalg eller blot ønsker lidt praktisk hjælp med dine backup muligheder, så er du velkommen til at tage fat i os.