# Datalagring ## Hva det er Datalagring, til daglig ofte bare kalt lagring, er det laget i et system der data blir liggende mellom hver gang de brukes, på medier som tar vare på dem gjennom en omstart og et strømbrudd. NIST-ordlisten gir ordet to betydninger, begge hentet fra SP 800-88r2: at data oppbevares slik at de kan hentes fram igjen, og maskinvaren som data kan skrives inn på og leses ut fra. Hver form for lagring hviler på et fysisk medium: en harddisk med roterende plater, en SSD, et SD-kort, et bånd. Programvaren ser ett av tre lag over det: - **Blokklagring** viser en enhet som en rekke blokker av fast størrelse, adressert med nummer. En diskpartisjon, et RAID-oppsett og en virtuell disk i skyen ser alle slik ut for systemkjernen, og et filsystem eller en databasemotor avgjør hva blokkene betyr. - **Fillagring** legger et filsystem over de blokkene: navn, mapper, størrelser, eiere og rettigheter, og en fil kan endres noen få byte om gangen. Delt over NFS eller SMB kan ett tre betjene mange maskiner. - **Objektlagring** holder hele objekter, hvert av dem en rekke byte med metadata, under et navn i en beholder, og nås gjennom et HTTP-API i stedet for å monteres. Google Cloud Storage lagrer data som objekter i beholdere som kalles bøtter (buckets), hver bøtte hører til et prosjekt, og et objekt er en uforanderlig bit data som består av en fil i et hvilket som helst format. De tre går hver sin vei når det gjelder hva en endring koster. En blokkenhet skriver om én blokk der den står. Et filsystem endrer en del av en fil og flytter den med et navnebytte. Et objektlager erstatter hele objektet: Googles side om objekter utelukker både å legge til på slutten og å kutte et objekt kortere, og en erstatning er atomisk, så lesere får den gamle versjonen helt til den nye opplastingen er ferdig. Et navnebytte blir en kopi under det nye navnet og en sletting av originalen. I en bøtte med flatt navnerom er mapper et bilde verktøyene tegner ut fra skråstrekene i objektnavnene. Strengen `folder1/` er en del av navnet, og bøtta lagrer ingen mappe i det hele tatt. Den samme filen ser slik ut på hvert av lagene: ```sh # block: the kernel's view of a disk as numbered blocks lsblk /dev/sda # file: a filesystem mounted over those blocks, with names and directories df -h /srv # object: a whole object sent to a bucket over an API gcloud storage cp readings.csv.gz gs://example-bucket/2024/01/ ``` ## Hvorfor det er viktig Mediet avgjør hvordan data går tapt. En harddisk, en SSD og et SD-kort svikter hver på sin måte, og en gjenopprettingsmetode som passer for det ene, er feil verktøy for det neste. Redundans inne i én boks, som et speilet diskpar eller et RAID-oppsett, holder data lesbare etter at én disk dør, men den skriver hver sletting til hver disk like trofast som den skriver dataene. Holdbarhet og tilgjengelighet er to forskjellige løfter. Holdbarhet er sjansen for at lagrede data overlever, og tilgjengelighet er sjansen for at de kan leses i et gitt øyeblikk. Cloud Storage oppgir en årlig holdbarhet på 99,999999999 % for hver lagringsklasse, mens den typiske månedlige tilgjengeligheten tjenesten gir, går fra 99,9 % til over 99,99 %, avhengig av klasse og plassering. En lagringsklasse er metadata på hvert objekt som bestemmer tilgjengeligheten og prismodellen, og nye objekter arver standardklassen til bøtta si. De kaldere klassene gir en lavere pris for å oppbevare data og tar betalt på andre måter: litt lavere tilgjengelighet, en minste lagringstid på 30, 90 eller 365 dager og en avgift for å lese dataene tilbake. Google retter dem mot data som leses én gang i måneden eller sjeldnere, høyst én gang i kvartalet og sjeldnere enn én gang i året. Plassering er en del av dataene. En kopi på den samme disken, den samme maskinen eller i den samme skykontoen deler skjebne med den disken, maskinen eller kontoen, og en kopi et annet sted gjør det ikke. Plasseringen styrer også fart og kostnad: Google påpeker at data som ligger i samme region som datakraften som bruker dem, gir best ytelse for dataintensivt arbeid og kan gi lavere nettverkskostnader. Måten programvaren når lagringen på, former resten. Restic, et program for sikkerhetskopiering, definerer sikkerhetskopirepoet sitt som ganske enkelt en mappe med et sett undermapper og filer, og den samme mappen kan ligge på en lokal disk, på en server som nås over SFTP, eller i et objektlager som Google Cloud Storage eller Amazon S3. Bytene er de samme, mens latensen, måtene ting svikter på og hvem som styrer kontoen, alle endrer seg. ## Slik ser det ut i praksis Nedenfra og opp i stakken har arbeidet berørt det fysiske mediet som svikter, objektlageret som flytter hele filer, og kopien hos en annen leverandør som gjør det mulig å overleve tapet av en vert. Mediet: [datagjenoppretting ble utført på så å si alle vanlige lagringstyper](/nb/portfolio/performed-data-recovery-across-a-wide-range-of-92/), fra SD-kort og roterende harddisker til SSD-er, RAID-oppsett, eksterne disker og Mac-systemer. Folk kom med lagringsmedier som hadde sviktet eller tatt skade, og som holdt bilder, forretningsfiler eller den eneste kopien av noe som betydde noe. Hvert medium svikter og gir fra seg dataene sine på sin egen måte: en SSD er et annet problem enn en disk med plater, et RAID-oppsett er et annet problem igjen, og et filsystem på en Mac har sine egne særheter. Å kjenne riktig framgangsmåte for akkurat det mediet betydde like mye som noen enkelt teknikk, og kundene fikk tilbake kritiske data fra enheter de allerede hadde avskrevet. Objektlageret: i [seks ETL/ELT-pipeliner som matet Google BigQuery](/nb/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/), stod en bøtte i Google Cloud Storage mellom kilden og datavarehuset. Kuraterte datasett og tabeller ble eksportert til mellomformater, komprimert med gzip og overført til bøtta, og derfra lastet bq CLI og Python-skript dem inn i BigQuery. Hele komprimerte filer gikk inn, og hele filer kom ut, akkurat det mønsteret objektlagring er bygd for. Kopien et annet sted: [restic sender nå krypterte sikkerhetskopier over SFTP til en annen leverandør](/nb/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/). Før det lå alt selskapet har, på én skyinstans der leverandørens øyeblikksbilde var hele gjenopprettingsberedskapen. Det øyeblikksbildet lå i den samme kontoen som maskinen det beskyttet, ingen i selskapet hadde kryptert det, og ingen hadde noen gang gjenopprettet noe fra et slikt bilde. Nå kjører en systemd-timer en databasedump der det finnes en database, et kryptert og deduplisert øyeblikksbilde til den andre leverandøren, en opprydding etter oppbevaringsregelen og en integritetssjekk. Én gang i måneden hentes én kjent fil tilbake fra lagringen hos den andre leverandøren og sammenlignes, og det beviser at den eksterne kopien kan leses tilbake og ikke bare skrives. Med kopien hos en annen leverandør kan selskapet miste verten og likevel få dataene sine tilbake. ## Hvor det går galt Lagring svikter sjelden der noen ser etter. Som regel er det en kopi, en sjekk eller en kostnad som virket i orden fram til dagen den ble satt på prøve. **En kopi som deler skjebne med originalen.** Et øyeblikksbilde i den samme kontoen, en sikkerhetskopi på den samme disken, en replika i den samme bygningen: hver av dem overlever de små feilene og går under med den store. Skriv opp hver enkelthendelse som kan ta med seg begge, og flytt én kopi til listen er kort. **Redundans som telles som en sikkerhetskopi.** Et speil kopierer hver skriving til hver disk, slettinger og korrupte data inkludert. Det redder deg fra en død disk. En egen kopi med sin egen historikk er det som redder deg fra en feil. **Et objektlager som behandles som et filsystem.** Kode skrevet for filer regner med billige navnebytter og raske mappelister. I en bøtte med flatt navnerom er et navnebytte en kopi pluss en sletting, og Google påpeker at dypt nestede, mappelignende strukturer mangler listeytelsen til et ekte filsystem. Legg opp objektnavnene etter måten de skal leses på, og hold arbeid som endrer filer der de står, på fil- eller blokklagring. **En sjekk som leser indeksen og hopper over dataene.** Som standard sjekker restic-kommandoen `check` strukturen i sikkerhetskopirepoet og lar pakkefilene som holder de sikkerhetskopierte dataene, ligge uleste, fordi det å lese dem betyr å laste ned hver eneste en. `--read-data` leser alle, og `--read-data-subset=1/5` til og med `5/5` dekker dem alle over fem kjøringer. En sjekk som bare lister filer, beviser at navnene finnes, og sier lite om bytene bak dem. **En kald klasse som holder varme data.** En fil som leses daglig fra en klasse priset for månedlige lesinger, betaler en avgift hver gang den leses, så velg klassen etter lesemønsteret dataene faktisk har. ## Les mer - [NIST glossary: storage](https://csrc.nist.gov/glossary/term/storage) — de to betydningene av ordet slik NIST SP 800-88r2 definerer dem. - [Cloud Storage overview](https://cloud.google.com/storage/docs/introduction) — prosjekter, bøtter, objekter og mapper, og verktøyene som når dem. - [About Cloud Storage objects](https://cloud.google.com/storage/docs/objects) — data og metadata i et objekt, regler for navn, uforanderlighet og det flate navnerommet bak simulerte mapper. - [Cloud Storage: Storage classes](https://cloud.google.com/storage/docs/storage-classes) — holdbarhet, tilgjengelighet, minste lagringstid og avgifter for å hente data for hver klasse. - [restic: Preparing a new repository](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html) — hva et sikkerhetskopirepo er, og de lokale, SFTP-baserte og objektbaserte lagrene det kan ligge på. - [restic: Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html) — å sjekke strukturen i et sikkerhetskopirepo og lese tilbake dataene det holder.