i öppningskapitlet i Craig Mullins bok, databasadministration, säger han ”på många sätt är affärer idag data”. Inom de flesta organisationer är den person som ansvarar för att skydda data databasadministratören… du.

det är rätt; hela verksamheten är i dina kapabla händer, körs på den servern som aldrig kraschar, med alla de slutanvändare som aldrig gör misstag med hjälp av applikationer, byggda av de utvecklare som skriver felfri kod första gången, varje gång, med hjälp av den nya co-op som har sa-privilegier tack vare din chef.

OK. Sluta gråta. Det finns saker du kan göra för att skydda SQL Server-data under din vård och en av de viktigaste är att köra vanliga databasbackups.

säkerhetskopior

Microsoft, i SQL Server Books Online, definierar säkerhetskopior som:

en kopia av data som används för att återställa och återställa data efter ett systemfel

SQL-säkerhetskopior kan skapas på ett antal sätt och kan innehålla alla eller en del av data, liksom en del av transaktionsloggen. Medan den här artikeln är inriktad på 2005-syntax, är de flesta begreppen tillämpliga på 2000. Detta är ett stort ämne. I bästa fall ska jag skrapa ytan och ge dig tillräckligt med information så att du inte börjar gråta igen. Efter att ha läst detta bör du kunna ställa in en rimlig uppsättning säkerhetskopior för ditt system.

Återställningsmodeller

för att börja arbeta med säkerhetskopior behöver verksamheten definiera en databasåterställningsmodell. I huvudsak definierar en återställningsmodell vad du ska göra med transaktionsloggdata.

det finns tre återställningsmodeller: Full, enkel och Bulk loggad. Dessa är ganska lätta att definiera:

• enkelt-i enkelt återställningsläge säkerhetskopieras inte transaktionsloggen så att du bara kan återställa till den senaste fullständiga eller differentiella säkerhetskopian.
• Full-i fullständigt återställningsläge säkerhetskopierar du databasen och transaktionsloggen så att du kan återställa databasen till vilken tidpunkt som helst.
• Bulkloggad-i bulkloggat läge lagras de flesta transaktioner i transaktionsloggen, men vissa bulkoperationer som bulklaster eller indexskapande loggas inte.

de två vanligaste lägena är enkla och fulla. Antag inte nödvändigtvis att du naturligtvis alltid behöver använda Full återställning för att skydda dina data. Det är ett affärsbeslut. Verksamheten kommer att berätta om du behöver återhämta sig till en tidpunkt eller om du helt enkelt behöver den sista fullständiga säkerhetskopian. Det kommer att definiera om dina data kan återställas på annat sätt, till exempel manuell inmatning, eller om du måste skydda så mycket som möjligt när det kommer över ledningen. Du använder enkel återställning om du har råd att förlora data som lagrats sedan den senaste fullständiga eller differentiella säkerhetskopian och/eller om du bara inte behöver återhämtning till en tidpunkt. I Enkelt läge måste du återställa alla sekundära läs – / skrivfilgrupper när du återställer det primära. Du använder Simple mestadels på sekundära databaser som inte är en absolut viktig del av företaget eller rapporteringssystemen, med skrivskyddad åtkomst så det finns ingen transaktionslogg att oroa sig för ändå. Du använder Full om varje bit av data är avgörande, måste du återställa till en tidpunkt eller, vanligtvis när det gäller mycket stora databaser (VLDB), måste du återställa enskilda filer och filgrupper oberoende av andra filer och filgrupper.

med både enkla och fullständiga återställningsmodeller kan du nu köra en kopieringsskyddad säkerhetskopia som låter dig kopiera databasen till en säkerhetskopia, men påverkar inte loggen, differentiella säkerhetskopieringsplaner eller effektåterställning till en tidpunkt. Jag ska försöka borra ner på så många av dessa ämnen som möjligt genom artikeln, men inte filerna och filgrupperna.

arbeta med enkel återställning

tillräckligt med prat. Låt oss komma ner till att köra säkerhetskopior. Låt oss anta att vi är i enkel återhämtning på en liten till medelstor databas. Jag kommer att använda AdventureWorks för alla exempelskript. För att ställa in den till enkel återställning:

din enklaste backup strategi är att köra, med jämna mellanrum, följande SQL Server backup kommando, som kommer att utföra en fullständig säkerhetskopia av databasen:

Vad är det med all typing du frågar? Har vi inte GUI-verktyg för att hantera arbetet för oss? Ja, de flesta enkla säkerhetskopior kan utföras med SQL Server Management Studio. Men om du vill lära dig och förstå vad Management Studio gör för dig, eller om du vill ha lite finkornig kontroll över vad som säkerhetskopieras, hur och var, måste du bryta ut tangentbordet och lägga bort musen.

ovanstående kommando kommer att fälla ut en grundläggande säkerhetskopiering till disk. De flesta DBA jag vet backup till fil och sedan skrapa filerna på ett band eller någon annan media. Detta beror på att filer på disken är enkla och snabba att återställa, medan media ibland kan vara lite smärta. Till exempel har vi i allmänhet två till tre dagars säkerhetskopior på våra filsystem för omedelbar återställning. Vi går bara till bandsystemen om vi behöver köra återställningar för äldre säkerhetskopior.

Vad gjorde det kommandot? Det gjorde en kopia av alla engagerade data i databasen. Det kopierade också obekräftade loggposter. Dessa används under återställning för att antingen begå eller återställa ändringar som inträffade i data under säkerhetskopieringsprocessen.

kopiera endast säkerhetskopior

normalt påverkar säkerhetskopiering av en databas andra säkerhetskopierings-och återställningsprocesser. Till exempel efter att ha kört det föregående kommandot, skulle eventuella differentiella säkerhetskopior (en säkerhetskopia som bara kopierar data som ändrats sedan den senaste säkerhetskopian) använda detta som utgångspunkt för dataändringar, inte säkerhetskopian du körde igår kväll. Som tidigare nämnts introducerar SQL 2005 ett nytt koncept för säkerhetskopior, COPY_ONLY-säkerhetskopior, vilket gör att vi kan hålla oss från att avbryta cykeln:

redan har vi hittat en av de mer granulära ögonblicken när Management Studio inte skulle hjälpa dig. Om du bara vill ha en säkerhetskopia måste du använda kommandoraden.

differentiella säkerhetskopior

låt oss anta ett ögonblick att vi fortfarande är i enkel återhämtning, men vi har att göra med en större databas, säg något över 100 GB i storlek. Fullständiga säkerhetskopior kan faktiskt börja sakta ner processen lite. Istället, efter samråd med verksamheten, har vi beslutat att göra en veckovis fullständig säkerhetskopiering och dagliga differentiella säkerhetskopior. Differentiella säkerhetskopior säkerhetskopierar bara de datasidor som har ändrats sedan den senaste fullständiga säkerhetskopieringen. Följande är SQL backup-kommandot för att utföra en differentiell säkerhetskopiering:

nu, om vi var tvungna att återställa den här databasen, skulle vi först gå till den sista fullständiga säkerhetskopian, återställa det och sedan återställa differentiella säkerhetskopior i ordning (mer om det senare).

det finns ett antal andra säkerhetskopieringsalternativ som jag inte kommer att beskriva här. Läs böckerna online för att se detaljer om BLOCKSIZE, EXPIREDATE, RETAINDAYS, lösenord, namn, statistik och så vidare.

du kan också köra ett uttalande som kommer att kontrollera integriteten för en databas backup. Det kontrollerar inte integriteten för data i en säkerhetskopia, men det verifierar att säkerhetskopian är formaterad korrekt och tillgänglig.

Full återställning och loggbackups

vi har främst arbetat med en databas som var i enkelt återställningsläge (detta brukade kallas Truncate Log on Checkpoint). I det här läget säkerhetskopierar vi inte transaktionsloggarna för senare återställning. Varje backup enligt denna mekanism är en databas backup. Loggbackups är helt enkelt inte möjliga.

du har dock bara skyddat data från den senaste bra säkerhetskopian, antingen full eller differentiell. Låt oss ändra våra antaganden. Nu har vi att göra med en stor, verksamhetskritisk applikation och databas. Vi vill kunna återställa den här databasen fram till den senaste minuten. Detta är en mycket viktig punkt. I teorin, eftersom loggposterna lagras och säkerhetskopieras, är vi skyddade fram till eventuella fel. Vissa fel kan dock orsaka korruption av loggen, vilket gör återhämtning till en tidpunkt omöjlig. Så vi måste bestämma vad den rimliga minimitiden mellan loggbackuper kommer att vara. I det här fallet kan vi leva med högst 15 minuters förlorade data.

så, låt oss börja med att sätta vår databas i FULL återställningsläge:

sedan, på schemalagd basis, i det här fallet var 15: e minut, kör vi SQL backup-kommandot för transaktionsloggen:

detta skript kommer att säkerhetskopiera engagerade transaktioner från transaktionsloggen. Den har markörer i filen som visar start-och stopptiden. Det kommer att trunkera loggen när den är klar, rensa ut från transaktionsloggen de engagerade transaktioner som har skrivits till säkerhetskopian. Om det behövs kan du använda uttalandet med NO_TRUNCATE för att fånga data från transaktionsloggen oavsett databasens tillstånd, förutsatt att den är online och inte i en NÖDSTATUS. Detta är endast för nödsituationer.

Observera att vi inte använder init-uttalandet i det här fallet, men du kan göra det om du väljer. När du gör loggbackups har du alternativ:

1. kör alla säkerhetskopior till en enda fil, där de staplar och allt du behöver göra, vid återställning (täckt senare), är att cykla genom dem.
2. namnge säkerhetskopiorna unikt, förmodligen med datum och tid i strängen.

i det senare fallet säger säkerhet, använd INIT eftersom du utövar maximal kontroll över vad som säkerhetskopieras var, och du kommer att kunna veta exakt vad en säkerhetskopia är, när den togs och varifrån baserat på namnet. Detta är ännu en plats där du använder säkerhetskopior från kommandoraden ger dig mer kontroll än GUI. Vi har använt båda metoderna i våra system av olika skäl. Du kan bestämma vad som är bäst för din teknik och affärskrav.

de flesta av de alternativ som är tillgängliga för databas backup ingår i Log backup, inklusive COPY_ONLY. Detta gör att du kan fånga en uppsättning transaktionsdata utan att påverka loggen eller nästa schemalagda loggbackup. Detta skulle vara praktiskt för att ta produktionsdata till ett annat system för felsökning etc.

om du har din databas inställd på FULL återställning måste du köra loggbackups. Ibland glömmer folk och transaktionsloggen växer till den punkt som den fyller upp hårddisken. I det här fallet kan du köra:

att bifoga NO_LOG till loggbackupen och inte ange en plats för loggen gör att den inaktiva delen av loggen tas bort och det gör det utan en loggpost själv och därmed besegrar hela hårddisken. Detta rekommenderas absolut inte eftersom det bryter loggkedjan, serien av loggbackups från vilken du skulle återställa din databas till en tidpunkt. Microsoft rekommenderar att du kör en fullständig säkerhetskopia omedelbart efter att du har använt detta uttalande. Vidare varnar de för att detta uttalande kan avvecklas i en framtida release.

återställa databaser

lika viktigt som SQL Server-säkerhetskopior är, och de är viktiga, de är värdelösa utan möjlighet att återställa databasen.

återställa en fullständig databas backup

återställa en fullständig databas backup är så enkelt som det var att skapa:

det är verkligen så enkelt-om inte, som vi vi säkerhetskopiera allt till en fil som om det vore en backup-enhet. I så fall måste du ange vilken fil i ”enheten” du har åtkomst till. Om du inte vet vilken fil måste du skapa en lista:

detta kommer att ge dig samma lista som jag visade ovan från Management Studio. Så nu, om vi ville återställa den andra filen i gruppen, COPY_ONLY backup, skulle du utfärda följande kommando:

tyvärr, om du följer med, kanske du upptäcker att du just genererade det här felet:

vad detta betyder är att din databas är i full återställningsläge, men du har inte säkerhetskopierat ”loggens svans”, vilket betyder att transaktionerna har angetts sedan förra gången du körde en säkerhetskopia. Du kan åsidosätta detta krav om du ändrar den tidigare syntaxen till:

det är första gången vi har staplat med klausuler (med FILE=2 och med REPLACE representeras som med FILE=2, REPLACE), men det blir inte det sista. Läs igenom böckerna online. De flesta med klausul uttalanden kan användas i kombination med de andra.

vad händer om vi vill återställa till en annan databas än originalet? Vi vill till exempel göra en kopia av vår databas från en separat säkerhetskopia. Kanske vill vi flytta ner den till en produktionssupportsserver där vi ska göra lite arbete med den, separat från produktionskopian av databasen. Om vi tar det enkla tillvägagångssättet, prova det här:

i det här fallet bör du se en hel serie fel relaterade till filer som inte skrivs över. Du kan verkligen skapa nya databaser från säkerhetskopior, men om du gör det på en server med den befintliga databasen måste du ändra platsen för de fysiska filerna med de logiska namnen. För att känna till de logiska namnen på filerna för en viss databas, kör detta innan du försöker flytta filerna:

detta kan sedan användas för att identifiera lämpliga logiska namn för att generera detta skript:

återställa en differential backup

den sista metoden är att tillämpa differential backup. Detta kräver två steg. Först återställer vi databasen, men med en vridning och sedan tillämpar vi differential backup:

det mesta av detta är förmodligen självförklarande baserat på vad vi redan har täckt. En rynka är införandet av NORECOVERY nyckelordet. Mycket enkelt, under en återställning kan transaktioner ha startat under säkerhetskopieringsprocessen. I slutet av en återställning rullas slutförda transaktioner framåt i databasen och ofullständiga transaktioner rullas tillbaka. Inställning NORECOVERY håller transaktioner Öppna. Detta gör det möjligt för nästa uppsättning transaktioner som ska plockas upp från nästa backup i ordning.

vi har huvudsakligen att göra med enkla säkerhetskopior och återställningar i den här artikeln, men en mer avancerad återställning 2005 gör att sekundära filgrupper kan återställas medan databasen är online. Den primära filgruppen måste vara online under operationen. Detta kommer att vara mer användbart för mycket stora databassystem.

återställa SQL Server-databaser till en tidpunkt

återställa loggar är inte mycket svårare än den differentiella databasåterställning som vi just har slutfört. Det är bara ganska lite mer involverat i att återställa till ett ögonblick i tiden. Förutsatt att du säkerhetskopierar dina loggar till en enda fil eller enhet:

annars går du helt enkelt och får de filnamn du behöver. Kör först databasåterställningen, var noga med att lämna den i ett icke-återställt tillstånd. Följ upp detta med en serie loggåterställningar till en tidpunkt.

nu har vi en databas som är upp till den exakta, senast engagerade transaktionen klockan 14:30:29 Den 23 oktober. Kom ihåg, under flera steg åter som detta, du måste lämna databasen i en återställa status. Det innebär att lägga till NORECOVERY till varje uttalande tills du har slutfört återställningsprocessen. Om du av någon anledning har lagt till NORECOVERY i alla dina uttalanden, eller om du helt enkelt slutar i mitten och vill ta tillbaka databasen online, kan du använda detta uttalande för att slutföra processen:

databas ögonblicksbilder

SQL Server 2005 introducerade begreppet en ögonblicksbild, eller en skrivskyddad, statisk vy av en databas. Ögonblicksbilder skapas främst för att tillhandahålla en skrivskyddad version av en databas för rapporteringsändamål. De fungerar dock på samma sätt som säkerhetskopior. Den främsta skillnaden är att alla obekräftade transaktioner rullas tillbaka. Det finns inget alternativ för att rulla framåt, fånga loggar etc., som säkerhetskopior ger, inte heller används mycket SQL Server-resurser alls. Snarare används Diskteknik för att skapa en kopia av data. På grund av detta är de mycket snabbare än säkerhetskopior både för att skapa och återställa.

OBS:
för mer information om SQL 2005 Snapshot, se http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

en bra användning av ögonblicksbilder, förutom rapportering, kan vara att skapa en före underhåll efter att du redan har tagit bort alla aktiva användare (och deras transaktioner) från systemet. Medan ögonblicksbilder inte stöder volatiliteten i live-säkerhetskopior, är deras hastighet och enkel återhämtning ett bra verktyg för snabb återhämtning från en botched rollout. Snapshots lagras på servern, så du måste se till att du har tillräcklig Lagring.

syntaxen är annorlunda eftersom du inte säkerhetskopierar en databas; du skapar en ny:

nu kommer det att vara tillgängligt för skrivskyddad åtkomst. Eftersom vi främst är intresserade av att använda detta som en säkerhetskopieringsmekanism, låt oss inkludera metoden för att återställa en databas till en databasbild.

identifiera först den ögonblicksbild du vill använda. Om det finns mer än en i någon databas som du ska återställa måste du ta bort alla utom den du använder:

då kan du återställa databasen genom att köra ett ÅTERSTÄLLNINGSUTTALANDE (blandade metaforer, inte bra):

det är det. På mitt system körde databasens ögonblicksbilder av Adventureworks 136 ms. den fullständiga säkerhetskopian tog 5,670 ms.återställningen av ögonblicksbilden tog 905ms och databasåterställningen tog 13,382 ms. Att integrera detta i en produktionsutrullningsprocess kan leda till betydande fördelar

återigen är det värt att notera att det finns några försiktighetsåtgärder för att använda ögonblicksbilden. Du måste ha tillräckligt med diskutrymme för en andra kopia av databasen. Du måste vara försiktig med ögonblicksbilder eftersom det mesta av syntaxen liknar den som används av databaserna själva. Sist, medan det finns ögonblicksbilder kopplade till en databas kan du inte köra en återställning från en databas backup av databasen.

bästa praxis

det sätt på vilket du utför säkerhetskopior av databaser bör inte vara ett tekniskt beslut. Det bör dikteras av verksamheten. Små system med låga transaktionshastigheter och/eller rapporteringssystem som laddas regelbundet behöver bara en fullständig databasbackup. Medelstora system och stora system blir beroende av vilken typ av data som lyckats bestämma vilka typer av säkerhetskopiering som krävs.

för ett medelstort system skulle en daglig säkerhetskopiering med loggbackups under dagen förmodligen svara på de flesta datakrav i tid.

för en stor databas är det bästa sättet att mixa och matcha säkerhetskopiorna för att säkerställa maximal återhämtningsbarhet på kortast möjliga tid. Kör till exempel en fullständig säkerhetskopia varje vecka. Två gånger om dagen under veckan, kör en differentiell säkerhetskopiering. Var 10: e minut under dagen, kör en loggbackup. Detta ger dig ett stort antal återhämtningsmekanismer.

för mycket stora databaser måste du komma in i att köra filgrupp och Filbackup eftersom det inte är möjligt att göra en fullständig säkerhetskopiering eller till och med en differentiell säkerhetskopiering av hela databasen. Ett antal ytterligare funktioner finns tillgängliga för att hjälpa till på detta område, men jag kommer inte att gå in på dem här.

du bör ta dig tid att utveckla några skript för att köra dina säkerhetskopior och åter. En namnkonvention så att du vet vilken databas, från vilken server, från vilket datum, i vilken specifik säkerhetskopiering och format kommer att vara mycket gynnsamt för ditt förstånd. En gemensam plats för säkerhetskopiering, logg, full eller inkrementell bör definieras. Alla ansvariga bör utbildas i både säkerhetskopiering och återställning och felsökning samma. Det finns många sätt att göra detta, men du kan hitta några förslag I Pop backs up och Pop återställer.

det verkliga testet är att köra dina säkerhetskopieringsmekanismer och sedan köra en återställning. Försök sedan en annan typ av återställning, och en annan, och en annan. Var säker på att du inte bara har gjort due diligence för att definiera hur du säkerhetskopierar systemet, men att du har gjort det extra steget för att se till att du kan återställa dessa säkerhetskopior. Om du inte har övat detta och dokumenterat övningen och sedan testat dokumentet, är du i själva verket inte redo för en katastrof.

sammanfattning

säkerhetskopior inom ditt företag ska vara som att rösta i Chicago, tidigt och ofta. Att ställa in grundläggande säkerhetskopior är ganska enkelt. Att lägga till loggbackups och skillnader är också enkelt. Utforska alternativen för att se hur du lägger till i fil-och filgruppsbackuper och återställer för att öka hastigheten på dina säkerhetskopior och återställer båda som ökar systemets tillgänglighet och upptid. Håll en gemensam namnstandard. Var försiktig när du använder ögonblicksbilder, men använd dem säkert. Lagra dina filer på en standardplats mellan servrar. Öva dina återhämtningar. Slutligen, för att verkligen få dina säkerhetskopior att sjunga, ladda ner en gratis testversion av Red Gates SQL-Backupjätte. Det erbjuder högpresterande komprimering och nätverksbeständighet för att göra processen att skriva eller kopiera säkerhetskopior över flagnande nätverk feltoleranta.