1 7. april 2005 TDT4285 Planl&drift IT-Syst Forelesning nr 27 Backup TDT4285 Planlegging og drift av IT-systemer Våren 2005 Anders Christensen, IDI.

Presentasjon om: "1 7. april 2005 TDT4285 Planl&drift IT-Syst Forelesning nr 27 Backup TDT4285 Planlegging og drift av IT-systemer Våren 2005 Anders Christensen, IDI."— Utskrift av presentasjonen:

1 1 7. april 2005 TDT4285 Planl&drift IT-Syst Forelesning nr 27 Backup TDT4285 Planlegging og drift av IT-systemer Våren 2005 Anders Christensen, IDI

2 2 7. april 2005 TDT4285 Planl&drift IT-Syst Definisjon Backup er å benytte redundant lagring av informasjon for å unngå at denne forsvinner ved en feiltagelse, et krasj el.l. (dvs for å nøytralisere single point of failure).

3 3 7. april 2005 TDT4285 Planl&drift IT-Syst Dimensjoner for backup Omfang – alle eller bare viktige data? Nivå – alle eller kun endrede data? Grader –filinnhold eller også metadata? Redundans – antall kopier av hver fil Granularitet – hvor ofte tas backup Versjonering – antall versjoner bakover Endringsrate - % endringer i fildataene

4 4 7. april 2005 TDT4285 Planl&drift IT-Syst Nivåer av backup Stor fil Grov fil Kjørefil Filleting Nyfil Grov fil Kjørefil Filleting Stor fil Grov fil Filleting Stor fil Grov fil Kjørefil Filleting Full backup Tid Stor fil Inkr. backup Nyfil Inkr. backup Filleting Basert på Tid Nivå 0 Nivå 1 Nivå 2

5 5 7. april 2005 TDT4285 Planl&drift IT-Syst Full og inkrementell backup Full backup: kopi av alle data Inkrementell backup nivå 1: kopi av alle nye/endrede data etter forrige fulle backup. Inkrementell backup nivå 2: kopi av alle nye/endrede data etter forrige backup på nivå 1.

6 6 7. april 2005 TDT4285 Planl&drift IT-Syst Tre grader av backup Filinnhold Index 1. Speilkopi 2. Alle data 3. Fildata Innhold, metadata og ”implementasjon” Innhold og metadata Kun filinnhold

7 7 7. april 2005 TDT4285 Planl&drift IT-Syst Metadata som kanskje kopieres Access control lists (ACL) Eierskap og gruppetilhørighet Alle tidsstempler relatert til fila (typisk minst 3-4 for de fleste OS) Informasjon om ”hull” i filer Device-filer, spesialfiler og lenker Filattributter (R/O, skjulte, systemfiler...)

8 8 7. april 2005 TDT4285 Planl&drift IT-Syst Backupmetoder Harddisk Tapestasjon 1 tape pr dag Oppdatering Backup- database Alle data lagres 1 gang i en database Inkrementell Full Versjonering Alle versjoner av hver fil lagres Tape backup Bruker Bruker er selv ansvarlig for å ta sin egen backup

9 9 7. april 2005 TDT4285 Planl&drift IT-Syst Redundans og granularitet Anta schedule: Full hver mnd Inkr nivå 1 hver uke Inkr nivå 2 hver dag Taperotasjon 6mnd Worst case: en fil med en levetid på 1mnd finnes bare på en tape.  For hver tape som blir defekt, hvor mange filer ”mistes” permanent?  Sannsynlighet for restore gitt en fils levetid og et antall defekte taper?

10 10 7. april 2005 TDT4285 Planl&drift IT-Syst Må hele fila tas backup av? Ford Opel Mercedes Volvo Citroen Rolls Royce Lada Databasefil Mazda Juli Juni Mai April Mars Februar Januar August Append-only loggfil Backup av hele fila Backup kun av endret post Backup av hele fila Backup kun av tillagt post Update Append

11 11 7. april 2005 TDT4285 Planl&drift IT-Syst Backup - proaktivt eller reaktivt? Original harddisk Tape Tidsakse Restoret harddisk Krasj Backup Restore Proaktiv faseReaktiv fase Rutine Tidsnød

12 12 7. april 2005 TDT4285 Planl&drift IT-Syst Lokasjon for lagring av tape 12 543 Samme bygning Samme rom TaperobotBrannsafe Leirras Nabobygg Nedbrenning Utbrenning Branntilløp Innbrudd

13 13 7. april 2005 TDT4285 Planl&drift IT-Syst Arkivbackup 1.Ta et eget backupsett, som er separat fra daglig backup 2.Plukk ut et sett taper fra daglig backup som utgjør et enkelt komplett sett 3.Dobbeltlagre full backup av hvert disk til en egen arkiv-tapestasjon, og lagre som arkivbackup når den er komplett

14 14 7. april 2005 TDT4285 Planl&drift IT-Syst Tidsaspekter ved backup Tar backup oftere enn restoring, så det er viktig å automatisere backup Ofte tidsnød ved restore (reaktivt)

15 15 7. april 2005 TDT4285 Planl&drift IT-Syst Noen måltall Tid for nattlig backupkjøring Antall dager for en full backupsyklus Tid for å restore en enkelt, liten fil Tid for å restore største disk/RAID Overføringsrate ved restore Komprimeringsgrad for dataene

16 16 7. april 2005 TDT4285 Planl&drift IT-Syst Backup-schedule ved IDI Full backup hver 10. dag Inkrementell backup hver dag Full/inkr tas vare på i 60 dager Arkivbackup 3-4 ggr pr år. Partisjoner Dager Full Inkrementell

17 17 7. april 2005 TDT4285 Planl&drift IT-Syst Noen ops!-faktorer Ingen har testet hvor lang tid en full restore tar Lisensen på backupprogramvaren har gått ut og ingen kan restore data Ingen hadde sjekket loggene, og alle tapene fra siste 5 mnd var tomme Disksystemene gror raskere enn økningen på tapesystemenes kapasitet klarer å ta unna

18 18 7. april 2005 TDT4285 Planl&drift IT-Syst Case: Situasjonsbeskrivelse Brevjournalen var korrupt Kjører på SQL-server Backup fra de to siste dagene korrupt Lignende har skjedd to ganger tidligere Måtte rekonstruere for to dager Journalen skulle vært faset ut Mange feil i liten del av systemet

19 19 7. april 2005 TDT4285 Planl&drift IT-Syst Opprinnelig system DatabaseBrukerBackup1 Backup2 Alarm!

20 20 7. april 2005 TDT4285 Planl&drift IT-Syst Problemfaktorer 1 Backupen er drevet rent reaktivt – det vil si at man korrigerer og justerter etter feil; men man er uten kvalitetskontroll før situasjonen har nådd en kritisk grense. Ingen brannøvelser. Implementering og igangsetting av databasen skjedde ad hoc uten hensyn til innspill fra drift, innen områder som teknologivalg og driftskostnader. Databasen var ’gratis’.

21 21 7. april 2005 TDT4285 Planl&drift IT-Syst Problemfaktorer 2 Databasen måtte kjøre på et mer eller mindre selvstendig, isolert system – dels for å isolere dens egen ustabilitet, og dels fordi den forutsatte andre enn standard teknologivalg. Kvaliteten på backup av databasen fikk lov til å bli redusert uten at det ble oppdaget og korrigert (hvis bare databasen selv fungerte). Man sjekket ikke kvaliteten før man trengte dataene fra backup.

22 22 7. april 2005 TDT4285 Planl&drift IT-Syst Problemfaktorer 3 Ingen merket feilmeldingene fra den nattlige backupkjøringen i vrimmelen av andre daglige meldinger.

23 23 7. april 2005 TDT4285 Planl&drift IT-Syst Mulig løsning 1 Introduser avhengighet! La databasen være avhengig av backup, slik at defekter i backup umiddelbart blir synlige. DatabaseBrukerBackup Trinn 1 kopiering Trinn 2 bytte

24 24 7. april 2005 TDT4285 Planl&drift IT-Syst Løsning 1a - momenter 1.Tvinger evt backup til å være konsistent (ellers vil brukerne klage) 2.Men: detekterer ikke hvorvidt backup faktisk er tatt

25 25 7. april 2005 TDT4285 Planl&drift IT-Syst Mulig løsning 1b DatabaseBrukerBackup Trinn 1 kopiering Trinn 2 bytte Alarm1 Alarm2

26 26 7. april 2005 TDT4285 Planl&drift IT-Syst Løsning 1b – momenter 1.Som løsning 1a, samt... 2.En alarm detekterer om backup ikke tas – og varsler brukerne 3.For å sikre seg mot at alarmen slutter å virke, kan man legge til enda en alarm som sjekker den første. 4.Men: kan ikke sikre seg at ikke alle alarmene slutter å virke på en gang

27 27 7. april 2005 TDT4285 Planl&drift IT-Syst Løsning 1c – diagram DatabaseBrukerBackup Trinn 1 kopiering Trinn 2: bytte Alarm1Alarm2

28 28 7. april 2005 TDT4285 Planl&drift IT-Syst Løsning 1c – momenter 1.Som løsning 1b, samt... 2.Alarmene er uavhengige av hverandre (helst på to ulike OS) 3.Alarmene er symmetriske (dvs at de vokter på hverandre) 4.Alarmene går til noen som vil reagere, dvs brukerne