A soha vissza nem állított backup nem backup

A legrosszabb pillanat annak felfedezésére, hogy egy backup nem működik, az, amikor szükséged van rá. Ennek ellenére pontosan ez a leggyakoribb forgatókönyv: a backupot egyszer beállítják, egy dashboardon tizennyolc hónapon át zöld pipa látható, majd egy visszaállítás üres adatbázist eredményez.

Az adatbázis-backup visszaállításának tesztelése nem olyan best practice, amelyet a legtöbb best practice-hez hasonlóan opcionálisnak lehet tekinteni. A backup egy állítás, és amíg nem állítottál vissza egyet, ez az állítás nem tesztelt.

Így vallanak kudarcot, és ezt kell ténylegesen ellenőrizni egy validálás során.

A négy mód, ahogyan egy backup észrevétlenül használhatatlanná válik

1. Üres, és senki sem ellenőrizte

Egy részben hibásan lefutó pg_dump is létrehozhat fájlt. Ha a dump a rossz adatbázisnév ellen fut, érvényes, helyes, de üres fájlt kapsz. Mindkettő sikeresnek tűnik minden olyan ellenőrzés számára, amely csak a nem nulla exit code-ot vagy a fájl létezését vizsgálja.

A világ legolcsóbb ellenőrzése: nézd meg a méretét, és hasonlítsd össze a tegnapival. Ha a tegnapi backup 40 MB volt, a mostani pedig 400 bájt, az mindent elmond. Ha hat hónapon át 400 bájtos backupok készültek, azt végig jelezték neked.

2. Tartalmazza az adatokat, de a körülöttük lévő dolgokat nem

Egyetlen adatbázis pg_dump mentése nem tartalmazza a role-okat, és más adatbázisokat sem. Állítsd vissza egy friss szerverre: a táblák megérkeznek, miközben minden GRANT olyan role-ra hivatkozik, amely nem létezik. Az alkalmazás csatlakozik, és mindenhol permission denied hibát kapsz.

Az extensionök esetében ugyanez a helyzet. Ha a sémád a pgcrypto vagy a uuid-ossp használatára épül, a célkörnyezetben pedig ezek nincsenek telepítve, a visszaállítás félúton leáll, és csak néhány táblád marad.

3. A restore-hoz szükséges beállításokhoz nem megfelelő flag-eket használtál

A pg_dump a formátumtól függően különböző kimenetet készít, és a hibára általában csak nyomás alatt derül fény:

• Plain SQL formátum esetén a visszaállítás psql segítségével történik, és az eredmény ember által olvasható. Nem lehet szelektíven visszaállítani, nagy adatbázisoknál pedig lassú.
• Custom format (-Fc) esetén a visszaállítás pg_restore segítségével történik, támogatja a párhuzamosítást és a szelektív visszaállítást, ezért minden nagyobb adatbázishoz ezt érdemes használni.

Plain formátumban backupolni, mert a tutorial is ezt tette, majd egy incidens során rájönni, hogy egyetlen táblát sem tudsz visszaállítani: ez a rossz napok egyik konkrét és elkerülhető formája.

4. Nem tudod visszafejteni

Ha a backupok titkosítva vannak — és így kell lenniük —, akkor a kulcs is a backup része. Az a kulcs, amely csak az elveszett gépen vagy a leállt service egyik environment variable-jében létezik, nem áll rendelkezésedre, amikor szükséged van rá.

Így néz ki egy valódi ellenőrzés

A teszt nem az, hogy „létezik-e a fájl”. Állítsd vissza máshová, és tegyél fel neki egy kérdést.

# 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)

A 2. lépés az egész folyamat lényege. Az, hogy a restore hiba nélkül befejeződik, még nem mond semmit arról, hogy az adatok valóban ott vannak-e. A sorok száma és a frissesség ellenőrzése viszont igen.

Három dolgot érdemes assertálni:

• A sorok száma a megfelelő nagyságrendben van. Nem kell pontosan egyeznie — az adatok változnak —, de ha egy korábban 200 000 soros tábla most 12 sort tartalmaz, az hiba.
• A legújabb rekord friss. Ha a „nightly” backupban a legutóbbi rendelés márciusi, akkor a backup job márciusban leállt.
• Az alkalmazás valóban tud csatlakozni. Irányíts egy staging példányt a visszaállított adatbázisra, és tölts be egy oldalt.

Ütemezetten csináld, ne egy incidens megoldásakor

A reális gyakoriság havi, automatizált ellenőrzés, amelynek eredménye olyan helyre kerül, ahol észre fogod venni. A „backupok tesztelése” naptárbejegyzés olyan emlékeztető, amelyet el fogsz napolni.

Ami működőképessé teszi, az a hangos hibajelzés: ha az ellenőrző query a küszöbértéknél kevesebb sort ad vissza, ugyanúgy jelezzen valakinek, ahogyan egy production hiba is tenné. A csendben meghibásodó backup rendszer megkülönböztethetetlen attól, mintha egyáltalán nem lenne backup rendszer — egészen addig, amíg szükség nem lesz rá.

Hogyan kezeli ezt a Dockup?

Három döntés, amelyek mind a fenti hibák egyikére adnak választ.

A backupok máshová kerülnek. Azzal azonos lemezen tárolt backup, amelyen az adatbázis is található, nem backup — csak egy másolat, amely a lemezzel együtt vész el. A Dockup közvetlenül object storage-ba streameli az adatbázis-backupokat, miközben azok elkészülnek, így a fájl soha nem függ az azt létrehozó hosttól.

Titkosítva vannak, a kulcs pedig nincs a gépen. A backupok streamelés közben AES-256-GCM-mel titkosítva készülnek. A helyreállítás szempontjából az a lényeg, hogy a kulcsot a platform kezeli, nem pedig a backupolt service environmentjében található.

Ami nem készített semmit, az nem kerül backupként rögzítésre. Ez közvetlenül az üres fájlok problémáját kezeli: ha a dump nem nulla exit code-dal lép ki, vagy nulla bájtot hoz létre, a feltöltés törlődik, a backup pedig sikertelenként lesz rögzítve. Nem marad egy olyan zöld bejegyzésekkel teli listád, amelyben az egyik fájl 400 bájtos.

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

A listában látható méretek jelentik a legolcsóbb health checket. Figyeld a trendjüket.

A kellemetlen kérdés

Ha a production adatbázisod a következő tíz percben megsemmisülne, mennyi idő alatt állítanád helyre, és mennyi adatot veszítenél?

Ha egyik számra sem tudsz válaszolni, akkor nincs backup stratégiád — csak backup fájljaid vannak. A különbség teljes egészében azon múlik, hogy valaki végrehajtotta-e már a restore-t.

Gyakran ismételt kérdések

Milyen gyakran kell tesztelnem a restore-t? A havi gyakoriság jó alapértelmezett beállítás, lehetőleg automatizáltan, nem manuálisan. Az a fontos, hogy a hiba hangos legyen, nem az, hogy agresszív legyen az ütemezés.

Miért fejeződött be a restore, ha mégsem lett benne adat? Általában azért, mert a dump rossz adatbázis ellen készült, vagy a folyamat úgy hibásodott meg, hogy közben tovább írta a fájlt. Hasonlítsd össze a backupok méretét az idő során — egy üres dump jól látható a méret trendjében, a státuszoszlopban viszont rejtve marad.

Titkosítani kell a backupokat? Igen, és a kulcsnak olyan helyen kell lennie, amely túléli a gép elvesztését. Az a titkosított backup, amelynek kulcsa az elveszett szerveren volt, nem állítható helyre.

A snapshot ugyanaz, mint a backup? Nem. A volume snapshot a lemezt rögzíti, beleértve azt az állapotot is, amelyben az adatbázis abban a pillanatban volt. A logikai dump felépítéséből adódóan konzisztens. A legtöbb csapat mindkettőt használja, különböző hibák ellen.