Komplexa system bär per definition med sig möjligheten att saker kan gå fel. Olyckor är nästan omöjliga att undvika. De behöver dock inte bli förödande; allt beror på hur väl förberedd man är. Därför är det A och O att ha planer för hur man minimerar risker och gör utfallet så milt som möjligt. Och det är här som recovery models kommer in.
Inom SQL manifesteras riskminimeringen av just recovery models och hur man väljer att ta backuper. Dessa två beslut är dock väldigt tätt sammankopplade – valet av recovery model avgör vilka backuper man har tillgängliga. Det finns tre möjliga recovery models att välja mellan: simple, full och bulk logged. Valet av recovery model avgör även en del annan funktionalitet, exempelvis hur och om transaktionsloggar används.
Men innan vi kan gå igenom recovery models är det viktigt att förstå vilka tre backuper man kan ta. Den vanligaste backupen heter full. Detta är den sortens backup man intuitivt tänker på när man tänker på backuper - all data och all databasinformation sparas, så att du kan återställa hela miljön till ett funktionellt läge.
Att ta full-backuper varje dag tar dock lång tid och kräver mycket utrymme, och det är då differential-backuper kommer in i bilden. Dessa sparar allt som förändrats sedan senaste full-backupen. Dessa blir därmed mindre än full-backuperna och funkar enbart som komplement till dessa. De är dessutom kumulativa och ignorerar andra differentialbackuper, vilket innebär att du bara behöver läsa in den senaste differentialbackupen för att få alla förändringar på plats. En möjlig strategi för att minska utrymmet för backuper är att exempelvis ta full-backuper en dag i veckan och differential-backuper resterande dagar.
Dessa första båda backuper är tillgängliga i samtliga recovery models. Den tredje sorten, transaktionsloggsbackuper (förkortas till loggbackuper), är dock bara tillgänglig en del av dem. Dessa backuper sparar alla transaktioner som körts mot databasen sedan senaste full-, differential- eller loggbackupen. De är alltså inte kumulativa, som differentialbackuperna, utan hänger ihop i en kedja.
Nu kan vi börja gå in på recovery models. Vi börjar med den mest omfattande modellen: full. Full recovery model möjliggör alla sorters backuper, men kräver även att man administrerar transaktionsloggarna. Dessa töms nämligen inte per automatik i full recovery model – man måste ta loggbackuper för att de ska kunna trunkeras. Full tillåter inte att någon data slarvas bort.
Det faktum att man tar transaktionsloggsbackuper möjliggör också så kallas point-in-time recovery, vilket innebär att man kan återställa sin miljö till en viss tidpunkt på dagen. För att kunna använda denna funktionalitet bör dock loggbackuper tas ofta, gärna flera gånger i timmen.
Det vanligaste alternativet till full recovery model är simple. Denna modell förenklar en del administration, då transaktionsloggarna automatiskt rensas med tiden. Man kan i princip se det som att man inte har några transaktionsloggar. Det är heller inte möjligt att ta loggbackuper.
Detta omöjliggör en del annan funktionalitet, exempelvis HA-lösningar som AlwaysOn och log shipping. Men fördelarna av att ha en enkel modell, där man enbart behöver tänka på att ta full- och/eller differential-backuper, överväger ofta nackdelarna. Det är dock inte rekommenderat att ha denna modell på en produktionsmiljö, då man har lite mindre kontroll över hur databasen fungerar.
Det tredje alternativet, vilket används mer sällan, är bulk logged recovery model. Denna modell påminner mycket om full - skillnaden är att bulk logged använder en teknik för att minimera loggningen av vissa operationer. Detta ökar prestandan för bulkoperationer, men innebär dock att point-in-time recovery inte är möjligt. Detta är alltså användbart när man ska importera stora datamängder under en ganska kort tid.
Valet av recovery model är avgörande för hur din data sparas och vilka möjligheter du har för att återställa miljön utifall att det värsta skulle hända. Så gör dig själv en tjänst och undersök vilken recovery model du har och skräddarsy din backupstrategi efter vad är du är villig att förlora.
Gå in på Accigo.se/EKG för att lära dig mer om vad vi på Accigo kan göra för din IT-miljö.
Olle Kärnekull - olof.karnekull@accigo.se - Försäljning
Fredrik Hellstenius - fredrik.hellstenius@accigo.se - Solution Architect
Måns Rantzer - mans.rantzer@accigo.se - IT Infrastructure Consultant
Gustav Jansson - gustav.jansson@accigo.se - IT Infrastructure Consultant
