# Lagring ## Vad det är Datalagring, oftast kallad bara lagring, är den del av ett system där data finns mellan användningarna, på medier som behåller dem genom en omstart och ett strömavbrott. Ordlistan hos NIST ger ordet två betydelser, båda hämtade från SP 800-88r2: att data bevaras så att de kan hämtas igen, och den hårdvara som data kan föras in i och hämtas ur. Varje sort vilar på ett fysiskt medium: en hårddisk med snurrande skivor, en SSD, ett SD-kort, ett band. Programvaran ser ett av tre lager ovanpå det: - **Blocklagring** visar en enhet som en följd av block med fast storlek, adresserade med nummer. En diskpartition, en RAID-array och en virtuell disk i molnet ser alla ut så för systemkärnan, och ett filsystem eller en databasmotor avgör vad blocken betyder. - **Fillagring** lägger ett filsystem över blocken: namn, kataloger, storlekar, ägare och behörigheter, och en fil kan ändras några byte i taget. Delat över NFS eller SMB betjänar ett och samma träd många maskiner. - **Objektlagring** håller hela objekt, vart och ett en följd av byte plus metadata, under ett namn i en behållare, och nås genom ett API över HTTP i stället för genom en montering. Google Cloud Storage lagrar data som objekt i behållare som kallas buckets, varje bucket hör till ett projekt, och ett objekt är en oföränderlig bit data som består av en fil i vilket format som helst. De tre skiljer sig åt i vad en ändring kostar. En blockenhet skriver om ett block där det ligger. Ett filsystem redigerar en del av en fil och flyttar den med ett namnbyte. Ett objektlager ersätter hela objektet: Googles sida om objekt utesluter tillägg i slutet och avkortning, och en ersättning är atomär, så den som läser får den gamla versionen tills den nya uppladdningen är klar. Ett namnbyte blir en kopia under det nya namnet och en radering av originalet. I en bucket med platt namnrymd är mappar en bild som verktygen ritar upp utifrån snedstreck i objektens namn; strängen `folder1/` är en del av namnet, och bucketen lagrar ingen mapp alls. Samma fil ser ut så här i varje lager: ```sh # block: kärnans bild av en disk som numrerade block lsblk /dev/sda # fil: ett filsystem monterat över blocken, med namn och kataloger df -h /srv # objekt: ett helt objekt som skickas till en bucket över ett API gcloud storage cp readings.csv.gz gs://example-bucket/2024/01/ ``` ## Varför det spelar roll Mediet avgör hur data går förlorade. En hårddisk, en SSD och ett SD-kort går sönder vart och ett på sitt sätt, och en räddningsmetod som passar det ena är fel verktyg för nästa. Redundans inuti en och samma låda, som ett speglat par eller en RAID-array, håller data läsbara efter att en enskild disk har dött, men den skriver varje radering till varje disk lika troget som den skriver data. Hållbarhet och tillgänglighet är två skilda löften. Hållbarhet är sannolikheten att lagrade data överlever; tillgänglighet är sannolikheten att de går att läsa vid ett givet ögonblick. Cloud Storage anger en årlig hållbarhet på 99,999999999 % för varje lagringsklass, medan den typiska tillgänglighet per månad som tjänsten anger går från 99,9 % till över 99,99 %, beroende på klass och plats. En lagringsklass är metadata på varje objekt som bestämmer dess tillgänglighet och prismodell, och nya objekt ärver standardklassen i sin bucket. De kallare klasserna byter ett lägre pris för att behålla data mot något lägre tillgänglighet, en minsta lagringstid på 30, 90 eller 365 dagar och en avgift för att läsa tillbaka data; Google riktar dem mot data som läses en gång i månaden eller mer sällan, högst en gång per kvartal och mindre än en gång per år. Platsen är en del av datan. En kopia på samma disk, samma maskin eller samma molnkonto delar öde med den saken, och en kopia någon annanstans gör det inte. Platsen bestämmer också hastighet och kostnad: Google noterar att om data hålls i samma region som den beräkning som använder dem får dataintensivt arbete bäst prestanda, och nätverksavgifterna kan bli lägre. Hur programvaran når lagringen formar resten. Restic, ett program för säkerhetskopiering, definierar sitt repo som helt enkelt en katalog som innehåller en uppsättning underkataloger och filer, och samma katalog kan ligga på en lokal disk, på en server som nås över SFTP eller i ett objektlager som Google Cloud Storage eller Amazon S3. Innehållet förblir detsamma, medan latensen, sätten att gå sönder och den person som styr kontot alla ändras. ## Så ser det ut i praktiken Lagringen här spänner över tre nivåer: själva mediet, från SD-kort till RAID-arrayer, ett objektlager i molnet och till sist en krypterad kopia som ligger hos en annan leverantör. Mediet: [dataräddningen omfattade i stort sett alla vanliga lagringstyper](/sv/portfolio/performed-data-recovery-across-a-wide-range-of-92/), från SD-kort och snurrande hårddiskar till SSD:er, RAID-arrayer, externa diskar och Mac-system. Folk kom in med lagringsmedier som hade gått sönder eller skadats, med foton, affärsdokument, den enda kopian av något som betydde något. Varje medium går sönder och lämnar ifrån sig sina data på sitt eget sätt: en SSD är ett annat problem än en disk med roterande skivor, en RAID-array är ännu ett annat problem, och ett Mac-filsystem har sina egna egenheter. Att veta vilket angreppssätt som passar just det mediet betydde lika mycket som någon enskild teknik, och kunderna fick tillbaka kritiska data från enheter som de redan hade avskrivit som förlorade. Objektlagret: i [sex ETL/ELT-pipelines som matade Google BigQuery](/sv/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/) stod en bucket i Google Cloud Storage mellan källan och analysdatalagret. Kurerade dataset och tabeller exporterades till mellanformat, komprimerades med gzip och överfördes till bucketen, och därifrån läste verktyget bq och Python-skript in dem i BigQuery. Hela komprimerade filer gick in och hela filer kom ut, det mönster som objektlagring är byggd för. Kopian någon annanstans: [krypterade säkerhetskopior med restic gick över SFTP till lagring hos en annan leverantör](/sv/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/). Dessförinnan låg allt som företaget har på en enda molninstans, vars ögonblicksbild hos leverantören var hela återställningsberedskapen: ögonblicksbilden låg i samma konto som maskinen den skyddade, ingen på företaget hade krypterat den, och ingen hade någonsin återställt något från en sådan. En timer i systemd kör nu en databasdump där det finns en databas, en krypterad och deduplicerad ögonblicksbild till den andra leverantören, en gallring enligt bevarandepolicyn och en integritetskontroll. Varje månad tar en återställningsövning tillbaka en fil med känt innehåll ur repot hos den leverantören och jämför den. Med kopian hos en andra leverantör kan företaget förlora värden och ändå få tillbaka sina data. ## Var det går fel Det mesta besväret med lagring kommer från en kopia, en kontroll eller en kostnad som såg bra ut fram till den dag den behövdes. **En kopia delar öde med originalet.** En ögonblicksbild i samma konto, en säkerhetskopia på samma disk, en replik i samma byggnad: var och en överlever de små felen och går under med det stora. Lista de enskilda händelser som skulle kunna slå ut båda, och flytta en kopia tills listan är kort. **Redundans räknas som en säkerhetskopia.** En spegel kopierar varje skrivning till varje disk, raderingar och korrupta data inräknade. Den är svaret på en död disk; en separat kopia med en egen historik är svaret på ett misstag. **Ett objektlager behandlas som ett filsystem.** Kod som är skriven för filer räknar med billiga namnbyten och kataloglistningar. I en bucket med platt namnrymd är ett namnbyte en kopia plus en radering, och Google noterar att djupt nästlade, katalogliknande strukturer saknar listningsprestandan hos ett riktigt filsystem. Lägg upp objektnamnen efter hur de kommer att läsas, och håll arbete som redigerar filer på plats kvar i fil- eller blocklagring. **Kontrollen läser indexet och hoppar över datan.** Som standard verifierar kommandot `check` i restic repots struktur och lämnar de packfiler som håller de säkerhetskopierade data olästa, eftersom det skulle innebära att ladda ned varenda en. `--read-data` läser alla, och `--read-data-subset=1/5` till och med `5/5` täcker repot på fem körningar. En kontroll som bara listar filer bevisar att namnen finns, och säger lite om innehållet bakom dem. **Data som läses ofta ligger i en kall klass.** En fil som läses varje dag från en klass som är prissatt för läsningar en gång i månaden betalar en avgift vid varje läsning, så matcha klassen mot det läsmönster som datan faktiskt har. ## Läs mer - [NIST glossary: storage](https://csrc.nist.gov/glossary/term/storage) — ordets två betydelser så som NIST SP 800-88r2 definierar dem. - [Cloud Storage overview](https://cloud.google.com/storage/docs/introduction) — projekt, buckets, objekt och mappar, och verktygen som når dem. - [About Cloud Storage objects](https://cloud.google.com/storage/docs/objects) — objektens data och metadata, regler för namn, oföränderlighet och den platta namnrymden bakom simulerade mappar. - [Cloud Storage: Storage classes](https://cloud.google.com/storage/docs/storage-classes) — hållbarhet, tillgänglighet, minsta lagringstid och avgifter för hämtning för varje klass. - [restic: Preparing a new repository](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html) — vad ett repo är, och de lokala backends, SFTP-backends och objektlager som det kan ligga på. - [restic: Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html) — att kontrollera ett repos struktur och läsa tillbaka de data det håller.