En sikkerhetskopi du aldri har gjenopprettet, er ikke en sikkerhetskopi

Det verste tidspunktet å oppdage at en sikkerhetskopi ikke fungerer, er når du trenger den. Likevel er det nettopp dette som skjer oftest: Sikkerhetskopier konfigureres én gang, et grønt hakemerke vises i et dashboard i atten måneder, og så produserer en gjenoppretting en tom database.

Testing av gjenoppretting fra en sikkerhetskopi av en database er ikke en anbefalt praksis på samme måte som de fleste andre anbefalte praksiser er valgfrie. En sikkerhetskopi er en påstand, og før du har gjenopprettet én, er den en uprøvd påstand.

Slik feiler de, og dette må en verifisering faktisk kontrollere.

De fire måtene en sikkerhetskopi kan være ubrukelig på uten at noen merker det

1. Den er tom, og ingen har sett etter

En pg_dump som feiler underveis, kan fortsatt produsere en fil. En dump som kjøres mot feil databasenavn, produserer en gyldig, korrekt og tom fil. Begge ser vellykkede ut for alt som bare sjekker om prosessen avsluttes med en exit-kode ulik null, eller om en fil finnes.

Den billigste kontrollen i verden: se på størrelsen, og sammenlign den med gårsdagens. En sikkerhetskopi på 400 byte når gårsdagens var 40 MB, har fortalt deg alt. En sikkerhetskopi som har vært på 400 byte i seks måneder, har fortalt deg det hele tiden.

2. Den inneholder data, men ikke alt rundt dataene

pg_dump av én enkelt database inkluderer ikke roller og heller ikke andre databaser. Gjenopprett den på en ny server, så kommer tabellene på plass, mens alle GRANT-kommandoene viser til en rolle som ikke finnes. Appen kobler til og får «permission denied» på alt.

Utvidelser fungerer på samme måte. Hvis skjemaet ditt er avhengig av pgcrypto eller uuid-ossp, og målmiljøet ikke har dem, feiler gjenopprettingen underveis og etterlater noen tabeller.

3. Flaggene var feil for gjenopprettingen du trenger

pg_dump produserer ulike ting avhengig av formatet, og feilen oppdages vanligvis under press:

• Vanlig SQL gjenopprettes med psql og er lesbart for mennesker. Det kan ikke gjenopprettes selektivt, og det er tregt for store databaser.
• Custom-format (-Fc) gjenopprettes med pg_restore, støtter parallell kjøring og selektiv gjenoppretting, og er det du bør bruke for alt av en viss størrelse.

Å sikkerhetskopiere i vanlig format fordi det sto i veiledningen, og så oppdage under en hendelse at du ikke kan gjenopprette én enkelt tabell, er en helt spesifikk og unødvendig dårlig dag.

4. Du kan ikke dekryptere den

Hvis sikkerhetskopier er kryptert – og det bør de være – er nøkkelen en del av sikkerhetskopien. En nøkkel som bare finnes på maskinen som gikk tapt, eller bare i en miljøvariabel for tjenesten som er nede, er en nøkkel du ikke har når den faktisk trengs.

Slik ser en reell verifisering ut

Testen er ikke «finnes filen». Det er å gjenopprette den et annet sted og stille den et spørsmål.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

Steg 2 er hele poenget. En gjenoppretting som fullføres uten feil, forteller deg fortsatt ingenting om hvorvidt dataene faktisk finnes. Det gjør radantall og en kontroll av hvor ferske dataene er.

Tre ting det er verdt å verifisere:

• Radantallet er i riktig størrelsesorden. Ikke nøyaktig – dataene endrer seg – men en tabell som hadde 200 000 rader og nå har 12, er et tegn på feil.
• Den nyeste posten er fersk. Hvis den nyeste ordren i den «daglige» sikkerhetskopien din er fra mars, sluttet jobben for sikkerhetskopiering i mars.
• Appen kan faktisk koble til. Pek en staging-instans mot den gjenopprettede databasen og last inn én side.

Gjør det etter en plan, ikke når du får tid

En realistisk frekvens er månedlig, automatisert, med resultatet et sted du vil legge merke til det. En kalenderpåminnelse om å «teste sikkerhetskopier» er en påminnelse du kommer til å utsette.

Det som gjør at dette faktisk blir gjort, er å sørge for at feil blir tydelige: Hvis verifiseringsspørringen returnerer færre rader enn en terskelverdi, bør det varsles til noen på samme måte som en produksjonsfeil ville gjort. Et system for sikkerhetskopiering som feiler stille, kan ikke skilles fra et system uten sikkerhetskopiering – helt frem til det faktisk gjelder.

Slik håndterer Dockup dette

Tre beslutninger, hver rettet mot en konkret feil ovenfor.

Sikkerhetskopier lagres et annet sted. En sikkerhetskopi på samme disk som databasen er ikke en sikkerhetskopi – det er en kopi som forsvinner sammen med disken. Dockup strømmer sikkerhetskopier av databaser direkte til objektlagring mens de opprettes, slik at filen aldri er avhengig av verten som laget den.

De er kryptert, og nøkkelen ligger ikke på maskinen. Sikkerhetskopier krypteres med AES-256-GCM mens de strømmes. Det viktige for gjenoppretting er at nøkkelen oppbevares av plattformen i stedet for å ligge i miljøet til tjenesten som sikkerhetskopieres.

En sikkerhetskopi som ikke produserte noe, registreres ikke som en sikkerhetskopi. Dette håndterer tomme filer direkte: Hvis dumpen avsluttes med en exit-kode ulik null eller produserer null byte, slettes opplastingen, og sikkerhetskopien registreres som mislykket. Du ender ikke opp med en liste over grønne oppføringer der én av dem er en fil på 400 byte.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Størrelsene i denne listen er den billigste helsekontrollen du har. Følg utviklingen over tid.

Det ubehagelige spørsmålet

Hvis produksjonsdatabasen din ble ødelagt i løpet av de neste ti minuttene, hvor lang tid ville det tatt å få den tilbake, og hvor mye ville du ha mistet?

Hvis du ikke kan svare på begge spørsmålene, har du ikke en strategi for sikkerhetskopiering – du har sikkerhetskopifiler. Forskjellen ligger utelukkende i om noen faktisk har gjennomført gjenopprettingen.

Vanlige spørsmål

Hvor ofte bør jeg teste en gjenoppretting? Månedlig er et rimelig utgangspunkt, automatisert fremfor manuelt. Det viktige er at en feil blir tydelig, ikke at frekvensen er høy.

Hvorfor ble gjenopprettingen fullført uten at det kom noen data? Vanligvis ble dumpen tatt mot feil database, eller så feilet den underveis mens den fortsatt skrev til en fil. Sammenlign størrelsen på sikkerhetskopiene over tid – en tom dump er tydelig i en størrelsesutvikling og usynlig i en statuskolonne.

Bør sikkerhetskopier være kryptert? Ja, og nøkkelen må oppbevares et sted som overlever at du mister maskinen. En kryptert sikkerhetskopi der nøkkelen lå på den tapte serveren, kan ikke gjenopprettes.

Er et snapshot det samme som en sikkerhetskopi? Nei. Et volum-snapshot fanger opp disken, inkludert tilstanden databasen var i akkurat da. En logisk dump er konsistent i kraft av hvordan den opprettes. De fleste team ønsker begge deler, fordi de dekker ulike feil.