I disse tider er det vigtigt at holde øje med sin backup, da risikoen for at blive udsat for cyberangreb eller andre trusler er steget markant. Med et usikkert miljø kan alt ske, og det er derfor vigtigt at sikre, at du har fuld kontrol over din backup. Ved at have kontrol minimere du risikoen for, at skaderne bliver for store til at blive repareret, hvis et angreb skulle ske.
Vi får en del henvendelser om korruption i databaser og når man undersøger hvilke muligheder vi havde for at reparere skaden, har det vist sig, at man ikke har haft så godt styr på backup, som man troede. Det kan blive en meget bekostelig affære for virksomheden, hvis man mister data i forretningskritiske systemer.
Nedenfor er et par eksempler fra det virkelige liv samt nogle ting, der kan være vigtige at overveje, når du konfigurerer din backup-løsning.
Eksempel 1: Om at måtte starte forfra
En kunde kontakter os og siger, at de har et problem med en database. Logfilen er væk. Vi forsøger at starte databasen uden en logfil, men så ender den i Recovery Pending, fordi den ikke kan afspille det, der skulle være i logfilen. Vi forsøger at hente databasen i nødtilstand. Så kan vi få adgang til indholdet af tabellerne med SELECT, men vi ved ikke, hvad der er beskadiget eller mangler. At køre DBCC Checkup med REPAIR-kommandoen virkede heller ikke.
Det eneste alternativ for at redde databasen er at gendanne den fra en backup. Desværre blev der ikke oprettet backup for en enkelt database. Man var stadig i systemets konfigurationsfase. Man blev nødt til at træffe beslutningen om at starte forfra med konfigurationen samt tilpasninger og mistede to ugers konsulentarbejde med forsinkelse i tidsplanen som følge.
Konklusion: Hold styr på din backup, det kan spare både tid og penge.
Eksempel 2: Problemer med SAN og langt større udfordring end forventet
En kunde kontakter os en mandag, fordi de havde problemer med deres SAN (Storage Area Network) i weekenden, og backup med transaktionsloggene mislykkedes på grund af korruption i logfilerne. Vi løser problemet ved først at justere databaserne til SIMPLE RECOVERY MODEL og derefter til FULL RECOVERY MODEL. Herefter tager vi en fuld backup, og log-backup starter igen.
Som en ekstra kontrol kører vi også en DBCC CheckDB på alle databaser. Det viser sig, at fire databaser også har korruption i datafilen. Vores første valg er at gendanne fra den seneste fungerende backup. Desværre er den allerede blevet fjernet fra disken, så vi henvender os til tredjepartsapplikationen, der skulle arkivere filerne til langtidsopbevaring. Nu viser det sig, at applikationen er gået ned, og vi kan kun få en backup, der er tre uger gammel.
Det lykkedes os at redde tre af databaserne, men den fjerde database kunne ikke reddes. Gendannelse fra den gamle backup betød, at der nu manglede tre ugers data.
Konklusion: Tjek, at din backup virkelig virker
Eksempel 3: Databaseanalyse - Health Tjek
Under en gennemgang hos en kunde opdager vi, at tidsplanen for backup ser ud som følger:
SQL backup jobbet fjerner alle gamle backups, der er ældre end 15 timer. Det betyder, at log backups mellem klokken et om natten og elleve om morgenen ikke vil blive inkluderet i langtidsopbevaringen. Hvis man skal foretage en gendannelse til et bestemt tidspunkt, vil det være umuligt, fordi der mangler log backup-filer at gendanne ud fra (backup-kæden er brudt).
Konklusion: Du skal holde styr på hele backup-kæden
For at man virkelig kan sige, at man har en backup/restoreproces, der fungerer, er der mange ting, man skal overveje. Her er nogle ting, som vi mener, er vigtige at have styr på:
Tænk grundigt over dine krav og ønsker vedrørende RPO og RTO, før du opretter din backup/restore-proces. Det kan redde dit job!
Læs artiklen: Tester du virksomhedens backup? >
Læs artiklen: Hvorfor har du brug for Database Restore Test as a Service? >
Læs om vores tjeneste: Database Restore Test as a Service >