Därför ska du ha koll på backuperna

Det är för många en självklarhet att ta backuper men frågan är om du har koll på backuperna du tagit. Det kan ju bidra till ytterst tråkiga historier om informationen inte går att återställa som man gjort backup på. Vad hjälper en backup om den inte är brukbar? Ingenting! Därför ska du ha koll på backuperna. 

Full koll på backuperna

I dessa tider är det viktigt att ha koll på backuperna eftersom riskerna att bli utsatt för cyberattacker eller andra hot har ökat kraftigt. Med en osäker omvärld kan allt hända och det gäller därför att se till så att man har full koll på backuperna. Genom att ha koll minskar risken att skadan som kan ske blir för stor för att inte kunna repareras om ett angrepp är ett faktum.  

Vi får en del förfrågningar runt korruption i databaser och när man undersöker vilka möjligheter vi haft att reparera skadan har det visat sig att man inte har haft så bra koll på backuperna som man trodde. Det kan bli en mycket kostsam historia för verksamheten om man tappar data i affärskritiska system.  

Nedan kommer ett par exempel från verkligheten och även några saker som kan vara viktiga att tänka på när man sätter upp sin backuplösning. 

En kund hör av sig till oss och säger att de har problem med en databas. Log-filen är borta. Vi försöker starta upp databasen utan log-fil men då hamnar den i Recovery Pending eftersom den inte kan spela upp det som skulle finnas i log-filen. Vi provar att ta upp databasen i Emergency Mode. Då kan vi komma åt innehållet i tabellerna med SELECT men vi vet inte vad som är skadat eller borta. Att köra DBCC Checkup med REPAIR kommando fungerade inte heller.  

Det enda alternativet för att rädda databasen är att återläsa den från en backup. Tyvärr hade man inte satt upp backuper för en enda databas. Man var i konfigurationsfasen för systemet. Man fick ta beslutet att börja om från början med konfigurationen samt anpassningar och förlorade två veckors konsultarbete med förskjutning i tidsplanen som följd.  

Slutsats: Håll koll på backuperna, det kan spara både tid och pengar. 

En kund hör av sig till oss en måndag med anledning av att dom haft problem med ditt SAN (Storage Area Network) under helgen och att backuperna med transaktionsloggarna misslyckats på grund av korruption i log-filerna. Vi åtgärdar det problemet genom att först ställa om databaserna till SIMPLE RECOVERY MODEL och sen till FULL RECOVERY MODEL. Sen tar vi en Full Backup och log-backuperna hoppar igång igen.  

För en extra kontroll kör vi också en DBCC CheckDB på alla databaser. Då visar det sig att fyra databaser också har korruption i datafilen. Vi vill då som första alternativ göra en återläsning från senaste fungerande backup. Den har dock redan hunnits tas bort från disk så vi vänder oss till tredjepartsapplikationen som ska arkivera filerna till långtidslagringen. Nu visar det sig att den har hängt sig och vi kan bara få en backup som är tre veckor gammal.  

Tre av databaserna lyckades vi med olika medel att rädda men den fjärde gick inte att göra något åt. Återläsning från den gamla backupen och tre veckors data var nu borta.  

Slutsats: Kontrollera att dina backuper verkligen fungerar  

Vid en genomgång hos en kund upptäcker vi att schemat för backupen ser ut enligt följande:  

• Full backup EN gång per dygn klockan 23:00
• Log backup EN gång per timme 
• Backup av filer EN gång per dygn klockan 01:00 

SQL backup jobbet tar bort alla gamla backuper som är äldre än 15 timmar. Det betyder att log backuper mellan klockan ett på natten och elva på morgonen inte kommer med till långtidslagringen. Om man då måste göra en återläsning till en viss tidpunkt går inre det eftersom det saknas log-backup-filer att återläsa från (backup-kedjan är bruten).  

Slutsats: Man måste ha koll på hela backupkedjan  

Det är många saker man måste tänka på för att man verkligen ska kunna säga att man säker på att man har en backup/restore process som fungerar. Här kommer några saker som vi tycker är bra att kunna bocka av:  

• Ta backup av databaserna så att det passar din organisations krav på RPO (acceptabel dataförlust).
• Kontrollera att filbackup fungerar och täcker över tid så att ni får med alla filer
• Regelbundna (helst automatiserade) återläsningstester med DBCC CheckDB inkluderat
• Regelbundna integritetskontroller med DBCC CheckDB 

  
Tänk igenom ordentligt vad ni har för krav och önskemål gällande RPO och RTO innan ni sätter upp er backup/restore process. Det kan komma att rädda ditt jobb! 
 
Läs artikeln: Testar du företagets backuper? >

Läs artikeln: Varför behövs Restore Test as a Service? >

Läs om vår tjänst: Database Restore Test as a Service >