# Sikkerhetskopi ## Hva det er En sikkerhetskopi er det dataene hentes tilbake fra når originalen blir slettet, ødelagt eller forsvinner sammen med maskinen som holdt den, og derfor må den ligge et sted disse hendelsene ikke når. NIST-ordlisten definerer den som en kopi av filer og programmer laget for å gjøre gjenoppretting enklere. På norsk heter selve kopien sikkerhetskopi og arbeidet med å lage den sikkerhetskopiering, mens mange i bransjen bare sier backup om begge deler: en nattlig jobb sikkerhetskopierer databasen og etterlater en sikkerhetskopi. Ting i nærheten blir tatt for å være det samme. En replika får hver endring i løpet av sekunder, noe som beskytter mot en død disk og kopierer en feilaktig `DELETE` like trofast. Et øyeblikksbilde fryser et volum i ett øyeblikk, og blir en sikkerhetskopi først når det lagres et sted der feilene som rammer originalen, ikke kan følge etter. En sikkerhetskopi er definert av historikk og atskillelse: den gir tilbake dataene slik de var på et tidligere tidspunkt, fra et sted som overlevde det som tok originalen. Databaser gjør dette konkret. PostgreSQL-manualen beskriver tre grunnleggende forskjellige tilnærminger. En SQL-dump, laget med `pg_dump`, skriver ut setningene som bygger opp databasen igjen, som et konsistent bilde av øyeblikket dumpen startet. En sikkerhetskopi på filsystemnivå kopierer selve datakatalogen. Kontinuerlig arkivering kombinerer én slik basekopi (base backup) med write-ahead-loggen (WAL) serveren skriver etterpå, og ved å spille av den loggen kan databasen gjenopprettes til et hvilket som helst øyeblikk etter basekopien. Den evnen kalles gjenoppretting til et tidspunkt (point-in-time recovery). ## Hvorfor det er viktig To tall gjør et generelt ønske om å være trygg om til et design. NIST definerer gjenopprettingspunktmålet, RPO (recovery point objective), som tidspunktet dataene må gjenopprettes til etter et avbrudd: i praksis hvor mye nylig arbeid virksomheten har råd til å miste. Gjenopprettingstidsmålet, RTO (recovery time objective), er hvor lenge et system kan være under gjenoppretting før avbruddet skader det organisasjonen er til for. De to trekker i ulike deler av designet. RPO bestemmes av hvor ofte en kopi tas: en nattlig dump kan miste et døgn med skrivinger, mens WAL-arkivering krymper tapet til de siste øyeblikkene med logg som fortsatt er på vei til arkivet. RTO bestemmes av hvor lang tid en gjenoppretting tar. PostgreSQL-manualen påpeker at serveren spiller av hvert WAL-segment siden siste basekopi, noe som kan ta tid når den kopien er gammel, så hvor ofte basekopier tas, er like mye en RTO-beslutning som et spørsmål om lagringsplass. Begge tallene er påstander om en gjenoppretting, og derfor bedømmes en sikkerhetskopi ved å gjenopprette den. En jobb som avslutter med status null, viser at noen byte ble skrevet et sted. Om de bygger opp et fungerende system innenfor RTO, får du svar på ved å gjenopprette etter en fast plan, et annet sted enn i produksjon, og sammenligne det som kommer tilbake. Atskillelse er den andre halvdelen. En kopi i samme konto, under samme påloggingsinformasjon, deler feilene den er ment å overleve: en stengt konto, en stjålet nøkkel, et skript kjørt mot feil mål. Det nyttige spørsmålet for hver kopi er hvilken enkelt hendelse som ville tatt den sammen med originalen. ## Slik ser det ut i praksis Alt ett selskap har, lå på én skyinstans, og leverandørens øyeblikksbilde av den var hele gjenopprettingsberedskapen: i samme konto som maskinen, uten kryptering noen her styrte, og aldri brukt til en gjenoppretting. Erstatningen er en systemd-timer som tar en databasedump, sender et kryptert, deduplisert restic-øyeblikksbilde til lagring hos en annen leverandør over SFTP, rydder gamle øyeblikksbilder etter en regel for oppbevaring og kjører en integritetssjekk. En dødmannsknapp pinges bare når alt lykkes, så det er en stille kjøring som utløser alarmen. En separat [gjenopprettingsøvelse henter hver måned en kjent fil ut av repoet og sammenligner den](/nb/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/), så påstanden om at selskapet kan miste verten og få dataene tilbake, hviler på en gjenoppretting som kjørte forrige måned, og ikke på en sikkerhetskopi som kjørte i natt. I større skala ble [hundre kritiske sikkerhetskopier av data automatisert med Barman og Google Cloud](/nb/portfolio/automated-100-critical-data-backups-using-barman-google-18/) for et produkt som lever av GIS-dataene sine. Barman tok seg av PostgreSQL, Google Cloud holdt kopiene utenfor huset, og Bash og Python orkestrerte og validerte kjøringene. Integritetskontroller bekreftet at hver sikkerhetskopi var god, og ikke bare til stede. På et tredje produkt gikk arbeidet ut på å definere gjenopprettingsevnen i stedet for å anta den. [Oppbevaringstiden for sikkerhetskopier ligger i Bicep-malen ved siden av databasen](/nb/portfolio/configured-database-backup-retention-as-infrastructure-as-code-72/), så gjenoppretting til et tidspunkt er en egenskap ved malen og ikke en innstilling noen en gang klikket seg fram til i en portal, og miljøet rundt er også kode. Revisjonen skrev ned hullene: georedundans er slått av, og RTO er foreslått og ikke målt, med øvelsen som skulle måle den, beskrevet og klar til å kjøres. ## Hvor det går galt Problemer med sikkerhetskopier holder seg gjerne skjult til det trengs en gjenoppretting, så hvert av dem er verdt å lete etter en rolig dag. **En filkopi av en kjørende database blir gjenopprettet som en ødelagt klynge.** Å kopiere datakatalogen til PostgreSQL med `tar` mens serveren kjører, samler filer fra ulike øyeblikk, og manualen sier at serveren må stoppes for å få en brukbar sikkerhetskopi på denne måten. Et øyeblikksbilde av filsystemet tatt i ett atomært øyeblikk virker hvis det tar med WAL, som serveren spiller av ved oppstart slik den ville gjort etter et krasj; med data og WAL på ulike filsystemer kan et samtidig øyeblikksbilde være umulig. `pg_dump`, eller en basekopi for kontinuerlig arkivering, gir en konsistent kopi mens serveren fortsetter å kjøre. **Et hull i WAL-arkivet avslutter gjenopprettingen til et tidspunkt ved hullet.** Gjenoppretting krever en ubrutt rekke arkiverte WAL-filer helt tilbake til starten av basekopien. Når arkiveringskommandoen feiler gang på gang, fortsetter PostgreSQL å prøve på nytt, og WAL hoper seg opp i `pg_wal/`, så det første symptomet er ofte en disk som fylles. Manualen råder til å sette opp og teste arkiveringen før den første basekopien, og å overvåke den for forsinkelser. **Jobben stopper, og tausheten ser ut som suksess.** En timerjobb som slutter å virke, skriver feilen sin til en logg ingen leser, og hver stille dag går for å være en god dag. Overvåkingen må behandle taushet som alarmen: en innsjekking som sendes bare etter en vellykket kjøring, til en tjeneste som varsler vakthavende når den uteblir, fanger opp en jobb som har stoppet, like godt som en som feiler høylytt. **Nøkkelen blir borte, eller kommer fram endret.** Kryptering flytter hele risikoen over på nøkkelen, og dokumentasjonen til restic er rett på sak: mister du passordet, er dataene ugjenkallelig tapt. Nøkkelen må ligge et sted som overlever maskinen. I restic-oppsettet ovenfor leses passfrasen fra en fil og ikke fra miljøet, fordi tjenestestyreren tolker escape-sekvenser i miljøverdier, og en passfrase med en omvendt skråstrek ville i det stille kommet fram som en annen enn den som opprettet sikkerhetskopirepoet. **Oppbevaringsregelen fjerner kopien som trengtes.** Korrupsjon blir ofte oppdaget uker etter at den skjedde, og en regel som beholder sju daglige kopier, har da erstattet hver rene kopi med en skadet en. En regel i flere trinn beholder en lang hale til lav kostnad, og `--dry-run` i restic viser hva en regel ville fjernet før noe forsvinner: ```bash restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 \ --prune --dry-run ``` `forget` fjerner øyeblikksbilder, og `prune` fjerner dataene bare de viste til, så etter en prune er de gamle kopiene borte for godt. **Integritetssjekken går gjennom, og gjenopprettingen feiler likevel.** Som standard verifiserer `restic check` strukturen i sikkerhetskopirepoet uten å lese hver pakkefil, siden det ville bety å laste ned alle sammen; `--read-data` leser alt, og `--read-data-subset=1/5` leser en femtedel, så fem kjøringer fra `1/5` til `5/5` dekker hele mengden. En full lesing beviser bare at de lagrede bytene er intakte. Om de bygger opp en fungerende database, med de riktige rollene og innstillingene, er noe bare en gjenoppretting viser. ## Les mer - [NIST glossary: backup](https://csrc.nist.gov/glossary/term/backup) — definisjonen som brukes her, og publikasjonene den bygger på. - [NIST SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) — veiledningen i beredskapsplanlegging som definerer RPO og RTO. - [PostgreSQL: Backup and Restore](https://www.postgresql.org/docs/current/backup.html) — de tre tilnærmingene og hva hver av dem koster. - [PostgreSQL: Continuous Archiving and Point-in-Time Recovery](https://www.postgresql.org/docs/current/continuous-archiving.html) — basekopier, WAL-arkivering og gjenoppretting til et valgt øyeblikk. - [restic: Preparing a new repository](https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html) — passord, passordfiler og advarselen om å miste dem. - [restic: Removing backup snapshots](https://restic.readthedocs.io/en/stable/060_forget.html) — regler for oppbevaring, `forget`, `prune` og `--dry-run`.