Sannsynligvis har du en «backup». Den kjører hver natt, den har gjort det i to år, og ingen har noen gang forsøkt å bruke den. Det betyr at du har en rutine som produserer filer. Om disse filene kan bringe nettsiden din tilbake, vet du ikke før du prøver.

Dette er ikke pedanteri. De vanligste backupfeilene oppdages bare på én måte: den dagen du trenger dem. Passordet er borte. Databasen ble aldri med. Kopien ligger på samme server som originalen, og serveren er det som er borte.

Tre ting som ikke er backup #

La oss rydde først, fordi de tre er lette å forveksle:

  • Synkronisering holder to steder like. Det er hele poenget, og hele problemet: sletter du en fil, forsvinner den begge steder. Ødelegges den, ødelegges kopien også. Synkronisering beskytter mot at én maskin dør, ikke mot at du gjør noe dumt.
  • Versjonshistorikk lar deg gå tilbake til en tidligere utgave av en fil. Nyttig, men det er ofte begrenset i tid, lever vanligvis i samme tjeneste og samme konto, og forsvinner sammen med dem hvis kontoen blir kapret eller låst.
  • Backup er en separat kopi, på et annet sted, som ikke endres av det som skjer i originalen, og som du har bevist at du kan hente ut igjen.

Bare den siste er backup. De to første er bra å ha, men de erstatter den ikke.

3-2-1 for en liten nettside #

Regelen er enkel: tre kopier av dataene, på to ulike typer lagring, med én kopi utenfor stedet der de ligger. For en liten nettside eller en enkeltmannsvirksomhet kan det se slik ut:

  1. Kopi 1: originalen. Filene og databasen på serveren. Dette teller som en kopi, men er den du minst bør stole på.
  2. Kopi 2: ekstern kopi. Daglig, kryptert, til lagring hos en annen leverandør enn der serveren står, med egen konto og egne nøkler.
  3. Kopi 3: frakoblet eller uavhengig. En ekstern disk du kobler til når du tar kopien, og kobler fra igjen. Eller en andre leverandør med helt egne nøkler. Poenget er at et innbrudd i serveren din ikke gir tilgang til å slette denne.

Det siste er den som oftest mangler. Hvis serveren har nøkler som kan slette alle kopiene, har du ikke tre kopier. Du har én, med ekstra steg. Bruk, der leverandøren støtter det, legitimasjon som bare kan legge til nye data (ofte kalt «append-only» eller objektlås), slik at serveren ikke kan fjerne de gamle.

Et lite oppsett med restic #

restic er et kommandolinjeverktøy som lager krypterte, versjonerte backuper. Dokumentasjonen lister blant annet lokal lagring, SFTP, S3-kompatibel lagring og Backblaze B2 som støttede mål, så du kan velge leverandør uten å bytte verktøy. Eksemplet under er et skisseoppsett, ikke en ferdigtestet oppskrift for din server. Tilpass stier, og kjør det først på testdata.

bash 
# Forutsetninger (eksempel): Postgres-database og filer i /var/www/site
export RESTIC_REPOSITORY="sftp:backup@backup.example.net:/srv/restic-repo"
export RESTIC_PASSWORD_FILE="/root/.restic-passord"   # chmod 600

restic init                                           # én gang

# Hver natt:
pg_dump -Fc mindb > /var/backups/db/mindb.dump
restic backup /var/www/site /var/backups/db
restic snapshots                                      # se at det faktisk ble en ny

To detaljer som ofte glemmes. Databasen tas som en dump, ikke ved å kopiere de levende filene mens den kjører. Og passordet til repoet: uten det er kopien ubrukelig, fordi dataene er kryptert. Legg det i en passordbehandler, og ha det i tillegg et sted som ikke er serveren.

Restore-testen: slik beviser du det #

Backupen er ikke det du lager. Den er det du får tilbake. Så test den, i denne rekkefølgen.

1. Sjekk at repoet er helt. Dokumentasjonen for restic check er tydelig på at standardsjekken verifiserer strukturen, ikke innholdet i alle pakkefilene. Vil du lese dataene, bruker du --read-data, som laster ned alt og dermed koster båndbredde og tid. Et kompromiss er --read-data-subset, som sjekker en del per kjøring:

bash 
restic check                              # struktur og konsistens
restic check --read-data-subset=10%       # leser et tilfeldig utvalg av dataene

Ifølge dokumentasjonen må du reparere repoet hvis check melder feil, og inntil videre kan gjenoppretting av enkelte filer feile.

2. Gjenopprett til et tomt sted, ikke over originalen.

bash 
mkdir /tmp/restore-test
restic restore latest --target /tmp/restore-test

3. Sammenlign. Ikke stol på at kommandoen «gikk bra». Sjekk noen filer du vet er viktige:

bash 
sha256sum /var/www/site/index.html /tmp/restore-test/var/www/site/index.html

Sjekksummene skal være like for filer som ikke har endret seg siden backupen.

4. Gjenopprett databasen til en testdatabase og se at det er noe i den.

bash 
createdb restoretest
pg_restore -d restoretest /tmp/restore-test/var/backups/db/mindb.dump
psql restoretest -c "SELECT count(*) FROM artikler;"

Tellingen skal være rimelig. En tom tabell er en feil, selv om kommandoen ikke klaget.

5. Start siden fra gjenopprettede filer. Det er den ekte testen. Kommer siden opp, med innhold og bilder? Hvis ikke, har du funnet noe som manglet, og du fant det en rolig dag.

6. Skriv ned hvor lang tid det tok, og hva du måtte slå opp. Det er din reelle gjenopprettingstid. Hvis du trengte tre ting du ikke husket, skriv dem inn i en kort rutine.

Hvor ofte? #

Gjør hele testen første gang, og så på en fast frekvens du faktisk holder, for eksempel hvert kvartal, og alltid etter store endringer: ny server, nytt lagringsmål, ny database. Kjør den lette check-varianten automatisk på timeplan og la den varsle deg om feil. Ingen av delene krever mye tid, og begge er billigere enn å oppdage problemet under press.

Ikke kjøp løftet om «ett klikk» #

Det finnes tjenester som lover trygg sikkerhetskopiering «med ett klikk». Noen er gode. Men et klikk beviser ikke at du kan gjenopprette, og det forteller deg ikke hva som faktisk er med. Spør alltid: hva tar den med, hvor lagres kopien, hvem kan slette den, og hvordan får jeg ting tilbake? Prøv så svaret.

Du har ikke en backupplan før du har tatt en gjenoppretting og fått en fungerende nettside ut av den. Gjør det én gang. Det tar en ettermiddag, og det er forskjellen på en rutine og en antakelse.