En backup du aldrig har återställt är ingen backup

Det värsta tillfället att upptäcka att en backup inte fungerar är när du behöver den. Ändå är det precis så det oftast ser ut: backuper konfigureras en gång, en grön bock visas i en dashboard i arton månader, och sedan ger en restore en tom databas.

Att testa restore av en database-backup är inte en best practice på det sätt som de flesta best practices är valfria. En backup är ett påstående, och tills du har återställt en har du bara ett otestat påstående.

Så här fallerar de, och det här måste en verifiering faktiskt kontrollera.

De fyra sätten en backup kan vara oanvändbar utan att någon märker det

1. Den är tom och ingen tittade

En pg_dump som fallerar halvvägs kan fortfarande skapa en fil. En dump som körs mot fel databasnamn ger en giltig, korrekt och tom fil. Båda ser ut som lyckade körningar för allt som bara kontrollerar en exit-kod som inte är noll eller att en fil existerar.

Världens billigaste kontroll: titta på storleken och jämför med gårdagens. En backup på 400 byte när gårdagens var 40 MB har berättat allt du behöver veta. En backup som varit 400 byte i sex månader har försökt berätta det hela tiden.

2. Den innehåller data, men inte allt runtomkring

pg_dump av en enskild databas inkluderar inte roller och inte heller andra databaser. Återställ den på en ny server så kommer tabellerna på plats, medan varje GRANT hänvisar till en roll som inte finns. Applikationen ansluter och får nekad åtkomst till allt.

Extensions fungerar på samma sätt. Om ditt schema är beroende av pgcrypto eller uuid-ossp och målservern saknar dem, fallerar restore-processen halvvägs och lämnar efter sig vissa tabeller.

3. Flaggorna var fel för den restore du behöver

pg_dump producerar olika saker beroende på format, och misstaget upptäcks vanligtvis under press:

• Plain SQL återställs med psql och är läsbart för människor. Det kan inte återställas selektivt och är långsamt för stora databaser.
• Custom format (-Fc) återställs med pg_restore, stöder parallellism och selektiv restore och är det du vill använda för allt av betydande storlek.

Att ta backup i plain format eftersom handledningen gjorde det, för att sedan upptäcka under en incident att du inte kan återställa en enskild tabell, är ett specifikt och helt undvikbart slags dålig dag.

4. Du kan inte dekryptera den

Om backuperna är krypterade — vilket de bör vara — är nyckeln en del av backupen. En nyckel som bara finns på maskinen som försvann, eller bara i en environment variable för tjänsten som ligger nere, är en nyckel du inte har när den behövs.

Så här ser en riktig verifiering ut

Testet är inte ”finns filen?”. Det är att återställa den någon annanstans och ställa en fråga till databasen.

# 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 är hela poängen. En restore som slutförs utan fel säger fortfarande ingenting om huruvida datan finns där. Radantal och en kontroll av hur aktuell datan är gör det.

Tre saker som är värda att kontrollera:

• Radantalen ligger i rätt storleksordning. Inte exakt — data förändras — men en tabell som hade 200 000 rader och nu har 12 innebär ett fel.
• Den nyaste posten är aktuell. Om den senaste ordern i din ”nattliga” backup är från mars slutade backup-jobbet i mars.
• Applikationen kan faktiskt ansluta. Rikta en staging-instans mot den återställda databasen och läs in en sida.

Gör det enligt ett schema, inte när det passar

En realistisk frekvens är varje månad, automatiserat, med resultatet någonstans där du kommer att märka det. En kalenderpåminnelse om att ”testa backuper” är en påminnelse du kommer att snooza.

Det som får detta att fungera är att göra fel tydliga: om verifieringsfrågan returnerar färre rader än ett tröskelvärde ska någon få en alert på samma sätt som vid ett produktionsfel. Ett backupsystem som fallerar tyst går inte att skilja från inget backupsystem alls, åtminstone inte förrän det verkligen behövs.

Så hanterar Dockup detta

Tre beslut, vart och ett riktat mot ett specifikt fel ovan.

Backuper lagras någon annanstans. En backup på samma disk som databasen är ingen backup — det är en kopia som försvinner tillsammans med disken. Dockup streamar database-backuper direkt till object storage medan de skapas, så filen aldrig är beroende av värddatorn som skapade den.

De är krypterade, och nyckeln finns inte på maskinen. Backuper krypteras med AES-256-GCM medan de streamas. Det viktiga ur recovery-perspektiv är att nyckeln hanteras av plattformen i stället för att ligga i environment för tjänsten som säkerhetskopieras.

En backup som inte producerade något registreras inte som en backup. Det här hanterar problemet med tomma filer direkt: om dumpen avslutas med en exit-kod som inte är noll eller producerar noll byte raderas uppladdningen och backupen registreras som misslyckad. Du får inte en lista med gröna poster där en av dem är 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

Storlekarna i den listan är den billigaste hälsokontroll du har. Följ trenden över tid.

Den obekväma frågan

Om din produktionsdatabas förstördes under de närmaste tio minuterna, hur lång tid skulle det ta att få tillbaka den, och hur mycket skulle du ha förlorat?

Om du inte kan svara på båda frågorna har du ingen backupstrategi — du har backupfiler. Skillnaden ligger helt i huruvida någon någonsin har genomfört en restore.

Vanliga frågor

Hur ofta bör jag testa en restore?
En gång i månaden är en rimlig standard, automatiserat snarare än manuellt. Det viktiga är att ett fel märks tydligt, inte att frekvensen är särskilt hög.

Varför slutfördes min restore utan att skapa någon data?
Vanligtvis togs dumpen mot fel databas eller så fallerade den halvvägs medan filen fortfarande skrevs. Jämför backupstorlekar över tid — en tom dump syns tydligt i storlekstrenden men inte i en statuskolumn.

Bör backuper vara krypterade?
Ja, och nyckeln måste finnas någonstans som överlever att maskinen förloras. En krypterad backup vars nyckel fanns på den förlorade servern går inte att återställa.

Är en snapshot samma sak som en backup?
Nej. En volume snapshot avbildar disken, inklusive det tillstånd databasen befann sig i just då. En logisk dump är konsistent genom sin konstruktion. De flesta team vill ha båda, eftersom de skyddar mot olika typer av fel.