Den senaste tiden har vi fått en hel del förfrågningar kring korruption i databaser…
Den senaste tiden har vi fått en hel del förfrågningar kring korruption i databaser och när man undersöker vilka möjligheter vi haft att reparera skadan har det visat sig att man inte haft så bra koll på backuperna som man trodde. Det kan bli väldigt kostsamt för verksamheten om man tappar data i affärskritiska system.
Här kommer några exempel ur verkligheten och även några saker som är viktiga att tänka på när sätter upp sin backuplösning.
En kund hör av sig till oss och säger att dom har problem med en databas. Logiflen är borta. Vi försöker starta upp databasen utan logfil 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 Checkdb med REPAIR-kommando fungerar 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 denna databas. Man var i konfigurations-fasen för systemet.
Man fick ta beslutet att börja om från början med konfigurationer och anpassningar och förlorade ca 2 veckors konsult-arbete med förskjutning i tidsplanen som följd.
Slutsats: Backuper 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 sitt SAN under helgen och att transaktions logs backuperna misslyckas på grund av korruption i logfilerna. 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å DBCC CheckDB på alla databaser. Då visar det sig att 4 databaser även 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 3:e parts-applikationen som skall arkivera filerna till långtidslagringen. Nu visar det sig att den har hängt sig och vi kan bara få en backup som är 3 veckor gammal.
Tre av databaserna lyckades vi med olika medel att rädda men dem fjärde gick inte att göra nått åt. Återläsning från den gamla backupen och 3 veckors data borta.
Slutsats: Kontrollera att dina backuper verkligen fungerar
Vid en genomgång med en kund upptäcker vi att schemat för backuper ser ut enligt följande:
- Full backup 1 gång per dygn kl 23
- Log backup 1 gång per timme
- Backup av filer 1 gång per dygn kl 01
SQL backup jobbet tar bort alla gamla backuper som är äldre än 15 timmar.
Det betyder att log backuper mellan mellan 1 på natten och 11 på morgonen inte kommer med till långtidslagringen. Om man då måste göra en återläsning till en viss tidpunkt går inte 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 finns många saker man måste tänka på för att man verkligen skall kunna säga att man är 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 !
Lycka Till!