KAP 16 BACKUP, RESTORE OCH RECOVERY

(1)

Sven Åke Johansson Institutionen för Kommunikation o design

Tommy Löfqvist Lnu/DFM

KAP 16 BACKUP, RESTOREOCH RECOVERY

 Backup - strategier

 Backuptyper

 Recoverymodeller

 Backup med Management Studio

 Backup med TSQL

 Hur transaktionsloggen fungerar

 Automatiskt återhämtning (Recovery)

 Återhämta databaser - Recover

 Återställning (restore) av databas med Mstudio

 Återställning (restore) av databas med TSQL

1

BACKUP

2

Med en backup kan du återställa databasen från

 Fel på media

 Fel på system-mjukvara

 Oavsiktlig felaktig användning av delete och update

‒ DELETE Customers

‒ DROP DATABASE SalesProduction

‒ Format C:

‒ UPDATE Employees SET Salary=200000

 Elaka virus

 Naturkatastrofer

 Klantiga tekniker

 Eldsvådor

 Stöld

En databas representerar för de flesta en mycket värdefull investering Det gäller att förvalta den väl med genomtänkta säkerhetskopieringar

(2)

BACKUPSTRATEGI

3

Var alltid beredd på det värsta!

Ditt jobb är att förbereda för katastrofer och hoppas att du aldrig behöver använda dina förberedelser. Det finns inget som heter paranoid när det gäller backuper! Data som förlorats är borta för evigt!

Det finns två sorters diskar

‒ sådana som har gått sönder

‒ sådana som ännu inte gjort det

Utveckla en backupstrategi

Backupstrategin bestämmer punkten fram till vilken databasen kan återställas efter en katastrof.

Den strategi som ska väljas bestäms av hur viktiga dina data är.

Det räcker normalt inte att kunna återställa backupen från i söndags! Man måste kunna återställa till tidpunkten för krashen! Det är här transaktions-loggen kommer till räddning, den innehåller information om vilka kommandon som har förändrat databasen.

I händelse av en krasch är det möjligt att köra kommandon igen (ROLLFORWARD) för att återhämta (recover) databasen från den senaste backupen fram till godtycklig tidpunkt.

För att detta ska fungera måste man emellertid se till att databasen är inställd på rätt

”Recovery model”. Se längre fram!

BACKUPSTRATEGI

4

Hur ofta och vilka typer av backupmedia som behövs beror på hur ofta och hur mycket databasen förändras med tiden.

Det är vanligt att säkerhetskopiera (ta backup på) hela databasen 2 gånger per vecka och däremellan ta backup på transaktionsloggen och göra differentiella backuper flera gånger per dag.

Man bör också använda sig av åtminstone tre generationer av backupmedia (t ex band) som man växlar mellan.

Små databaser kan man med fördel alltid ta full backup på då de inte tar så stor plats och att det går snabbt, men glöm inte transaktionsloggen, den är viktig.

Även systemdatabaserna ska säkerhetskopieras när något förändrats i systemet, t ex då man lagt till nya login, databaser och programmerade uppgifter.

För att ta en säkerhetskopia (backup) behöver man inte ”kasta ut” användarna utan all backuptagning kan göras ”online”. Detta beror på att alla kommandon som påverkar databasen också sparas i transaktionsloggen.

(3)

BACKUPTYPER

5

Flera backuptyper

Full - Fullständig kopia tas av databasen

Differential - Kopia tas på ändrade sidor sedan förra backupen Transaction log - Kopierar endast transaktionsloggen

File eller group - Kopierar endast angiven fil eller filgrupp File differential - Alla ändrade sidor i filen sedan förra filbackupen

Begrepp

Backup - säkerhetskopiering

Restore - återställning av säkerhetskopia Recover- återhämtning från krasch

ÅTERHÄMTNINGS (RECOVERY) MODELLER

6 Recovery model kan väljas på Properties - Options sidan till databasen

Lämplig för små databaser med få uppdateringar, test-databaser samt även till master och msdb då dessa inte använder transaktioner.

Full Recovery Model

Säkraste recovery-modellen

Kan återhämta (recover) från kraschade filer till godtycklig tidpunkt om inte transaktionsloggen är skadad.

Transaktionsloggarna kan bli enormt stora

BULK_LOGGED Recovery Model

Tillåter mycket snabba bulk-operationer - Bulk Copy, BULK INSERT, SELECT INTO, WRITETEXT, UPDATE TEXT, CREATE INDEX

Tar minimalt logg-utrymme då det endast loggas att en bulkoperation ägde rum.

Kan återhämta (recover) kraschade filer till sista logg-backupen

Simple Recovery Model

Endast full databas och differentiell backup

Loggfilen blir minimal

Kan endast återhämta (recover) kraschade filer till senaste backup.

Servercrasch hanteras automatiskt av alla modellerna genom en ROLLFORWARD av comittade transaktioner (finns lagrade i transaktionsloggen)

(4)

SÄKERHETSKOPIERAMEDMANAGEMENTSTUDIO #1

7

Välj backuptyp

• Full

• Differentiell

• Logg Välj

• databas

• fil

• filgrupp Sökväg till backup

• Fil

• Device

OBS! Endast lokala diskar är åtkomliga via interfacet. Om du ska spara backup'en på en nätverksdisk anges UNC - sökväg eller så skapar du en Backup Device som är ett alias till sökvägen. SQL Server måste ges skriv och läsrättighet där.

Generalsidan

SÄKERHETSKOPIERAMEDMANAGEMENTSTUDIO #2

8

Komprimering av backupen gör den snabbare och mindre!

Endast Enterprise- och Developer-versionerna har komprimering. Återställning kan göras av alla versioner fr.o.m. 2008

Optionssidan

• Addera till befintlig

• Skriv över

Kolla media & datum

Verifiera backup

Komprimera backup?

• Default inställning

• Komprimera

• Komprimera inte

(5)

ATTSÄKERHETSKOPIERAENDATABASMEDTSQL

9

Säkerhetskopiering av hel databas med TSQL BACKUP DATABASE NorthWind

TO DISK = 'D:\backup\Nwbackup.bak' [WITH COMPRESSION]

Differentiell backup med TSQL BACKUP DATABASE NorthWind TO DISK = 'D:\backup\Nwbackup.bak' WITH DIFFERENTIAL [, COMPRESSION]

Säkerhetskopiering av Transaktionsloggen med TSQL

BACKUP LOG Northwind

TO DISK = 'D:\backup\Nwbackup.bak' [WITH COMPRESSION]

En liten test av filstorlek för backup med och utan komprimering gav resultatet: 1062/3673 KB

HUR TRANSAKTIONSLOGGEN FUNGERAR

10

INACTIVE ENTRIES sparade

Äldsta uncommited

transaction Checkpoints Loggslut

Loggstart

ACTIVE Entries EJ sparade LSN

141 begin Tran1

LSN 142 begin Tran2

LSN 143 update Tran2

LSN 144 Check Point

LSN 145 update Tran1

LSN 146 Commit Tran1

LSN 148 Update Tran2 LSN 147 Check Point

1. Till vänster påbörjas Tran1 (141), därefter påbörjas Tran2 (142) som fortsätter i (143).

2. Därefter kommer en CHECKPOINT (144). Vid en checkpoint sparas bland annat commit'ade transaktioner till disk. Det finns inga sådana transaktioner ännu.

3. Tran 1 fortsätter (145) och avslutas med commit i (146).

4. Vid kommande CHECKPOINT (147) sparas nu transaktionen som började i (141).

5. Allt till vänster om äldsta uncommited transaktion 142 ligger nu på disk och är nu INACTIVE Entries.

6. Transaktionen som började med (142) fortsätter nu att köras i (148) och ligger fortfarande i de ACTIVE Entries som inte sparats på disk.

I transaktionsloggen sparas information om utförda kommandon.

LSN = Log Sequence Number

(6)

TRANSAKTIONSLOGGEN

11

De flesta DBMS använder Write - Ahead log vilket innebär att modifikationer skrivs till loggen innan de skrivs till databasen. Detta garanterar återskapande av högsta klass.

En CHECKPOINT

• Inträffar c:a en gång per minut, beroende på belastning

• "Commit'ade" datasidor skrivs till databasen

• Aktiva transaktioner bokförs i loggen

• Inaktiva loggposter raderas vid simple recovery model.

• Vid andra recoverymodeller tas inaktiva loggposter bort från loggen vid nästa backup av loggen. Vid datakrasch ska detta väljas bort. Istället ska man ta backup på Tail of the log så att kommandon efter förra backup'en kan köras igen.

Radera inactive Entries med MStudio OBS! Om man inte tar backup på loggen

blir den så stor att den till slut inte går att göra några operationer på databasen

Tail of the log

INACTIVE ENTRIES sparade (ej backup) ACTIVE Entries EJ sparade

LSN 141 begin Tran1

LSN 142be gin Tran2

LSN 143 update Tran2

LSN 144 Check Point

LSN 145 update Tran1

LSN 146 Commit

Tran1 LSN 148 Update

Tran2 LSN 147 Check Point

Förra backupen

AUTOMATISKT ÅTERHÄMTNING (RECOVERY)

12

Transaktionsloggen innehåller också information till "Automatic Recovery" efter Server-krasch, t ex strömavbrott. Det kan då hända att commit'ade transaktioner inte hunnit sparas på disk och man kan ana att det finns risk att dessa

commit'ade transaktioner blir förlorade. Så är dock inte fallet, kraven enligt ACID

1)(Durability) säkerställer att dessa transaktioner även kommer att slutföras på ett säkert sätt.

När datorn återstartas efter ev. reparation sker automatiskt "roll forward" på commit'ade men ej sparade transaktioner, dvs de körs en gång till.

Transaktioner som ej var slutförda (uncommited transactions) vid serverkraschen görs rollback på och felmeddelande visas så att de kan utföras på nytt. Denna automatiska återhämtning (recovery) gäller alla recovery modellerna.

1) ACID Sammanfattar de fyra krav som ska ställas på en transaktion (atomicity, consistency, isolation och durability). Se hjälp eller googla!

Alla databaser har en transaktionslogg, operationer som påverkar databas och data spelas in i denna logg och används till att återskapa efter mediafel eller förstörd databas för Full och Bulk logged recovery model

(7)

ÅTERHÄMTADATABASER - RECOVER

13

Ser misstänkt tomt ut

Fysiska fel på en enhet märks vanligen direkt!

- Disken för oväsen eller står still - Databasen "försvinner" i MStudio

Andra fel visas i

- SQL Server Error Log (Current + 6 äldre) - Windows NT Application log

Hur vet man att det uppstått problem?

ÅTERHÄMTNINGS (RECOVERY) SCENARIER #1

14

Vad som ska göras efter en krasch beror på vad som är skadat och vilken recovery model som används

A. Om servern gått ner

Om du fått strömavbrott, hårdvarufel som inte förstört datafiler, mm, så är det bara att starta om servern efter eventuell reparation.

”Automatic Recovery” kör igång vid återstart och återställer ”committed transactions” som inte hunnit ner på disk. (Roll forward). Rollback görs automatiskt på ”uncommitted transactions” som får göras om.

B. Datakrasch vid "Simple Recovery Model"

Skadad transaktionslogg

Om endast transaktionsloggen är skadad är det bara att starta om servern så skapas automatiskt en ny transaktionslogg på 1MB. Expandera denna om du behöver mer utrymme.

Skadad databas

Återstarta servern och återställ (Restore) den fulla backupen och differentiella backuper. Data ändrad efter sista backupen är förlorad

(8)

ÅTERHÄMTNINGS (RECOVERY) SCENARIER #2

15

C. Full eller Bulk logged Recovery Model

Både databasfil och transaktionslogg skadad

Återställ (Restore) senaste fulla backupen, differentiella backuper,

transaktionsloggar. Ändringar sedan den sista transaktionsloggs-backupen kommer att förloras.

Endast skadad databas

1. Ta backup på aktuell transaktionslogg (innehåller transaktioner sedan senaste backup) med inaktiva poster kvar (NO_TRUNCATE)

2. Återställ: senaste fulla backupen differentiella backuper transaktionsloggar (även loggen i 1.)

3. Databasen kommer att blir återställd till tidpunkten för felet.

Tail of the log INACTIVE ENTRIES ACTIVE Entries ej sparade

LS N LS N LSN 143 LSN 144 LSN 145 LSN 146

LSN 148 LSN

backup 147

RESTORE / RECOVER

16

Vad är det för skillnad mellan Restore och Recover?

Restore (Återställning)

• säkerhetskopia (backup) återställes till databasen från backupmedium

• flytta/kopiera återställa skadade filer

• data ändrad efter senaste säkerhetskopieringen kommer att förloras Recovery (Återhämtning)

• återställer databas efter krasch till tidpunkt för krasch

• använder databasens loggar genom roll forward

• kräver tidigare full backup

(9)

ÅTERHÄMTNING (RECOVERY) MED "SIMPLE MODEL"

17

Till vilken punkt kan vi återhämta databasen om databasen kraschar kl 15.00 på Onsdag? ______

DB Må 22.00

Full kopia

DB On 22.00

Full kopia

DB Fr 22.00

Full kopia

?

ÅTERHÄMTNING (RECOVERY) MED "FULLMODEL"

Söndag Måndag Tisdag Onsdag 10.00

14.00 18.00 24.00 DB

Full

Log Log Log

DB Diff

Log Log Log

DB Diff

Log Log Log

DB Full Antag att databasen krashar

Onsdag kl 17.00.

Till vilken punkt kan man återhämta (recover)? ______

?

Vad gäller om transaktionsloggen också är skadad?

________

?

Må 22

On 17

On 14

ÅTERSTÄLLNING (RESTORE) AVDATABASMEDMSTUDIO…

18

Databasnamn

Restore med info från msdb Restore från angiven fil

Markera backup som ska återställas Börja med senaste fulla Högerklicka, välj Tasks -> Restore - General sidan

(10)

ÅTERSTÄLLNING (RESTORE) AVDATABASMEDMSTUDIO…

19

Högerklicka, välj Tasks -> Restore - General sidan

Nya namn och sökvägar kan anges till data och logg

Lämna databasen i operationellt skick

ÅTERSTÄLLNING (RESTORE) AVDATABASMEDTSQL

20

RESTORE DATABASE mydb FROM DISK='c:\backup\mydb.bak' WITH PASSWORD

= 'hemlig', FILE=1, NORECOVERY

RESTORE DATABASE mydb FROM DISK='c:\backup\mydb.bak' WITH PASSWORD

= 'hemlig', FILE=7

FILE är numret på backupen. Kan utforskas med RESTORE HEADERONLY FROM

Använd NORECOVERY på alla utom den sista "restoren"

Återställning med TSQL är betydligt svårare då man måste ta reda på numret på ingående filer i backupen.

Återställ en full databas backup (fil nr 1) och den senaste differentiella backupen (fil nr 7)

Se books online för detaljer!

(11)

LOGG-MARKERINGAR

21

Applikationer kan sätta markeringar i transaktionsloggen för att markera när en viss transaktion börjar:

Det är sedan möjligt att återställa till eller till och med en sådan markering i loggen. Den sista återställningen av loggen kan då se ut så här:

RESTORE DATABASE mydb FROM DISK='c:\backup\mydb.bak' WITH FILE=3, STOP AT 'abc tran'

BEGIN TRANSACTION abc WITH MARK 'abc tran'

Man kan också återställa till viss tidpunkt::

RESTORE DATABASE mydb FROM DISK='c:\backup\mydb.bak' WITH FILE=3, STOP AT 'Apr 15, 2005 12:00 AM'

ÅTERSTÄLLAMASTER-DATABASEN

22

Om masterdatabasen blivit skadad går det inte att starta SQL Server. Det som då måste göras är att installera en ny masterdatabas från installationsdisken.

Därefter kan SQL Server startas på nytt.

Det kommer dock inte finnas några databaser och login-konton registrerade.

Alla programmerade jobb har också försvunnit.

För att få tillbaka allt detta återställer man backupen till master och msdb- databaserna.

Allt detta beskrivs i hjälpen och har man bara en aktuell backup på master och msdb databaserna går det att återställa servern i ursprungligt läge.