1 / 28

Forelesning nr 27 Backup

Forelesning nr 27 Backup. TDT4285 Planlegging og drift av IT-systemer Våren 2005 Anders Christensen, IDI. Definisjon.

hayley
Download Presentation

Forelesning nr 27 Backup

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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). TDT4285 Planl&drift IT-Syst

  3. 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 TDT4285 Planl&drift IT-Syst

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

  5. 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. TDT4285 Planl&drift IT-Syst

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

  7. 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...) TDT4285 Planl&drift IT-Syst

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

  9. 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? Redundans og granularitet TDT4285 Planl&drift IT-Syst

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

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

  12. Lokasjon for lagring av tape Innbrudd Branntilløp Utbrenning Nedbrenning Leirras Samme bygning Nabobygg Samme rom 1 2 3 4 5 Taperobot Brannsafe TDT4285 Planl&drift IT-Syst

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

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

  15. 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 TDT4285 Planl&drift IT-Syst

  16. 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. Inkrementell Dager Full Partisjoner TDT4285 Planl&drift IT-Syst

  17. 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 TDT4285 Planl&drift IT-Syst

  18. 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 TDT4285 Planl&drift IT-Syst

  19. Opprinnelig system Bruker Database Backup1 Backup2 Alarm! TDT4285 Planl&drift IT-Syst

  20. 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’. TDT4285 Planl&drift IT-Syst

  21. 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. TDT4285 Planl&drift IT-Syst

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

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

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

  25. Mulig løsning 1b Trinn 2 bytte Bruker Database Backup Trinn 1 kopiering Alarm2 Alarm1 TDT4285 Planl&drift IT-Syst

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

  27. Løsning 1c – diagram Trinn 2: bytte Bruker Database Backup Trinn 1 kopiering Alarm2 Alarm1 TDT4285 Planl&drift IT-Syst

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

More Related